x64 fractserv test

project: 64-bit test.frp
server: eng-wzengerle64 running 64-bit version of fractserv, verified x64 native, all cores 100%
record, all frames empty with nearly identical coords, server Progress checked
server render times:

83.068
83.551
84.411
84.393
84.131
84.420
84.337

32-bit fractserv, also on eng-wzengerle64, verified x32 server render times:

84.572
87.800
83.241
84.129
82.974
83.261
83.002

Incredible, but for GMP 4.2, x64 appears to confer essentially NO advantage. WTF?

canceling deep zoom render is too slow

Too slow as a minute or more to cancel in some cases. This makes normal navigation impossible.

TerminateThread seems to work fine, except it leaks 4K (per render thread) each time. No doubt it's stack-related. The leak adds up fast and judging from the net there's no way around it. Not a good solution, and dangerous too. What other options are there besides moving the cancel test into the x-loop?

benchmarks: test2rec.frp default image, deep zoom

pass #  y-loop  x-loop
1       428.749 428.870
2       433.881 430.811 <- less???
3       431.174 430.821 <- about the same
4       430.790

same test on eng-ckorda (10 passes):

y-loop      x-loop
2049.676075 2039.400477
2048.712436 2038.438469
2050.792970 2037.090637
2050.447226 2035.422571
2048.608691 2037.680482
2048.793714 2037.724510
2046.311500 2036.718894
2046.910888 2036.637628
2048.768443 2036.429394
2047.345827 2028.997061

The x-loop test is doing more work but it's 0.5% faster!? Why? Must be a cache effect?

Retested on eng-ckorda, not alternating but doing y-loop tests first, then x-loop tests.

y-loop:
2237.09407
2062.133135
2136.322901
2257.790813
2327.423103
2238.671214

x-loop:
2209.896596
2193.642617
2163.614744
2373.648677
2223.055257
2042.156961

Looks pretty random... x-loop still faster on average though.