Title: buddhabrot in fortran :) Post by: ker2x on March 07, 2010, 07:33:07 AM I decided to learn fortran yesterday :)
it's fun and faaaaaaaaaaaaaaaaaaaaaaaaast ! (http://ker.endofinternet.net/img/buddhabrot.png) Code: USE omp_lib Title: Re: buddhabrot in fortran :) Post by: ker2x on March 07, 2010, 08:02:47 AM actually, it compute 2*100 millions mandelbrot with bailout = 100 in 1mn47s on a single-core in a virtual machine (ubuntu running on win7 using virtualbox)
I need to refactor the code so the compiler can do auto-parallelisation. (yup, that's a nice feature of intel fortran compiler, you can let the compiler do all the multithreading stuff if you want ;D ) Title: Re: buddhabrot in fortran :) Post by: Sockratease on March 07, 2010, 12:49:33 PM I learned to program punching cards in Fortran III - glad to see it's still a toy for some folks!
Nice image too... Title: Re: buddhabrot in fortran :) Post by: ker2x on March 07, 2010, 06:33:52 PM I learned to program punching cards in Fortran III - glad to see it's still a toy for some folks! and a tools for some others. Some (most?) Top500 supercomputer are running fortran code. One of the guy that helped me to learn fortran use fortran on a cluster that is 13th on top500 Supercomputer (~26.000 cores and 80TB of memory ...) http://www.top500.org/system/10147 Title: Re: buddhabrot in fortran :) Post by: ker2x on March 08, 2010, 03:27:55 AM The latest dev version is available here : http://github.com/ker2x/Fortran_buddhabrot
Title: Re: buddhabrot in fortran :) Post by: Timeroot on March 08, 2010, 06:15:18 AM Looks cool - I didn't know Fortran handled complex numbers so natively. I think you could get a pretty big speed increase if, instead of checking inside/outside and calculating the orbit separately. Just keep a different counter that you update while finding the orbit the first time, and if it stays inside, then add it to the running total array.
Also, you can save a load of time but immediately removing big chunks, like the main cardioid and period-2 bulb, which can be found very simply. There are some formulas on the Wikipedia page about the MSet that tell how to eliminate them immediately. Good luck! :D Title: Re: buddhabrot in fortran :) Post by: ker2x on March 08, 2010, 07:38:40 AM Thx for the tips ! I'll try that :)
(i'm bad at math, but it's a good way to learn) fortran have many awesome feature. complex is one of them. The way it handle array is really awesome too. a good exemple is : exposureRMap = (exposureRMap / REAL(maxRExposure))*intensityR in pseudo-code, it could be something like : foreach element in exposureRMap exposureRMap[element] = (exposureRMap[element] / REAL(maxRExposure))*intensityR end And best of all : remark: LOOP WAS AUTO-PARALLELIZED. yup, the compiler transform this single line into some kind of "forearch loop" and handle the multithreading automagically. Thoses niceties explain why fortran is still used on Top500 supercomputer. With the right parameters, it can launch the threads on remote computers of a cluster, using openmp. Sadly, most of my code isn't parallized because of "ANTI" and "FLOW" dependencies. I'm planning to work on it to parallelize the main loop (the problem is in the exposureMap arrays) Title: Re: buddhabrot in fortran :) Post by: Nahee_Enterprises on March 08, 2010, 07:42:24 PM I decided to learn Fortran yesterday :) it's fun and faaaaaaaaaaaaaaaaaaaaaaaaast ! Way to go!! It has been at least two decades (probably more) since I last worked with Fortran, and that was on an IBM mainframe. Are you using the Evaluation copy, or did you fork over the $899 purchase price, or "acquire it" in some other manner?? Title: Re: buddhabrot in fortran :) Post by: Nahee_Enterprises on March 08, 2010, 07:56:15 PM actually, it on a single-core in a virtual machine (ubuntu running on win7 using virtualbox) I need to refactor the code so the compiler can do auto-parallelisation. (yup, that's a nice feature of Intel Fortran compiler, you can let the compiler do all the multithreading stuff if you want ;D ) I noticed that the Intel® Visual Fortran Compiler for Windows Professional Edition also has the option of including the Visual Numerics IMSL Fortran Library. I am guessing that this might not be part of the Linux version?? http://software.intel.com/en-us/articles/visual-numerics-imsl-fortran-library/ (http://software.intel.com/en-us/articles/visual-numerics-imsl-fortran-library/) If you already have a Windows environment, why not just use the Visual version?? Title: Re: buddhabrot in fortran :) Post by: ker2x on March 09, 2010, 07:59:11 AM actually, it on a single-core in a virtual machine (ubuntu running on win7 using virtualbox) I need to refactor the code so the compiler can do auto-parallelisation. (yup, that's a nice feature of Intel Fortran compiler, you can let the compiler do all the multithreading stuff if you want ;D ) I noticed that the Intel® Visual Fortran Compiler for Windows Professional Edition also has the option of including the Visual Numerics IMSL Fortran Library. I am guessing that this might not be part of the Linux version?? http://software.intel.com/en-us/articles/visual-numerics-imsl-fortran-library/ (http://software.intel.com/en-us/articles/visual-numerics-imsl-fortran-library/) If you already have a Windows environment, why not just use the Visual version?? I use the "free for non commercial use" intel software, that are available only on linux :) http://software.intel.com/en-us/articles/non-commercial-software-download/ Intel® C++ Compiler Professional Edition for Linux* Intel® Fortran Compiler Professional Edition for Linux Intel® Compiler Suite Professional Edition for Linux Intel® Math Kernel Library (Intel® MKL) for Linux Intel® Integrated Performance Primitives (Intel® IPP) for Linux Intel® VTune™ Performance Analyzer for Linux Intel® Thread Checker for Linux Title: Re: buddhabrot in fortran :) Post by: ker2x on March 09, 2010, 06:54:29 PM Looks cool - I didn't know Fortran handled complex numbers so natively. I think you could get a pretty big speed increase if, instead of checking inside/outside and calculating the orbit separately. Just keep a different counter that you update while finding the orbit the first time, and if it stays inside, then add it to the running total array. Also, you can save a load of time but immediately removing big chunks, like the main cardioid and period-2 bulb, which can be found very simply. There are some formulas on the Wikipedia page about the MSet that tell how to eliminate them immediately. Good luck! :D I found an itneresting website about the mandelbrot discs : http://classes.yale.edu/fractals/MandelSet/MandelCombinatorics/N2Scaling/N2Scaling.html Title: Re: buddhabrot in fortran :) Post by: ker2x on March 09, 2010, 09:43:34 PM i added the main cardiod and 2nd circle optimisation.
code pushed to github as usual. the main change is : Code: IF(((ABS(z - CMPLX(-1,0) )) < 0.25) .OR. (( ABS( 1.0 - SQRT(1-(4*z)) ) < 1.0 ) ) ) THEN Title: Re: buddhabrot in fortran :) Post by: ker2x on March 10, 2010, 01:23:12 AM updated to run in multithread.
I still have a weird bug... it works with a grid_size of 500x500 and segfault with 1000x1000 Title: Re: buddhabrot in fortran :) Post by: lkmitch on March 10, 2010, 04:32:46 PM I found an itneresting website about the mandelbrot discs : http://classes.yale.edu/fractals/MandelSet/MandelCombinatorics/N2Scaling/N2Scaling.html Shameless plug--I'm the Kerry Mitchell mentioned on that page. :) Michael Frame (who created those class notes) told me about the scaling rule some 20 years ago. While investigating it numerically (in FORTRAN), I discovered those deviation features. Title: Re: buddhabrot in fortran :) Post by: ker2x on March 10, 2010, 09:01:31 PM i'm wondering if it worth it to pre-compute the 3rd and 4th order disc.
i know they are not real disc, and it certainly doesn't worth it to compute a very good estimation, but i can estimate the size of a rough interal disc contained in the 3rd and 4th order disc/shape. It's very cheap in cpu time. (much cheaper than computing the main cardioid, but considering its size : it worth it) Title: Re: buddhabrot in fortran :) Post by: Timeroot on March 11, 2010, 01:43:43 AM I found an itneresting website about the mandelbrot discs : http://classes.yale.edu/fractals/MandelSet/MandelCombinatorics/N2Scaling/N2Scaling.html Shameless plug--I'm the Kerry Mitchell mentioned on that page. :) Michael Frame (who created those class notes) told me about the scaling rule some 20 years ago. While investigating it numerically (in FORTRAN), I discovered those deviation features. That's a pretty interesting page. I believe the fractal structure of those plots is somewhat similar tick marks on a ruler. I'm thinking this: if m/n has one value of rtc/rad, then (1/3)+m/6n and (1/3)+m/3n have a similar structure. Also, (1/4)+m/8n and (1/4)+m/4n would also produce similar values. This might explain the compression that occurs off to the side. Indeed, the structure reminds me of the dyadic rationals... Did you ever try plotting the values, as sorted by n? Or by m? Or maybe a plot (multivalued) where the x-coordinate corresponds to m+n? I would love to see!!! i'm wondering if it worth it to pre-compute the 3rd and 4th order disc. i know they are not real disc, and it certainly doesn't worth it to compute a very good estimation, but i can estimate the size of a rough interal disc contained in the 3rd and 4th order disc/shape. It's very cheap in cpu time. (much cheaper than computing the main cardioid, but considering its size : it worth it) But that would only save any time if you happen to be zooming in on one of those shapes. And in general, a good Mandelbrot pic doesn't have a huge period-3 or 4 mass off to one side... Has anyone investigated what shapes the bulbs are? When looking at skewed Minibrots, it seems they don't possess any other deformation. I would hypothesize that the bulbs are all exact ellipses (skewed circles), and that there is some correlation between m/n and their skew angle. The angle could be defined as relative to the normal. However, if we defined the angle that way, in order to fully describe the shape one would also need a stretch factor. The alternative would be the skew angle, and the angle relative to the normal, relative to which it was skewed. If someone wrote a program that gathered data on this, and then maybe tried plotting using both of those, I'm sure it would result in some interesting results. Title: Re: buddhabrot in fortran :) Post by: Timeroot on March 12, 2010, 01:49:58 AM Ohhhh, I think I understand that plot now. It's just a graph along the surface of the cardioid... I wonder what the ratio would be if you took successively accurate rational approximations of the Fibonacci point. I would still like to see a computation of the skew (if they truly are ellipses) though... and whatever shape they are I wonder if the center - that is, the multiplier - is the actual center of the shape. In the case of an ellipse, I mean the *center*, but of course for more irregular shapes you can define many different points as the center... O0
Title: Re: buddhabrot in fortran :) Post by: ker2x on May 04, 2010, 09:23:20 PM I added some easy optimisation to quickly know if a point is in an area of interest or not (more than a few iteration, and not inside the mandelbrot set)
The first one is to choose a "good" random point. 1) There is nothing interesting outside of -1.3 to 1.3 on the imaginary axis 2) There is nothing interesting outside of -2 to 0.5 on the real axis Code: c = CMPLX((x*2.5 - 2) ,y*1.3 ) After that, i ignore all point which are in the main cardoid, or in the 2nd bulb. Code: IF(((ABS(c - CMPLX(-1,0) )) < 0.25) .OR. ((ABS( 1.0 - SQRT(1-(4*c)) )) < 1.0 ) ) THEN There is probably more optimisation, but thoses ones were easy :) Title: Re: buddhabrot in fortran :) Post by: ker2x on May 04, 2010, 11:08:17 PM i'm back to good old black and white rendering.
Source code available here : http://github.com/ker2x/Fortran_buddhabrot/blob/BlackAndWhite/buddhabrot.f90 minimum iteration : 10k maximum iteration : 1 million Using 3 core in VirtualBox : real 3m5.918s user 8m47.050s sys 0m1.640s Title: Re: buddhabrot in fortran :) Post by: ker2x on May 17, 2010, 02:13:21 PM i ran a test and added too much zeros on the parameters.
So i tested 1 billion points at 100.000 maximum iterations (and 5 as "minimum iteration"). (a grand total of 200.000.000.000.000 iterations (worst case, probably much much much less than that)) it took 41.000mn (~28days) of cpu time (on an atom D510 (dual core + HT = 4 "cores") The resulst is very... useless. i could have the same result with 10mn of computation :) But ... well... now i know it ! EDIT : i just checked the picture on a more modern screen (with much more contrast/luminosity) the resulst is not so bad, after all ;D link to the original 2048x2048 version : http://fractals.s3.amazonaws.com/buddhabrot/buddhabrot-100KBillions.png (http://fractals.s3.amazonaws.com/buddhabrot/buddhabrot-100KBillions.png) EDIT2: on the 2048x2048 version, with a good screen : minibrot everywhere \o/ wonderfull \o/ It wasn't a waste of time :D compressed 1024x1024 below : (http://fractals.s3.amazonaws.com/buddhabrot/buddhabrot-1024x1024-100KBillions.png) Title: Re: buddhabrot in fortran :) Post by: kram1032 on May 18, 2010, 05:56:47 PM very nice results :)
Title: Re: buddhabrot in fortran :) Post by: decayer on June 10, 2010, 03:26:00 AM very good! I just thought the image means flattened. You know why? And man, it's really fast! |