Dinkydau
|
|
« Reply #30 on: June 27, 2013, 09:04:16 PM » |
|
Settings: Resolution: 640×360 Coordinates: Re = -1.479,946,223,325,078,880,202,580,653,442,563,833,590,828,874,828,533,272,328,919,467,504,501,428,041,551,458,102,123,157,715,213,651,035,545,943,542,078,167,348,953,885,787,341,902,612,509,986,72 Im = 0.000,901,397,329,020,353,980,197,791,866,197,173,566,251,566,818,045,102,411,067,630,386,488,692,287,189,049,145,621,584,436,026,934,218,763,527,577,290,631,809,454,796,618,110,767,424,580,322,79 Magnification: 2^471 6.0971651373359223269171820894398 E141
Test results: Software | Time to render (s) | Speed-up factor | Fractal eXtreme | 326,00 | 1,0 | Kalles Fraktaler | 48,95 | 6,7 | SuperFractalThing | 9,50 | 34,3 |
SuperFractalThing time was measured with a clock, so it's not as accurate as the others. The reason is that while the dialog window is opened to save the PNG file, the timer still counts (I just noticed). An important factor is the time it takes to calculate the reference point. The fewer pixels rendered, the more influence that the reference point has on the total calculation time. Both SuperFractalThing and Kalles Fraktaler would score better if the resolution was larger, especially SuperFractalThing because of the short total time. This explains the different speed-up factor from my previous test in the SuperFractalThing topic. Big differences, what is it that SuperFractalThing does better?
|
|
« Last Edit: June 27, 2013, 09:05:58 PM by Dinkydau »
|
Logged
|
|
|
|
cKleinhuis
|
|
« Reply #31 on: June 27, 2013, 09:20:58 PM » |
|
thank you for the numbers, SFT is incredibble ! i have no clue what it does better, i hadnt had the time to look a slightest into it, *offtopic*because of a little flood here in my house that destroyed my beloved main computer, aaaargh, this weekend show recording and cutting with ultra slow laptop
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
cKleinhuis
|
|
« Reply #32 on: June 27, 2013, 09:22:13 PM » |
|
but it might have to do with the fact that you just use equation (1)
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
Kalles Fraktaler
|
|
« Reply #33 on: June 27, 2013, 10:06:30 PM » |
|
Thanks for the comparison. It shows that algorithm and optimization is more important than language. I have some fun optimization in front of me
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #34 on: June 28, 2013, 10:22:15 AM » |
|
Pauldebrot mentions in the other thread that my program lack "series approximation", which SFT and the program he is making will have. I don't know what he means but maybe that can explain the difference in performance. I would like to know what this is.
Dinkydau, was it the 32-bit or 64-bit version of Kalles Fraktaler you used?
|
|
« Last Edit: June 28, 2013, 11:17:27 AM by Kalles Fraktaler »
|
Logged
|
|
|
|
claude
Fractal Bachius
Posts: 563
|
|
« Reply #35 on: June 28, 2013, 04:40:24 PM » |
|
my program lack "series approximation".... I would like to know what this is. That's the later equations in the sft maths pdf: the idea is that you compute A,B,C for the reference point, then initialize all the pixels in the image using that - which allows you to skip the first bunch of iterations completely for all the pixels. I think that if the reference point has period P, then you can skip the first 2P iterations of equation 1 for every pixel. SFT uses recursive subdivision, but I haven't yet worked out how much of an extra win that is. Dinkydau's coordinates has partials: 1 2 4 6 12 106 220 326 652 1304 2908 5516 11032 22064 So I think it'd be around an island with period 5516 (as the later two partials are exact multiples of it), so you could skip the first 11k iterations of eq1 for each pixel...
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #36 on: June 28, 2013, 06:15:02 PM » |
|
thank you for the numbers, SFT is incredibble ! i have no clue what it does better, i hadnt had the time to look a slightest into it, *offtopic*because of a little flood here in my house that destroyed my beloved main computer, aaaargh, this weekend show recording and cutting with ultra slow laptop Oh, that's not nice. I hope you haven't lost much important data. Pauldebrot mentions in the other thread that my program lack "series approximation", which SFT and the program he is making will have. I don't know what he means but maybe that can explain the difference in performance. I would like to know what this is.
Dinkydau, was it the 32-bit or 64-bit version of Kalles Fraktaler you used?
I used the 64-bit version.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #37 on: July 05, 2013, 09:10:08 AM » |
|
I have updated my program, now series approximation is used. My goal is not to create the smartest application, others are working with that. Instead I want my application to be able to create deep zoom animations as fast as possible. And it is now a little faster than SFT. Enjoy
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #38 on: July 05, 2013, 12:15:58 PM » |
|
4,518 seconds!!! So the new test results are: Software | Time to render (s) | Speed-up factor | Fractal eXtreme | 326,00 | 1,0 | SuperFractalThing | 9,50 | 34,3 | Kalles Fraktaler | 4,52 | 72,2 |
|
|
« Last Edit: July 05, 2013, 12:17:37 PM by Dinkydau »
|
Logged
|
|
|
|
cKleinhuis
|
|
« Reply #39 on: July 05, 2013, 12:56:55 PM » |
|
congrats, now its getting interesting
|
|
|
Logged
|
---
divide and conquer - iterate and rule - chaos is No random!
|
|
|
Kalles Fraktaler
|
|
« Reply #40 on: July 05, 2013, 02:09:42 PM » |
|
That's really great! (your computer is twice as fast as mine ) With series approximation 33097 iterations are skipped for each pixel, which is almost 3/4 of all iterations.
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #41 on: July 05, 2013, 05:23:11 PM » |
|
It still doesn't work on my desktop, but it looks like something has improved. The program first renders the mandelbrot set and then crashes, instead of immediately. While it's rendering, I can access the menus, but the time is too short to do anything.
|
|
|
Logged
|
|
|
|
Kalles Fraktaler
|
|
« Reply #42 on: July 05, 2013, 08:36:32 PM » |
|
Strange, and it does work on your laptop. And the difference is that your desktop is running Windows7 and your laptop some other version... The current location is stored for each zoom click, so that if the app crash it should be possible to recover the position. But storing a file in the same directory as the application should not cause it to crash...
|
|
« Last Edit: July 05, 2013, 08:42:08 PM by Kalles Fraktaler »
|
Logged
|
|
|
|
klixon
|
|
« Reply #43 on: July 08, 2013, 01:14:47 PM » |
|
Strange, and it does work on your laptop. And the difference is that your desktop is running Windows7 and your laptop some other version... The current location is stored for each zoom click, so that if the app crash it should be possible to recover the position. But storing a file in the same directory as the application should not cause it to crash...
It might if your program installs into one of the "program files" directories, or other directories protected as "windows" or "system" directories. DinkyDau, have you tried running the programs as administrator? (right-click the shortcut/executable and choose "Run as administrator..."
|
|
|
Logged
|
|
|
|
Dinkydau
|
|
« Reply #44 on: July 08, 2013, 01:55:39 PM » |
|
Yes, I did that. I tried everything.
|
|
|
Logged
|
|
|
|
|