New Fractal Program/Screensaver

[Christian]

Look at the following image.  I did the Ornament Julia Set at 1 billion iterations in 5.709s.  If you look where all the lines connect, bifurcation would have removed all the isolated pixels.  There are many different algorithms to detect the boundaries of fractals.  Huygen Lines, is just my version of the Algorithm.  It is not the only way or the best just a small piece of "The Fractal Algorithm".  There are many algorithms and disciplines in developing a good fractal program, and as many can agree, thousands of hours.  Like you I develop, and code in my free time at night.  I believe that fractal mathematics is the new frontier of the next mathematical revolution.  Please run this point using other fractal programs, and see how it compares.  You can see the full version here: www.zevendevelopment.com/images/ornament1920x1080.png

[Christian]

I think the OP is named 'Huygen', so there is probably no relation to the physicist Huygens :-)

My father was born in Haarlem Holland and I was a Dutch Citizen till I moved to the US.  My family tree goes back to the 13th century, and I have no relation to the physicist Huygens.

@Christian: Can't you explain what these Huygen lines are? Then it would be easier to see whether this is something new. There are already fast Mandelbrot zoomers out there - for instance 'Frax' for iOS which lets you zoom in realtime on an iPad.

There are many fast Mandelbrot zoomers.  The goal of 'The Fractal Algorithm' was to not use the GPU, because there are a lot of different video cards on the market.  'Frax' an impressive program for the iPad, does use the GPU.  See: http://news.cnet.com/8301-1035_3-57605820-94/yep-apples-a7-looks-twice-as-fast-at-least-for-fractal-math/

You program is certainly fast in the 'preview' mode. I get 30 fps, but this seems to be based on some sort of interpolation/rescaling between keyframes, which introduces visual artifacts (see e.g. the pixelation on the attached screenshot). When I go to edit mode and zoom interactively, the render time is higher (1-30 seconds for zooming in on complex locations). For proper time comparisons, it would be necessary with an option to calculate a single frame at the specified location - I don't think this is possible as of now?

Btw, the program crashes when exiting 8-bit colors mode on my machine (Windows 7). 32-bit works fine.

Thank you, we are aware of the issue, on some machines, and are looking to fix it.  When DirectX sets a fullscreen 8-bit mode, the windows task bar does not follow Microsoft's rules and takes over the palette.  To properly set the palette, we have to terminate the task bar, and when you exit, we relaunch explorer.exe, which depending upon your setup of your security rights will cause an exception.

[Christian]

You program is certainly fast in the 'preview' mode. I get 30 fps, but this seems to be based on some sort of interpolation/rescaling between keyframes, which introduces visual artifacts (see e.g. the pixelation on the attached screenshot). When I go to edit mode and zoom interactively, the render time is higher (1-30 seconds for zooming in on complex locations). For proper time comparisons, it would be necessary with an option to calculate a single frame at the specified location - I don't think this is possible as of now?

If you zoom in on a region of the fractal and create a new image, then using the saved iterated states of both images, where they intersect, Huygen Predictors can very quickly and accurately predict additional images. This is an iterated prediction, not pixel enlargement or interpolation. Regions outside the zoomed image where there are no intersection can only be enlarged, but since we are zooming this creates a nice motion blur effect helping in the zoom animation.  You will notice in predicted images, areas that contain a lot of detail, changes with every frame and will get the exact same effect if the predicted frame was calculated instead.

Orbits have patterns they can be used to predict.  You can set the predicted frames to zero so that every frame will be calculated.

[Kalles Fraktaler]

This method is depending on that the image has large "empty" areas with the same iteration count, and is actually slower, because of the overhead, if one zooms into a valley of a minibrot, where the space between spirals is not "empty". But if you are only using double float precision, which only allows you to zoom to about e13, these areas might not be so common. But it would certainly not impress any of my friends, as stated on the site, to show them zooms to e13!

