Logo by reallybigname - Contribute your own Logo!

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

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Support us via Flattr FLATTR Link
 
*
Welcome, Guest. Please login or register. March 28, 2024, 09:40:47 AM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: 1 2 3 [4] 5 6 ... 24   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: *Continued* SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java.  (Read 46904 times)
0 Members and 1 Guest are viewing this topic.
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #45 on: March 05, 2016, 07:38:46 PM »

my impression was that there was just the one initial reference point and no series approximation
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #46 on: March 05, 2016, 10:52:49 PM »

Your coordinates worked like a charm! smiley
FYI, I posted another image in my Pterodactyl series. Zoomed in the old fashioned way in Mandel Machine to a final depth of 7845 zoom levels deep. That soft-limit of 10000 zooms is getting closer. Sorry if I'm thread crapping.
http://www.fractalforums.com/images-showcase-%28rate-my-fractal%29/pterodactyl-vertebrae/msg91074/#msg91074

I just wanted to thank people again for solving the arbitrary precision problem with fractal zooming. At nearly 8000 zoom levels and 1.6 million iterations, each orbit is taking 30+ seconds to compute on my rig. Too bad calculating orbits can only use one CPU thread at a time. Computing high resolution images at this depth using the old Fractal Extreme methods would literally be impossible. Kudos for making this possible... afro
Logged
hapf
Fractal Lover
**
Posts: 219


« Reply #47 on: March 06, 2016, 01:41:11 PM »

I just wanted to thank people again for solving the arbitrary precision problem with fractal zooming. At nearly 8000 zoom levels and 1.6 million iterations, each orbit is taking 30+ seconds to compute on my rig. Too bad calculating orbits can only use one CPU thread at a time.
Well, one can split every iteration up into real and imaginary part, and iteration and distance, if one uses distance. Because of parallel processing overhead this split into 2 or 4 threads pays only off when the number of bits gets high enough. But it definitely can.
Logged
Kalles Fraktaler
Fractal Senior
******
Posts: 1458



kallesfraktaler
WWW
« Reply #48 on: March 06, 2016, 04:49:27 PM »

Too bad calculating orbits can only use one CPU thread at a time.
Actually it can at be splitted into at least 3 threads, since the 3 squaring operations can be executed in parallel.
Code:
xin = srsi - sr - si + iref;
xrn = sr - si + rref;
xr = xrn;
xi = xin;
sr = xr.Square();                // thread 1
si = xi.Square();                // thread 2
srsi = (xr + xi).Square();       // thread 3
I've implemented it in KF (when going beyond e600) and discussed this with Botond, however KF is much slower than MM calculating deep references even in mutliple threads, and Botond has not yet implemented it in MM (is he active at all these days?)
Logged

Want to create DEEP Mandelbrot fractals 100 times faster than the commercial programs, for FREE? One hour or one minute? Three months or one day? Try Kalles Fraktaler http://www.chillheimer.de/kallesfraktaler
http://www.facebook.com/kallesfraktaler
claude
Fractal Bachius
*
Posts: 563



WWW
« Reply #49 on: March 07, 2016, 06:36:17 PM »

I wrote a blog post about series approximation, mainly to retract a previous post in which I used symbolic algebra in an overcomplicated way (hi quaz0r!) - maybe it's useful as it has the (possibly well-known) general formulas for the series approximation with arbitrary order (thanks hapf) http://mathr.co.uk/blog/2016-03-06_simpler_series_approximation.html  it also contains the observation that high precision isn't so necessary for the series coefficients
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #50 on: March 08, 2016, 08:36:58 AM »

