END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

Not without quite a lot of work.

I did start refactoring the formulas into separate files using C preprocessor to avoid code duplication, not finished or published yet.  But it allows a formula to be written concisely in 2 short files:

formula/Mandelbrot2.h

formula/Mandelbrot2.cpp

Plus 6 calls like F(type,power) in the relevant places, and 1 line to add the formula to the GUI.

Possibly this simplified formula code could be used for OpenCL too - or at least make it easier to add support.  But I don't know how to use OpenCL on Windows, much less how to get it to work correctly in WINE.

Another change I made is to remove the threaded reference calculation - the non-threaded sped it up by a large factor (about 3x faster by elapsed wall-clock time for Dinkydau's Hyperbolic Tiling Pistile location) - either there is too much synchronisation overhead, or WINE is terrible at it.  I published a new build with this change (but not the formula refactoring), would be great to have some benchmarks from real Windows users, maybe is a WINE issue: https://mathr.co.uk/kf/kf.html

Here (WINE) it takes over twice as long with old version.  So I think the conclusion is that it is a WINE issue:

version / total time as reported by kf / refs / notes
20170504 / 19m51s289 / ref 12 / without multithreaded reference calculations
20170406 / 46m02s592 / ref 12 / wineserver uses 60% CPU when computing reference


Yes absolutely, at least make it available as an option in the menus (so that WINE users can disable it), if automagic config isn't an option.  I don't know much about Windows GUI programming but I'll try to hack it in this week.

EDIT: as of now Windows users should use the 20170406 release, WINE users should use the 20170504 release, for best performance...

EDIT: confirmed on IRC as a WINE issue:
17:19 < slackner> ClaudiusMaximus: without having reviewed the whole code, my theory would be that multithreading is done in such a way that a lot of time is wasted with synchronization
17:19 < slackner> ClaudiusMaximus: event functions always use the wineserver atm, so this would explain the performance issues
17:19 < ClaudiusMaximus> yes that's definitely the case, i'm just suprised at the huge difference between Windows and WINE (around 4x)
17:19 < ClaudiusMaximus> ok, and wineserver is single-threaded?
17:20 < nsivov> it is
17:20 < slackner> ClaudiusMaximus: yes. in most cases that shouldn't matter though, usually wineserver calls are rare and can be executed very quickly
17:21 < ClaudiusMaximus> yes this code is a bit pathological i guess

EDIT:  I investigated other synchronisation methods (alternatives to SetEvent()/WaitObject()), here's some rough results:

To conclude I'll use SetThreadAffinityMask(3) for ldbl and SetThreadAffinityMask(1<<threadid) for floatexp, which gives the best performance in these tests in WINE 64bit / Debian Stretch / AMD64 quad core processor.  I'll post again with a new build soon.

wine kf.exe
fixme:heap:HeapSetInformation 0x240000 0 0x23fe10 4
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:advapi:RegisterEventSourceW ((null),L"Bonjour Service"): stub
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54dfc0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x6f9c0,(nil)): stub
fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub
fixme:winsock:WSAIoctl -> SIO_ADDRESS_LIST_CHANGE request: stub
fixme:iphlpapi:DeleteIpForwardEntry (pRoute 0x54e350): stub
fixme:iphlpapi:CreateIpForwardEntry (pRoute 0x54e318): stub
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54dfc0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
fixme:service:EnumServicesStatusW resume handle not supported
fixme:service:EnumServicesStatusW resume handle not supported
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54dfc0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
fixme:netapi32:NetGetJoinInformation Semi-stub (null) 0x54e038 0x54e030
fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from 192.168.1.8:5353   16 zelman.local. AAAA FE80:0000:0000:0000:889C:3EA7:6CEA:BDC9"
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: ProbeCount 2; will deregister    4 zelman.local. Addr 192.168.1.8"
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d3e0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"Local Hostname zelman.local already in use; will try zelman-2.local instead"
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from 192.168.1.8:5353   14 8.1.168.192.in-addr.arpa. PTR zelman.local."
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Unexpected conflict discarding   16 8.1.168.192.in-addr.arpa. PTR zelman-2.local."

KF program works for me ( maybe it was not seen from output )
wine --version
wine-1.6.2

The scientific notation bug appears to be back since 20170330.1
Edit: I downloaded 20170330, the version where the bug would have been fixed, but it has scientific notation too.

new build at https://mathr.co.uk/kf/kf.html


The XML formula definition file is here:  https://code.mathr.co.uk/kalles-fraktaler-2/blob/refs/heads/formulas:/formula/formula.xml
As you can see it strips out all the repetitive code.

It should be possible to generate OpenCL code from these formula definitions, at least for double precision (no long double in CL, and not sure if there is operator overloading for floatexp).

The latest version crashes upon loading KFR files with a great depth such as E8383.

Also something else:
I'm interested in running kalles fraktaler in a virtual machine. I want to do that because it would allow me to save the state of the operating system while a heavy render is going on. If there's something that causes the computer to stop working such as power loss I can resume the render from the last saved state.

I compared some render times. There are 4 relevant types of calculations:
1. full precision reference pixels
2. series approximation
3. other pixels
4. Newton-raphson zooming, which could be split up into 4.1: finding period, 4.2: Newton-Raphson steps, 4.3: determining size of the minibrot.

First I tried windows 10 because it's easy to get a legal (trial) ISO of it.
Total render time is a little slower. Reference computation seems to be significantly slower.
Newton-Raphson zooming is about 5 times slower. (100 seconds versus 20 in a test). Especially finding the period is a lot slower. The other parts are slower as well.
This holds for several versions.
Mandel Machine and Fractal eXtreme perform pretty much exactly like how they do in my not-virtual windows 7, so the windows 10 virtual machine will be useful to render with Mandel Machine but not with Kalles fraktaler.

Then I installed Debian stretch with wine because it's what Claude uses, so I assumed it must be the most suitable to run his Kalles fraktaler fork.
Newton-Raphson zooming is still slower but only 2.5 times as slow. Also here, especially finding the period is a lot slower, but not as slow as in windows 10.
Comparing virtual Debian and not virtual Windows 7, the total render time is equal when using the latest version of KF+gmp to compare and a KFR file with depth E1886. Compared to this test:
Version 20170406 is about 8% faster in windows 7 (not virtual) but A LOT slower in Debian.
Version 20170508 is about 8% faster in windows 7 (not virtual) and 7% slower in Debian.

20170406 is the best version on windows 7, seemlingly equal to 20170508. 20170508 is the best version in Debian because it's the fastest one that doesn't hang upon loading great depths.
In the end 20170508 in Debian seems to be about 12% slower than 20170406 in not virtual Windows 7. I would accept that percentage if it means I won't have to be afraid to lose renders anymore but more tests with greater depths are required to be sure if it's worth doing. If the latest version didn't hang, it would be better.

Newton-Raphson zooming is so much faster on windows 7 (not virtual) that it's worth taking the risk of losing the progress right now.
I wondered how this could be and it came to my mind that Fractal eXtreme and Mandel Machine have all the important parts (that take a lot of time to run) written in assembly language. Could that have something to do with the fact that those programs don't seem to have any performance hits?

I will see if I can find my windows 7 installation DVD and make a virtual machine with that too to compare.