Mandel Machine

[Botond Kósa]

ne thing I notice while zooming in, is that most frames appear nearly instantly when the 1st orbit is completed, but when approaching areas with high density or a highly advanced Julia formation, the process of rendering pixels suddenly slows down by nearly an order of magnitude, then speeds back up after leaving the area or zooming through it. Kind of ironic that the feature I'm trying to render takes longer than the stuff immediately before or after it. And no, it's not one of those "blobby" areas either. Still strange that the complexity of the image or density of iteration data will have a profound impact on render speed (orbits are still about the same at this depth and iteration count though).

The reason for this lies in the efficacy of series approximation, which is best in sparse, boring areas, lower at embedded Julias, and lowest at Minibrots. When you approach a complex embedded Julia formation, the average iteration count per pixel grows at an ever increasing rate, but the number of iterations skipped by SA remains constant. If SA could skip 99% of the iterations previously, and only 90% at the Julia, this means a 10x increase of the calculated iterations in spite of only 10% increase of the average iteration counts. After leaving the Julia, the skipped iteration count "catches up", almost reaching the previously seen level (99% in our example).

When rendering complex locations (embedded Julias or Minibrots), you can try to increase the SA coefficients count in the Computation box. According to my measurements each step up in SA coefficients (5 to 9, 9 to 17 etc) decreases the actually computed iterations by 30-50%. Be aware though that there is a bug in SA coefficients calculation that can cause the skipped iterations to drop suddenly when reaching a certain amount of coefficients. This happens quite often when using 129 coefficients, and rarely at 65. Using 33 or less is generally unproblematic.

[Botond Kósa]

One more thing to keep in mind: when calculating with long double (80-bit extended) precision, no SIMD instructions can be used. So it is best to avoid extended precision by allowing SA to skip enough iterations so that the coordinates of the orbit fit in the range of ordinary doubles. If you run the application with logging enabled (from the command line or the provided cmd file), search for the line that begins with "Reference orbit min value...". There are some other factors that affect the data type used, but as a rule of thumb, if the exponent of the min value is greater than -600, doubles can be used instead of long doubles. And if it is greater than -70, single precision floats can be used instead of doubles, potentially resulting in a further 2x speed bump (~1.2-1.5 in practice).

The used data type can vary from pixel to pixel. You can see the distribution of the used data types on a per-pixel basis in the Statistics box.

[stardust4ever]

In the AMD Bulldozer architecture each processor module includes two CPU cores and one shared FPU (your 8-core CPU has only 4 FPUs). Inside a module, the two CPU cores already saturate the execution units of the shared FPU at a pixel grouping of 12, so going to 16 results in no further speed improvement. (Btw, the situation is the same on Intel CPUs with HyperThreading.)

Even worse, the Bulldozer modules have only two 128-bit FPU pipelines that can be unified into one 256-bit unit when running AVX code, so theoretically their performance under SSE2 and AVX is the same. By comparison, Intel processors have two 256-bit wide FPU pipelines per core. One Sandy Bridge or newer core has the same floating point throughput as 4 Bulldozer cores under AVX workloads. For more details and measurements see this article at AnandTech: http://www.anandtech.com/show/7711/floating-point-peak-performance-of-kaveri-and-other-recent-amd-and-intel-chips

So same old, same old about the Intel CPUs getting more operations done per core per clock. I miss the good old days of Athlon XP kicking P4's butt with cheaper CPU that got more work done running at lower clock cycles. But at least we have AMD to thank for the x86-64 architecture which was far superior to Intel's obsolete IA64 offering...

Guess I'm just a fanboy for the underdogs. I like AMD, Pepsi, and Nintendo while everybody else is doing Intel, Coke, and MS/Sony...  

I read some more info on Wikipedia about some new operations being added to x86-64 instruction sets in upcoming processor models by AMD and Intel, which are specifically targeting bignum arithmetic (mainly for cryptography and academic/scientific use but it should work for fractal rendering too). Future looks promising although I'm not entirely sold on the idea of integrated ALUs (CPU + GPU) for desktop processors, although the concept works great for mobile. Less opportunity for customization, ie the option to buy as much or as little CPU and GPU as you want.

[Botond Kósa]

Another small update containing bugfixes. Palette extracted from an image is finally saved correctly in the .mmf file.

[stardust4ever]

Another small update containing bugfixes. Palette extracted from an image is finally saved correctly in the .mmf file.

