Amusing anecdote ?

[David Makin]

I created an image using Ultra Fractal (2) on November 6th 2000 called "Aquamarine" and soon after started a disk render on my then PC with "non-adaptive AA" selected.

The render @8000*6000 took 29 days solid to complete i.e. the computer was never switched off though admittedly some of the time I was using foreground apps while UF rendered away in the background.

Now I have this dual 6-core beast I thought I'd see how much quicker the same render would be i.e. non-adaptive AA at 8000*6000.

Here's the info from the log file for the render:

26-9-11 03:55:03: Starting job MMF - Aquamarine.
26-9-11 03:55:03: Anti-aliasing on. Threshold: 0.00. Depth: 1. Subdivisions: 3x3.
26-9-11 03:55:03: Motion blur off.
26-9-11 03:55:03: Rendering in PNG format.
26-9-11 03:55:03: Calculating MMF-Aquamarine in /Users/davemakin/Documents/Ultra Fractal 5/Parameters/tmp.upr.
26-9-11 04:48:59: Saving to /Users/davemakin/Desktop/MMF - Aquamarine.png.
26-9-11 04:49:08: Job finished.

i.e. around 6 minutes short of an hour from start to finish.

So, rounding that up to 1 hour, 11 years of computer advancement has sped up number crunching by 29*24 = 696 times.
But wait, I also checked CPU usage and it was never over 40%, so the real increase in speed in 11 years is more like 1740 times since of course the original system was single-core without hyperthreading.
This is considerably better than the longstanding estimate that computer power doubles every 18 months.

As many older folks are often known to say "Kids today don't know they're born" !!!

[bib]

This is not that impressive I think. Let's round 11 years to 12 (= 8*18 months). Moore's law says that the power would be multiplied by 2^8=256. The reality of your benchmark is 696 (sorry, not the extrapolation at 1740 you did). And in 11 years and 3 major versions, it is reasonable to assume that Frederik has increased the performance of his calculation engine by a factor 3. 3*256=768 > 696. QED

[cbuchner1]

Disk I/O could also have slowed you down back them. Most likely the required swapping of main memory to disk.

[David Makin]

This is not that impressive I think. Let's round 11 years to 12 (= 8*18 months). Moore's law says that the power would be multiplied by 2^8=256. The reality of your benchmark is 696 (sorry, not the extrapolation at 1740 you did). And in 11 years and 3 major versions, it is reasonable to assume that Frederik has increased the performance of his calculation engine by a factor 3. 3*256=768 > 696. QED

Hmmm, using a full 10/4 *is* probably cheating a little because when substantially less than full CPU power is used even these cores have auto-speedup, just not quite as much as the I7's, however I'll stand by my ow belief that *3 is a gross over-estimate of how much more optimum the actual UF code is - one reason being that it had very little potential for improvement in the first place as even UF2 was so good and secondly any improvements made in speed from one version of UF to another have been accompanied by increased sophistication which itself knocks the speed a little,,,in fact I have v3, v4 and v5 on my PC here....just a mo'....

OK here are the render times on my WinXP 3GHz P4HT for "Aquamarine" at the default size (640 wide) within UF (I downloaded and tried V2 as well)

UF2  87 secs
UF3  65 secs
UF4  63 secs
UF5  58 secs

Render time on this system at the same size in UF5 is 1.4 secs, but of course back in 2000 I didn't even have a P4HT in fact we're probably talking around 200MHz tops for the CPU speed - and of course no hyper-threading which gives a factor of around 15*1.5 = 22.5* slower than a P4HT (assuming a 1.5* speed-up for the HT) - that gives an approx speed up within UF from 2000 to now of 22.5*58/1.4 = 932 which is lower than my 1640 estimate probably because of difference between rendering within UF and disk-rendering.

I am also cheating a bit because this system is more "up-to-date" for now than the system I had in 2000/2001 was for the time - I suspect it was only a 200MHz "Pentium MMX" so I guess you'd have to adjust the date for the old render time to about 18 months after such PCs were first in PC World etc.

[David Makin]

Disk I/O could also have slowed you down back them. Most likely the required swapping of main memory to disk.

UF has always rendered to disk in small sections so no memory issues (unless there are a very large number of layers and a lot of threads allowed) - so no disk loading is involved, only writes when each block is completed and they're probably asynchronous i.e. essentially just writes from PC RAM to Hard Drive RAM as far as the CPU is concerned.

[fractower]

I have been playing with fractals for over two decades now, and the time it takes to produce an image has not gone down at all. It always seems to take between a couple of seconds and a couple of hours. Granted a 100x100 2D monochrome and a 1200x1200 full color 3D rendering are different beasts.

[David Makin]

I have been playing with fractals for over two decades now, and the time it takes to produce an image has not gone down at all. It always seems to take between a couple of seconds and a couple of hours. Granted a 100x100 2D monochrome and a 1200x1200 full color 3D rendering are different beasts.

I agree with respect to the creation of an image - but not with the rendering of said image to quality print proportions
Also there's the matter of ease of production - modifying layers in UF at say 800*600 is now at best realtime and in general truly interactive, back in 2000 making a single change in a layer could require a tea break before you got to see the effect - apart from general improvements in artistry in the fractal community this is I think the main reason for improvements in Fractal Art overall i.e. that we spend more time trying things and less time waiting to see the result