I did a test in a minibrot's valley and Fractal eXtreme is faster. Even Kalles Fraktaler is as fast as FX - for the first reference. The location took about 15 seconds in both programs and I counted longer for the Fractal Algorithm program that unfortunately doesn't have any time indication.

Code:

Re: -0.1620036716521200206544664171007115394287
Im: 1.0354894536599102947447035047743266666668
Magnification: 3.435973836E10

Dinkydau's tick-tock, which we have used for measurements before, does almost not contain any empty areas, still Christian states it can be rendered 1000 times faster with his method ("any fractal"). I am sure that even if everything else would be as fast as FX, his method would make the render slower!

3dickulus, you shouldn't be too worried to put down on his work, because that is what he does to every other fractal applications when listing how bad they are compared to his program ("but all have one or more of the following limitations"). I think it is kind of priggish. Christian, why are you trying to belittle our work, what do you think you will gain?
This might even be some kind of a joke, digging up an old render method from the 80s, calling it he's own and claiming its superiority even though it's limited to e13??

[Christian]

The Fractal Algorithm does not use arbitrary precision, just CPU doubles, no floats either at this time.  I'm currently looking at double doubles that breaks the coefficients up which will give 30 digit precision or more if supported in real time.  Use of Huygen lines will give any fractal calculations up to x1000 speed improvements even at e100.  The Mandelbrot is a fractal why not use another fractal to calculate it?  The Fractal Algorithm was the first attempt at a true real time zoom of a fractal that could run on any dual core i5 CPU.  Enjoy!

First of all I said up to x1000, and it appears that you have missed the point of "The Fractal Algorithm".  It is an attempt to do real time zooms on fractal points.  Secondly I have purposely not compared any timings with other programs, because it is pointless.  I will not belittle other peoples hard work.  You have a deep zoom program and I commend you on that.  Please run the point of the Ornament Julia Set at 1 billion iterations and compare for yourself.  The Fractal Algorithm is FREE, you can't get a better deal!

[3dickulus]

I'm CaNaDiAn, we're just generally respectful and polite regarding others efforts but we do appreciate integrity,
ie:make a claim and it should stand on it's own merits without the need to defend it.

I present code examples for all to scrutinize and only issue a challenge when in need of enlightenment which will be accepted graciously.

The recursive bifurcating algorithm that I presented will not miss the pixels in tight areas, it will simply degenerate to calculating every pixel. It is not mine, I didn't invent it, anyone can find examples of it on the 'net.

I admire anyone who puts their code out there as in OpenSource, it's like being naked, everyone can see both flaws and assets, free to appreciate and criticize. (better wear your helmet, it's rough out there)

Anyone that has executed the binary "The Fractal Algorithm" without examining the source code is (imho) at risk.

What's a better deal than a "Free" program ? THE SOURCE CODE!!! that teaches me something new.

[Kalles Fraktaler]

First of all I said up to x1000, and it appears that you have missed the point of "The Fractal Algorithm".  It is an attempt to do real time zooms on fractal points.  Secondly I have purposely not compared any timings with other programs, because it is pointless.  I will not belittle other peoples hard work.  You have a deep zoom program and I commend you on that.  Please run the point of the Ornament Julia Set at 1 billion iterations and compare for yourself.  The Fractal Algorithm is FREE, you can't get a better deal!

Up to x1000, does that include 0.001 as well?
I think that since you claim your program is superior compared with all other fractal programs, a time indicator would not be pointless, so that we can compare.
What I do think is pointless is to render the Ornament Julia set with a billion iterations, since much less is required to make a decent image. 10'000-100'000 is enough, without antialiasing, depending on the resolution. Can you explain why you think antialiasing makes fractal images blurry??

But indeed, since this location contains large "empty" areas the "Border tracing / edge checking" method render it very fast compared to calculating every black pixel.
What you shown is that the fastest way to calculate a billion iterations is to not calculate them at all, which is indeed a good point, but I think most of us already knew that.
So your program is great as a demonstration of a special case when you can skip unnecessary calculations, but this is not the superior general fractal program you are describing in your presentation, and it's sad that you try to assert your own superiority by deprecating all others by listing how bad they are.