I set the color cycling to 201 in one of my renders and saved it. When I opened the file, it went back to 200. I manually edited the mmf file in notepad to say -201. when I opened the file, it still defaulted to 200. It's similar to how 100 will default to 99 when saved and reopened. And yes, I'm running version 1.2.9.

Overall, the glitch correction update is awesome. Thanks for making this. I can't wait untill you get movies working. Also, would it be too much to ask if you could enable the direct import of Kalles Fraktaler palette data? Currently the process of importing color palettes from Kalles Fraktaler is clunky because I have to resave as *.mmf selecting only palette data, then reopen the file on top of a previously loaded fractal. This load operation resets the iteration data and forces a rerender.

I know you have an option to open palette data from PNG files, but I don't know how to use it. Do I just make a custom gradient and save it as PNG using image editing software?

[Dinkydau]

It's simple to do, although it's kind of a hassle. You can convert a gradient to an image. I use 4096×10 bmp file because SeryZone's software accepts that too (which is useful). To convert a gradient, you can take a screenshot of it and stretch it in photoshop to the resolution you wish. Use bicubic image resizing for the best result.

[stardust4ever]

It's simple to do, although it's kind of a hassle. You can convert a gradient to an image. I use 4096×10 bmp file because SeryZone's software accepts that too (which is useful). To convert a gradient, you can take a screenshot of it and stretch it in photoshop to the resolution you wish. Use bicubic image resizing for the best result.

I thought it was something like that. It's probably simpler just to create a palette in Kalles Fraktaler and import it into Mandel Machine like I described earlier.

[SeryZone]

I think that you should to make turning on/off history recording. Maybe, It will reduce RAM usage.

[stardust4ever]

I think that you should to make turning on/off history recording. Maybe, It will reduce RAM usage.

I'm pretty sure most 64-bit machines now come with at minimum 4 Gigs of RAM. I've got 16 Gbytes on mine, recently upgraded to a dual channel 8Gbx2 1866Mhz kit. The only time Mandel Machine ever sucks more than a Gig or so of RAM is if I'm trying to render ginormous .5Gigapixel images.

And for that I still need to use a .bat file to unlock the extra RAM. Hint for next update.

[Botond Kósa]

SeryZone is right, there is a severe memory leak in the history function when using a palette that was extracted from an image. Will be fixed in the next release.

[SeryZone]

=)

Sometimes program is closes automatically (now I have 12gig RAM), when RAM usage is getting more than 4GB. 'Not enough memory!' - and closes =(

[stardust4ever]

=)

Sometimes program is closes automatically (now I have 12gig RAM), when RAM usage is getting more than 4GB. 'Not enough memory!' - and closes =(

I have not used the "IMG from PNG" Feature personally (a bit clunky, but I import palette data from Kalles Fraktaler parameters).

Place thie Huge.bat file in your Mandel Machine directory. It will let you utilize up to 10 Gigs of memory. I open Mandel Machine with it whenever I want to render huge images.

[SeryZone]

I have not used the "IMG from PNG" Feature personally (a bit clunky, but I import palette data from Kalles Fraktaler parameters).

Place thie Huge.bat file in your Mandel Machine directory. It will let you utilize up to 10 Gigs of memory. I open Mandel Machine with it whenever I want to render huge images.

I don't need only little images (10240x5760 - is little)! I need infinite iteration limit too. But with perturbation theory RAM usage grow up due to iteration limit. I need 20-30GB RAM 4 rendering my location 2,000,000,000 iterations! This is very hard but... I must to render it! It is beautiful!

[stardust4ever]

I don't need only little images (10240x5760 - is little)! I need infinite iteration limit too. But with perturbation theory RAM usage grow up due to iteration limit. I need 20-30GB RAM 4 rendering my location 2,000,000,000 iterations! This is very hard but... I must to render it! It is beautiful!

Every little bit helps though. You can edit the BAT manually and specify how many megabytes of RAM Java is allowed to use. Go a bit over what you think you'll need!

[SeryZone]

Well, for 2,000,000,000 iterations we need array of 2billions. double. We need (8*2B)=16,000,000,000 bytes =  14.901GB RAM for reference! + 10240x5760 image (10240*5760*4 = 225MB) Totally I need maximum 16GB for rendering final minibrot's image. Botond, Why I can't do this???



Sorry =( My idea works with integer, but doesn't works with float numbers =((( Idea was be @Compressing reference@