Actually it can at be splitted into at least 3 threads, since the 3 squaring operations can be executed in parallel.
Code:
xin = srsi - sr - si + iref;
xrn = sr - si + rref;
xr = xrn;
xi = xin;
sr = xr.Square();                // thread 1
si = xi.Square();                // thread 2
srsi = (xr + xi).Square();       // thread 3
I've implemented it in KF (when going beyond e600) and discussed this with Botond, however KF is much slower than MM calculating deep references even in mutliple threads, and Botond has not yet implemented it in MM (is he active at all these days?)
I'm not a software engineer, but I understand it's possible for CPU cores to share cache memory. Assuming each squaring operation takes a relatively constant amount of time (and it will if all threads are operating on cores at the same speed, and in the case of Intel Hyperthreading or AMD's Bulldozer architecture, both threads are not on the same core/module), then each thread produces a numerical result somewhere in the processor's cache memory. It is my understanding the way modern CPU architecture works, that lower level L1 cache is devoted to each core (Intel) or module (AMD), and the upper level L2 and L3 caches are accessible to the entire CPU. A forth CPU thread will need to apply the results of each multiplication and perform addition or other functions on it. How many CPU cycles does it require to fetch this information from other areas of the cache? Also I assume that perturbation rendering may take additional penalties because the results of each iteration must be stored somewhere in RAM so that it can be used to calculate the remaining pixels in float or low precision maths based upon the delta between orbits of nearby pixels. I also imagine the performance penalty for fetching each of three product values for summation from adjacent caches would be relatively constant and not increase exponentially as precision increases. Even if running three threads only decreased orbit time by 50%, that would still be a very welcome performance boost.

There are also other performance savings introduced by Fractal Extreme where Bruce Dawson noted that up to 75% of multiplication operations during a square (or half during a multiply) are basically discarded when the end result is computed, because they are either duplicate operations or least significant bits which get truncated from the final product. Further performance increases were gained in Mandel Machine by taking advantage of AVX instruction sets in newer AMD and Intel CPUs.

Overall Mandel Machine has been a God-send for extreme deep zooming. Also a shoutout to Kalles Fraktaler for his addition of my abs() variant fractal definitions, and excellent zoom movie software, even if it is a bit slower at insane deep mandelbrot sets. Now if only someone could implement a fool-proof brot-finding algorithm. The experimental feature in Mandel Machine is still a bit unreliable, although I haven't attempted to use the KF one recently.

Mandel Machine is much faster, even if it only consumes ~13% (one core) of my 8-core CPU while calculating orbits, at least according to Task Manager. Kalles Fraktaler is slower overall and as such I tend not to use it beyond 1e1000 or so for pure Mandelbrot deep zooms. I have noticed Kalles Fraktaler consumes a bit over ~30% or so CPU (between two and three cores) when calculating orbits. I have not done a benchmark recently but need to update Kalles Fraktaler on my desktop anyway.

I wrote a blog post about series approximation, mainly to retract a previous post in which I used symbolic algebra in an overcomplicated way (hi quaz0r!) - maybe it's useful as it has the (possibly well-known) general formulas for the series approximation with arbitrary order (thanks hapf) http://mathr.co.uk/blog/2016-03-06_simpler_series_approximation.html  it also contains the observation that high precision isn't so necessary for the series coefficients
One wierd side effect of exploring formations within Mandel Machine: When I zoom into a feature with extremely high detail (typically the target formation if I'm searching for a new fork point), the render speed slows to a crawl. Prior to the detailed formation and upon passing it, the remaining pixels appear almost instantly if I'm zooming at a medium resolution (800x600 or so), but right when I have the entire target formation in view, rendering of pixels on screen is not instant but takes some time to pass. A few seconds to a minute or so at medium resolution, to a few hours at very large (say 12800x9600 or something big like that) print quality resolution (which I scale down to 3200x2400 pixels or so in GIMP using bilinear filter for clean 4x4 antialias). I for one am not complaining. A gigantic image (12800x12800) at 8000 or so zooms taking five hours to complete is hella faster than a smaller image (3200x3200) at 3132 zooms taking over a month in Fractal Extreme.
Logged
hapf
Fractal Lover
**
Posts: 219


« Reply #51 on: March 08, 2016, 09:07:12 AM »

One wierd side effect of exploring formations within Mandel Machine: When I zoom into a feature with extremely high detail (typically the target formation if I'm searching for a new fork point), the render speed slows to a crawl. Prior to the detailed formation and upon passing it, the remaining pixels appear almost instantly if I'm zooming at a medium resolution (800x600 or so), but right when I have the entire target formation in view, rendering of pixels on screen is not instant but takes some time to pass. A few seconds to a minute or so at medium resolution, to a few hours at very large (say 12800x9600 or something big like that) print quality resolution (which I scale down to 3200x2400 pixels or so in GIMP using bilinear filter for clean 4x4 antialias). I for one am not complaining. A gigantic image (12800x12800) at 8000 or so zooms taking five hours to complete is hella faster than a smaller image (3200x3200) at 3132 zooms taking over a month in Fractal Extreme.
I'm doing my master images usually at 32K these days for clean versions up to 8K and ok 16K versions. But it really depends on the location. Some are so dense in parts that even 32K will not give an aliasing free 4K version.
Concerning the speed differences at different places on the way down it is expected. In between fork points one can usually skip a lot more safely than at fork  points, when embedded Julia sets are popping up or period dominance changes. The amount of corruption removal needed also slows things down considerably at times.
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #52 on: March 08, 2016, 10:55:26 AM »

I'm doing my master images usually at 32K these days for clean versions up to 8K and ok 16K versions. But it really depends on the location. Some are so dense in parts that even 32K will not give an aliasing free 4K version.
Concerning the speed differences at different places on the way down it is expected. In between fork points one can usually skip a lot more safely than at fork  points, when embedded Julia sets are popping up or period dominance changes. The amount of corruption removal needed also slows things down considerably at times.
With the type of formations I am used to exploring, I will zoom into a feature that I like, say an "X" formation, a spiral, what have you, then I will zoom to a point sideways to the feature. At approximately 50% deeper zoom depth and twice deeper iteration depth, a new, higher complexity feature appears, then rinse and repeat. I get a nice line of similar objects in a row, then zoom off somewhere to further perturb and manipulate the shapes, making snakes out of strait lines, or "X of Xs" etc... As I zoom through the glut of shapes on my way to the next fork point, it regurgitates previous patterns in the series as well as new formations of higher symmetry.

Eventually some several thousands of zoom levels deep, and hundreds of thousands to a few million iteration depth, I have generated a formation with up to 32768 or 65536 unique spiral arms or some other fragment of shape that collectively make up the larger shapes or formations, all at the exact same iteration depth, many of which are so small they do not fully resolve in the image, all contorted into some tightly knit formation. Typically I can tell when such a formation is approaching as the iteration bands become very dense, like close circles instead of sparsely placed shapes.

Suppose at a given very deep zoom depth, the first orbit takes 30 seconds to process, then part of the image renders, then the second orbit takes an additional 30 seconds, more pixels are rendered, and so on. Typically after a few such guesses, the full image resolves. Yet the individual pixels calculated at relatively low precision generally render almost instantaneously on screen when displaying simple features, but groupings of low precision pixels take much longer to render when the highly complex target formation appears.

Again I have no issue with the render times, because it is light-years faster than the old Fractal Extreme methods of rendering every pixel at full precision. I am just curious as to why the actual (low to medium precision) fast generated pixels (not the high precision slow orbits) take longer the more complex the formation. Do these high-complexity formations require higher precision to calculate the values of the pixels? If so how does the software know whether to render them fastly or slowly?

To me, this is the biggest speed boost of Mandel Machine over Kalles Fraktaller. Mandel Machine only renderings the low precision pixels slowly when it hits these complex objects. Kalles Fraktaller seems to render more slowly all the time. That tells me Mandel Machine is doing some heavy optimization during the times I am zooming through towards the centroid and rendering relatively simple shapes.

I also noticed that "glitch" formations I seem to encounter much less frequently in the most recent build of Mandel Machine than past experience dictates. But an option to automatically zoom into the centroid or minibrot locator would be most appreciated so I don't have to click the scroll wheel thousands of times over long hours.
Logged
hapf
Fractal Lover
**
Posts: 219


« Reply #53 on: March 08, 2016, 11:59:23 AM »

I don't know how Mandelmachine works internally in detail. But obviously once more than one reference is needed it takes longer. If there is no skipping with secondary references it takes longer still.
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #54 on: March 08, 2016, 01:01:00 PM »

I don't know how Mandelmachine works internally in detail. But obviously once more than one reference is needed it takes longer. If there is no skipping with secondary references it takes longer still.
I'm not referring to the time taken for reference pixels but the fast pixels rendered based on the slow reference pixel take longer to generate when the image is complex enough.
Logged
hapf
Fractal Lover
**
Posts: 219


« Reply #55 on: March 08, 2016, 01:13:07 PM »

I'm not referring to the time taken for reference pixels but the fast pixels rendered based on the slow reference pixel take longer to generate when the image is complex enough.
With the primary reference and all secondary references? Then the amount of skipping possible must come down. Can you see how much is skipped? Also, when switching from long double to extended double for the iterations the rendering time must go up.
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #56 on: March 08, 2016, 01:16:41 PM »

With the primary reference and all secondary references? Then the amount of skipping possible must come down. Can you see how much is skipped? Also, when switching from long double to extended double for the iterations the rendering time must go up.
But when I zoom through the center of formation and continue, the rendering speeds back up. So the overall complexity of the julia formation must affect the precision level needed to accurately render the meat of the image.

I should try to zoom something truly insane, like 65534 Xs in a row. I've never gone past 256 such features because I couldn't locate the center visually. I sure hope the "find centroid" button works in such scenario...  tongue stuck out
http://stardust4ever.deviantart.com/art/Making-X-Fractals-155341193
« Last Edit: March 08, 2016, 01:27:22 PM by stardust4ever » Logged
hapf
Fractal Lover
**
Posts: 219


« Reply #57 on: March 08, 2016, 01:28:57 PM »

But when I zoom through the center of formation and continue, the rendering speeds back up. So the overall complexity of the julia formation must affect the precision level needed to accurately render the meat of the image.
I should try to zoom something truly insane, like 65534 Xs in a row. I've never gone past 256 such features because I couldn't locate the center visually. I sure hope the "find centroid" button works in such scenario...  tongue stuck out
The Julia affects the skipping that is safe to do. And the button would work but might take quite some time to deliver. But much less than you manually for sure.  grin
Logged
stardust4ever
Fractal Bachius
*
Posts: 513



« Reply #58 on: March 08, 2016, 01:40:13 PM »

The Julia affects the skipping that is safe to do. And the button would work but might take quite some time to deliver. But much less than you manually for sure.  grin
Thanks, I'll give it a shot sometime. My latest creation, Pterodactyl Graveyard, has 65536 chromosomal arms in it, but not all in a row!  grin
Logged
quaz0r
Fractal Molossus
**
Posts: 652



« Reply #59 on: March 08, 2016, 03:42:08 PM »

the "fast" low-precision perturbed points take the longest to calculate when you are right on the complex julia formation you were zooming toward, then when youve zoomed past it, they are the fastest they will be between that point and the next complex julia formation, and will gradually get slower until you arrive there, just as youve described, due to how many iterations are being skipped by the series approximation, as hapf was indicating.  say you start out skipping 10,000 iterations, with the average iterations for that location being 11,000, then maybe by the time you get to the next julia formation the skipped iterations have slowly increased to 15,000, but the average iteration there is 30,000.  the number of iterations the perturbed points require has become much more.  then once you zoom past that julia the same pattern of skipped vs average iterations repeats, though the overall number of iterations required still gradually increasing the deeper you go, which could be offset to some degree if you also increase the number of terms in the series approximation as you go, but the return on that seems to be negligible without using a prohibitively large number of terms.

unfortunately what all this means is that the interesting stuff we are after and actually want to render are the slowest spots you could choose to render  cry

oh and these locations also have the highest number of high-precision reference points required to achieve a correct render, so it is the slowest and most demanding in every way..
« Last Edit: March 08, 2016, 04:01:18 PM by quaz0r » Logged
Pages: 1 2 3 [4] 5 6 ... 24   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
Java applet for exploring the Mandelbrot set Announcements & News Paton 5 6592 Last post March 26, 2007, 06:03:34 PM
by Paton
What range/precision for fractional escape counts for Mandelbrot/Julia sets? Programming Duncan C 7 9899 Last post May 01, 2007, 08:23:13 PM
by Duncan C
Java Mandelbrot segment Help & Support fractalwizz 10 1891 Last post December 29, 2008, 08:01:24 PM
by cKleinhuis
[Java] Double-double library for 128-bit precision. Programming Zom-B 10 16952 Last post December 20, 2010, 04:03:48 AM
by David Makin
SuperFractalThing: Arbitrary precision mandelbrot set rendering in Java. Announcements & News « 1 2 ... 16 17 » mrflay 252 98896 Last post August 17, 2016, 11:59:31 PM
by cKleinhuis

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.209 seconds with 25 queries. (Pretty URLs adds 0.012s, 2q)