[Christian]

If you want to enable the timer so that you can see how long the fractal took to calculate please enable the statistics option.  Again the purpose of The Fractal Algorithm was an attempt to create a real time fractal zoomer that would work on a dual core i5.  Isn't it the point to calculate as little as possible so that it will run faster?  There are a lot of good fractal programs out there, with their pros and cons.  I listed my reasons why I wrote The Fractal Algorithm and never made mention of any ones program by name and never will.  Even The Fractal Algorithm has its pros and cons, like it can not do deep zooms (which was the design for this release), and I will continue making it better every day.  These are my observations, and my attempt to write a better program. Competition is great, it gives the consumer a better a product, and at the end of the day the consumer will decide which product they like!

[3dickulus]

Watch your fractal zooms in real time!  Finally a new and faster way to generate fractals called “The Fractal Algorithm”.  Get your free copy today at www.zevendevelopment.com.  Run it as a screen saver and impress your friends and coworkers!  No GPU required!  It's FREE!

got some issues with your statement(s)...

I did the Ornament Julia Set at 1 billion iterations in 5.709s.

realtime??? not according to your own timing report of 5.709s. That's per frame?

The goal of 'The Fractal Algorithm' was to not use the GPU

finally a faster way??? I think not. 1152 core GPU vs 2 core CPU (even with my math skills it's a no-brainer)

Get your free copy today at www.zevendevelopment.com.

Your proggie won't truly be free until you release the source code from captivity.

impress your friends and coworkers!

definitely not happening!

depending upon your setup of your security rights will cause an exception.

whoa! you mean to avoid crashing I have to lower or remove security rights!?! again, not happening.

and finally...

at the end of the day the consumer will decide which product they like!

Here, perhaps, is the flaw in your perspective calculations (modus operandi). If you are viewing the good folks that frequent Fractal Forums as "consumers" and trying to market yourself your prog your website etc. to them you have to do a deeper analysis of who these people really are, Phd.s, scientists, mathematicians, researchers, teachers, students, artists, explorers, visionaries, nerds and of course hobbyists and laymen.

But what really takes the cake is "Huygen Lines", oh yeah, that will make you famous but maybe not in the way you envisioned.

somebody just had to say it 

[lycium]

finally a faster way??? I think not. 1152 core GPU vs 2 core CPU (even with my math skills it's a no-brainer)

Sorry, but I have some issues with this kind of accounting too. It is in no way obvious that tons of ants is "better" than an elephant, and the millions of ants don't always behave in a way that makes each one do useful work all the time...

At the risk of getting even more vague, let me just say: computer architecture (and the software that runs on it) is very complicated, and just comparing "big number versus little number" is exactly the kind of marketing game various vendors would love you to think works in real life...

[3dickulus]

yes I have to agree, but I'm reasonably sure that that a good GPU will emulate high precision math faster than a desktop CPU

[lycium]

yes I have to agree, but I'm reasonably sure that that a good GPU will emulate high precision math faster than a desktop CPU

Of course, but this does not excuse the earlier error in reasoning In fact, it makes it even more dangerous somehow: "well, it's definitely faster, so probably this reasoning about core count is totally fine..."

If your GPU code is wildly branch-divergent, and has very poor memory-to-compute properties, all those thousands of "cores" (they cannot be directly compared to a huge x86 core!) suddenly get serialised into a single thread of execution, and all the "magic pixie dust" that people think GPUs have is suddenly gone...

[3dickulus]

yes, there is no replacement for specialized hardware, GPUs specialize in graphics FPUs specialize in math and without a good CPU to keep them organized it wouldn't work very well at all.

as for my earlier reasoning it is solely in the context of "The Fractal Algorithm" and claims related to it.

[hobold]

It is in no way obvious that tons of ants is "better" than an elephant, and the millions of ants don't always behave in a way that makes each one do useful work all the time...

I once saw this quote attributed to Seymour Cray, inventor of the first "vector computers" (i.e. SIMD machines), of which modern GPUs are distant spiritual descendants:

"If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?"

At the risk of getting even more vague, let me just say: computer architecture (and the software that runs on it) is very complicated, and just comparing "big number versus little number" is exactly the kind of marketing game various vendors would love you to think works in real life...

The idea that "computing speed" is a single number is an invention of the marketing department. First that number was clock frequency. Then that number was some benchmark score. Then that number was core count. Then that number was ALU count. God knows what marketing comes up with next.

In reality, computing speed is a collection of at least four distinct numbers: computational throughput, computational latency, memory bandwidth, memory latency. Any one of those can be the slowest runner who sets the pace. And in practice, a particular piece of computing machinery requires many more than four numbers to accurately characterize possible performance.

The recent trend of thinking in terms of performance per watt adds a whole new set of energy related numbers to the whole thing.


The real fun starts when you begin comparing different algorithms. Simpler algorithms tend to better utilize the full brute force of the hardware. Smarter algorithms tend to re-use information computed earlier, which is efficient, but makes parallelization harder. Wildly different hardware will perform best with wildly different algorithms. But when neither software nor hardware have any similarities, then what do comparisons of a specific workload mean? Such specialized benchmark scores don't correlate much with the performance of other, arbitrary software.


Now, this wall of text doesn't help much over the simpler summary: "It's complicated" . So let me conclude with the most important piece of wisdom I acquired in a former life as a specialist for performance optimization:

The best way to predict the performance of a given piece of software on a given machine is to run that software on that machine.

The most important corollary is: the only way to know if you are definitely fastest is to time all competing programs on all competing machines. So be careful claiming top speed. That remains true even if you invented a seemingly new miracle algorithm. Speed tuning is a lot about re-inventing old wheels.

[Christian]

got some issues with your statement(s)...
realtime??? not according to your own timing report of 5.709s. That's per frame?

That was for a test at 1 billion iterations.  The Ornament Julia Set is one of the sample zoom points, but it uses variable iterations as I've described on my product page.  At 100,000 iterations on a dual core i5 it takes only 640ms.  With the combination of predicted frames it should play well.  The Fractal Algorithm needs to be compared as a whole, not in individual parts.

finally a faster way??? I think not. 1152 core GPU vs 2 core CPU (even with my math skills it's a no-brainer)
Your proggie won't truly be free until you release the source code from captivity.
definitely not happening!
whoa! you mean to avoid crashing I have to lower or remove security rights!?! again, not happening.

Please understand it has never been stated to remove your security rights.  In order to set a full screen DirectX 8-bit (256 color) mode the only way I have found to properly set the colors is to terminate the task bar (explorer.exe).  Upon return I have to re-run explorer.exe which on some systems causes an exception.  This is well documented in other forums of people trying to run older 256 colors games.  If you know of another way please let me know, or just run it in 32-bit mode.

and finally...
Here, perhaps, is the flaw in your perspective calculations (modus operandi). If you are viewing the good folks that frequent Fractal Forums as "consumers" and trying to market yourself your prog your website etc. to them you have to do a deeper analysis of who these people really are, Phd.s, scientists, mathematicians, researchers, teachers, students, artists, explorers, visionaries, nerds and of course hobbyists and laymen.

But what really takes the cake is "Huygen Lines", oh yeah, that will make you famous but maybe not in the way you envisioned.

somebody just had to say it 

Everyone is a consumer, even me.  I want to thank you for your feedback because it appears that a lot of consumers have been reading.  The Fractal Algorithm is being download now at a rate of 10 per hour and accelerating which means consumers are trying it.  Thank you again!

As far as CPU vs GPU, I am using an ASUS laptop i5 dual core laptop with an Intel HD 3000 GPU, and The Fractal Algorithm runs great on it even at 60fps.  I would love to have a super high powered GPU, but they are kinda power hungry in laptops, not to mention expensive.  The video on the welcome page was done with that laptop.  Again The Fractal Algorithm was designed to play fractal zooms on ordinary dual core i5 PC's.