mandelbrot fractal optimization

[realcr]

Hey everyone.

I was trying to write code to draw the mandelbrot fractal , however it seems like my algorithm to do it is really slow...
I am testing 500X500 points to find their color and draw them on screen as squares , so I can adjust the quality of picture.
Is there a faster idea to do that task , as I assume my problem is coming from the place of planning the algorithm...

bar.

[savage]

The best program I have ever seen in my life for fractals is this program: http://www.ultrafractal.com/

Infact, my avatar is a fractal I made from it a long time ago.  Funny.

Anyway you could look into their algorithm information, since obviously they know what they are doing.

[realcr]

Savage ,thanks for replying.

I have the feeling that the authors of this program will not agree to share their idea for algorithm (as they ask money for their program)...
I will keep looking for a fast algorithm to calculate the color for each point in mandelbrot fractal , I'm open for ideas.

thanks,
bar.

[savage]

Well I do highly suggest using SSE and MMX as much as possible, that is, if you aren't already.

[raymond]

If you are looking to improving speed using the FPU, the best approach is to keep as many as possible of your variables in FPU registers. minimizing memory access to/from registers.

You may want to have a quick look at the following, including the posted Mandelbrot generator program. Answers to specific questions can later be answered.

http://www.ray.masmcode.com/complex.html

You may also want to do a search of the site on the subject of fractal.

Raymond

[stanhebben]

Note that the FPU is slow, especially on the pentium 4.

[mnemonic]

Some years ago I wrote a Mandelbrot algorithm that used the FPU and I don't think that it is slow.
Try for yourself, it's attached. :)

I don't know whether it is optimized or not, I just took some algorithm that somebody wrote for a Java Applet and converted it to assembly. At that time I made my first steps in using the FPU.
There is currently no colouring and no zooming.

I would be happy if we could start some small community project and write some Mandelbrot rendering program that makes use of the different possible methods (FPU, MMX, SSE, ...).
What do you guys think about that?

[attachment deleted by admin]

[stanhebben]

Well, I have an amd cpu and those can work well with fpu :bg so I can't tell if it really runs slow on a pentium 4. Renders in about a second here.

If we start a community project, I'll do the sse2 version ;)

[savage]

Renders fairly fast on Pentium IV.

Took about a half second or so.

[raymond]

With the program which you can get from the link I posted previously, the basic Mandelbrot is generated in 0.2 sec in 800x600 on a P4-1500 (using the FPU). That timing was obtained after switching to/from 640x480. For some reason it runs faster than the opening screen.

Because of the various other features of the program, the Mandelbrot generating code has extraneous instructions to cater for those other features. The "barebone" code would thus be slightly faster, but probably not by much. If someone can run it on an AMD with similar MHz for speed comparison with the P4, the program also displays the elapsed time for generating the fractal within a dialog box listing the main parameters of the current fractal (by using the TAB key).

NOTE: Because I was aiming for the maximum range of magnification, all computations are done with 80-bit floats. I can thus get magnifications up to 10^17 for the basic Mandelbrot in 640x480. Using only 32-bit floats could also make it faster but at the cost of a very limited range of magnification.

If we start a community project, I can handle the FPU version unless someone can do better than my algo.

Raymond

[Tedd]

You can't really change the algorithm itself, since this is the precise way to calculate the mandelbrot set - which is a plot of the points where the iteration either converges or diverges. As a result, it's iterative by nature. All you can do to make the algorithm go faster (make a diverge/converge decision) is to limit your threshold, and therefore precision (you may make a diverge decision when it should actually converge in the next few iterations, but you've already cut-off). The points that take longest are those that diverge, since you have to iterative all the way to your threshold, but there's no way of knowing whether or not they will until you test the iterations.
Depending on your 'magnification' (the area of points covered) you could dynamically adjust the precision so there's little noticeable defect.

[VlasRad]

Have look here: http://board.flatassembler.net/topic.php?t=5122

optimized code and very well work for multi processor  :U

[mnemonic]

I started a new thread for the community project here: http://www.masm32.com/board/index.php?topic=4899.0

Ready, steady, go!

[savage]

w00t! Count me in.

[realcr]

Wow ,thanks for so many suggestions...
I will try read some of the code you pointed me to , probably it is faster than mine.

Great thanks!

bar.