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

The number of iterations skipped with SA is constant for the whole image. No per-pixel evaluation is done currently. The memory savings come from the fact that if N iterations will be skipped (for all pixels), there is no need to store the first N values of the reference orbit. (Although this is not yet implemented in the current beta version.)

Did you download the 64-bit version? The installed version can be verified with this command:
java -version

You should see something like this:
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

It is also possible to have multiple JREs installed, both 32 and 64-bit. In this case you have to check the presence of the 64-bit version in the Program Files folder. 64-bit JREs should be under Program Files\jre, 32-bit JREs under Program Files (x86)\jre.

I use an own class called ASFloat (arbitrary scale float). It is similar to Kalle's floatexp type. It stores numbers in mantissa*2^exponent format, where mantissa is a normalized double value (1<=mantissa<2) and exponent is an integer. The precision of this type is the same as that of double (52 bits), but the scale is much larger (32 bits compared to 11 bits of double or 15 bits of extended precision). All calculations related to SA coefficients are done using ASFloats, and the resulting coefficients are also stored in ASFloats.

MM can also be forced to calculate iterations using ASFloats by setting the Scale to 2000000000 (ASFloat) and Pixel grouping to 1 in the Computation box.

I don't know about such descriptions. The basic operations are pretty straightforward. Multiplication is done by multiplying the mantissas and adding the exponents. Addition and subtraction is done by rescaling the smaller term to match the exponent of the larger one, and then adding/subtracting the mantissas (the exponents remain unchanged). Some additional logic has to be implemented to handle zero values (which have no meaningful exponent), and the results have to be normalized every now and then to avoid over/underflow of the mantissas.

You could also look up the details in the source code of Kalles Fraktaler.

At what location and zoom level did you measure the 10x difference? MM uses automatic scale reduction whenever possible, and this makes comparisons a little trickier. The basic idea is the following: when calculating a perturbed orbit, the magnitude of its absolute value grows steadily (with some small jumps up/downwards and some bigger jumps downwards) from delta₀ to the bailout value. The rate of the growth is also increasing as we approach the bailout.

In the classical algorithm without SA, if |delta₀| < 10^-308, long double must be used to avoid underflow. But if SA can skip N iterations where N is large enough (more than 90% of the length of the reference orbit), the approximated value will likely be in the range of doubles: |delta_N| > 10^-308. If "Ignore small addends" is turned on, delta₀ is no longer added to the calculated delta_i (since delta₀ is tens or hundreds of magnitudes smaller), and all the iterations can be calculated using doubles*. This also enables the use of SIMD codepaths, resulting in a further 2x-8x speedup.

* There is one more thing to check: the previously mentioned bigger downward jumps in log|delta_i| are caused by sudden drops in the magnitude of the reference orbit (|Z_m|). So we have to be sure that minValue = |delta_N| * min_m>N|Z_m| > 10^-308

This method can also be taken one step further: if minValue > 10^-38, the remaining iterations can be calculated using floats instead of doubles, increasing the speed further by up to 2x when using SIMD. (This is not yet enabled in the current beta.) And also in the opposite direction: if minValue is between 10^-600 and 10^-308, scaled doubles can be used, which are a little slower than ordinary doubles, but much faster than long doubles.


I will have to check this. Maybe the normalization has to be done more frequently.


I found that checking the corners only is not always enough. In fact, when the image is centered on a julia, there are some cases when the borders are rendered correctly but the center is corrupted due to the SA skipping too many iterations. Evaluating the skippable iterations on small regions locally might help, but it would also be more costly.


Yes, I had to disable glitch correction, as I mentioned under Known issues in the changelog. I started to implement Pauldelbrot's method, but the whole thing is in an intermediate state now, and neither the old nor the new method works correctly.

It is using long double or ordinary double, but definitely not ASFloat. It should use ordinary double because at that location scale reduction is possible, but I am not sure I implemented it when pixel grouping is 1. But you can disable scale reduction and force the program to use long doubles by changing Scale (in the Computation box) from Automatic to Extended. (You can also force it to use ASFloat, by the way.)

My extended routines are written in ASM, but no SIMD is used (SIMD instructions work on floats and doubles only). You mentioned that you used DevC++ to implement the long double calculations, since MS VC++ does not support long doubles in 64-bit mode. I also tried DevC++ a few years ago (albeit for a different purpose) and found that the code produced by its compiler was quite slow.

According to my measurements on my dual-core Ivy Bridge laptop, the throughput of KF using long doubles is about 70 million iterations/second. This is comparable to MM using ASFloats (which also depends on the JRE used, since ASFloat is pure Java for the time being). The throughput of MM using long doubles is above 500 million iterations/second.

In the previous version of Mandel Machine I was having this glitch. It appears when 0 or 6 terms are being used for the series approximation. Note that it happens even with 0 terms! 10 terms (or any more than that) now gives the correct result.



The parameter file is attached to the post as .txt for reference.

Interesting: as I zoom deeper, I now need more and more terms for the render to be correct.