In article <548C8BC1.1010903@t-online.de>, "Multifrac@t-online.de" <Multifrac@t-online.de> writes:

Am 13.12.2014 um 18:52 schrieb Tony Hanmer:

...

I sympathize with the lack of response you're getting for your amazing work. Thank you, Tony. I still wait for information about the generation speed on other systems, especially Windows7, 32bit.

The DOS program is absolutely the slowest way to generate an image. It is using 16-bit code which is the slowest execution path on any modern CPU. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

It would be interesting to objectify the discussion about speeds on different platforms. It certainly is possible to make informed (and strong) statements about what the performance should be under various environments, but there is nothing like actual tests. Of course trying to make meaningful benchmarks is fraught with difficulties and challenges, I'm not saying it would be easy. What might be useful is to find a fractal that runs properly on several pieces of software and compare on one machine under different environments. Or maybe several fractals, one that is running from an assembler implementation of a built-in fractal in the DOS Fractint and maybe one that uses the parser with a challenging formula. Run these two under naked DOS, Windows 95 or 98 or XP, and several virtual environments. Would be nice to find a fractal that also runs under Iterated Dynamics (easy since it runs nearly everything Fractint runs) and Manpwin or even Fractint for Windows (though the later is still 16 bit and so subject to Rich's hypothesis about 16 bit code being slow). Be aware that DOSBox was originally developed for gamers running old games, so it has mechanisms for intentionally slowing things down so they don't run too fast. For our purposes it needs to be set to run as fast as it can. See: http://www.dosbox.com/DOSBoxManual.html#SpeedHelpI t would be informative to compare DOSBox with other virtual environments on the same hardware. I am moving on implementing the wiki at Fractint.net. Not quite done and no content up yet, but this would be the perfect place for this sort of discussion and results. The holidays are looming, so we are probably talking January for the wiki to be operational. Tim

*CPU Core (speed up)* On x86 architectures you can try to force the usage of a dynamically recompiling core (set core=dynamic in the DOSBox configuration file). This usually gives better results if the auto detection (core=auto) fails. It is best accompanied by cycles=max. But you may also try using it with high amounts of cycles (for example 20000 or more). Note that there might be games that work worse/crash with the dynamic core (so save your game often), or do not work at all! I always set Cycles=max, but possibly you get better results defining a fixed amount as explained. It´s subject to testing. Petta

Timothy Wegner wrote:

First step would be picking a couple of fractals. Suggestions? I suggest one built-in (maybe a zoom in of the standard mandelbrot) and one a formula. Is there a nice complex formula that runs on Fractint, Iterated Dynamics, and Manpwin?

I agree. And as to the complex formula, how about one from Sylvie Gallet, as in the following: comment { Because of its large size, this formula requires Fractint version 19.3 or later to run. It uses Newton's formula applied to the equation z^6-1 = 0 and, in the foreground, spells out the word 'FRACTINT'. } fractint [float=y periodicity=0] {; Sylvie Gallet [101324,3444], 1996 ; requires 'periodicity=0' z = pixel-0.025 , x=real(z) , y=imag(z) , x1=x*1.8 , x3=3*x ty2 = ( (y<0.025) && (y>-0.025) ) || (y>0.175) f = ( (x<-1.2) || ty2 ) && ( (x>-1.25) && (x<-1) ) r = ( (x<-0.9) || ty2 ) && ( (x>-0.95) && (x<-0.8) ) r = r || ((cabs(sqrt(|z+(0.8,-0.1)|)-0.1)<0.025) && (x>-0.8)) r = r || (((y<(-x1-1.44)) && (y>(-x1-1.53))) && (y<0.025)) a = (y>(x3+1.5)) || (y>(-x3-1.2)) || ((y>-0.125) && (y<-0.075)) a = a && ((y<(x3+1.65)) && (y<(-x3-1.05))) c = (cabs(sqrt(|z+0.05|)-0.2)<0.025) && (x<0.05) t1 = ((x>0.225) && (x<0.275) || (y>0.175)) && ((x>0.1) && (x<0.4)) i = (x>0.45) && (x<0.5) n = (x<0.6) || (x>0.8) || ((y>-x1+1.215) && (y<-x1+1.305)) n = n && (x>0.55) && (x<0.85) t2 = ((x>1.025) && (x<1.075) || (y>0.175)) && ((x>0.9) && (x<1.2)) test = 1 - (real(f||r||a||c||t1||i||n||t2)*real(y>-0.225)*real(y<0.225)) z = 1+(0.0,-0.65)/(pixel+(0.0,.75)) : z2 = z*z , z4 = z2*z2 , n = z4*z2-1 , z = z-n/(6*z4*z) (|n|>=0.0001) && test } Later, P.N.L.

In article <20141214042822.QZP08.294400.root@dnvrco-web07>, <gnome@hawaii.rr.com> writes:

Of course, the whole of DOS Fractint can fit entirely in L1 cache on modern processors. That could speed things up!

It won't make up for the fact that every single instruction is taking the slowest path in the CPU hardware. If you're running it inside some sort of virtual machine, it's even worse. Most people have reported that the Win32 version using C runs faster then the 16-bit version using assembly. It's not 1990 anymore. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>