[comp.sys.ibm.pc.hardware] 249 hours to generate MANDELBROT image on 286

rnollman@maxzilla.encore.com (Richard Nollman) (05/01/91)

Recently, using FRACTINT,I generated a Mandelbrot image on my 286
clone that took 239 hours.  I set the number of iterations to 1000
(for those of you who are familiar with FRACTINT).  The floating point
flag was turned on by FRACTINT and I do not have a math coprocessor.  I
told a friend about it and he was puzzled.  He has a 386 and the most
time a Mandelbrot image took to generate was about 14 hours and this
was deep into the set (billions magnification).  I saved my image on
diskette and gave it to him.  He generated the exact same image on his
computer in about 3 hours.  We surmised that the cumulative effect of
many different factors accounted for the large difference in
calculation times.  Given the differences in our machines (shown
below), does the time difference make sense?  (We are trying to
determine if there is something in FRACTINT that may be configured
incorrectly on my machine).


	my 286			his 386
	------			-------

	8 mghz			33 mghz

	no cachex		64K cache

	16-bit I/O bus		32-bit I/O bus

	no math coprocessor	math coprocessor

	249 hours to		3 hours to calculate
	  calculate


Where should I best spend my money to upgrade (best bang for buck)?
Where am I losing the most processing speed?

Thanks.

Rich Nollman

jal@acc.flint.umich.edu (John Lauro) (05/02/91)

In article <14697@encore.Encore.COM> rnollman@maxzilla.encore.com (Richard Nollman) writes:
>
>	my 286			his 386
>	------			-------
>
>	8 mghz			33 mghz
>
>	no cachex		64K cache
>
>	16-bit I/O bus		32-bit I/O bus
>
>	no math coprocessor	math coprocessor
>
>	249 hours to		3 hours to calculate
>	  calculate
>
>
>Where should I best spend my money to upgrade (best bang for buck)?
>Where am I losing the most processing speed?
>

The most bang for the buck in terms of fractint would be
to get a math coprocessor.  (A 4mhz PC with an 8087 is
several times faster than an 80287 without for floating point
calculations.)

If you want to really improve speed, get a 486.

draper@buster.cps.msu.edu (Patrick J Draper) (05/02/91)

In article <1991May2.124542.21865@engin.umich.edu> jal@acc.flint.umich.edu (John Lauro) writes:
>In article <14697@encore.Encore.COM> rnollman@maxzilla.encore.com (Richard Nollman) writes:
>>
>>	my 286			his 386
>>	------			-------
>>
>>	8 mghz			33 mghz
>>
>>	no cachex		64K cache
>>
>>	16-bit I/O bus		32-bit I/O bus
>>
>>	no math coprocessor	math coprocessor
>>
>>	249 hours to		3 hours to calculate
>>	  calculate
>>
>>
>>Where should I best spend my money to upgrade (best bang for buck)?
>>Where am I losing the most processing speed?
>>
>
>The most bang for the buck in terms of fractint would be
>to get a math coprocessor.  (A 4mhz PC with an 8087 is
>several times faster than an 80287 without for floating point
>calculations.)
>
>If you want to really improve speed, get a 486.

Isn't there an option to use either integer or floating point math? If
so, a coprocessor wouldn't save you anything in the integer mode.

The time gap is WAY too large here to be explained by clock speed or the
higher efficiency of a 386. As everyone knows, a 386 is only marginally
faster than a 286 at the same clock speed, running a 16bit system like
DOS.

I'll bet that your friend's 386 is coonfigured for integer math, and the
286 machine is configured for floating point math.


------------------------------------------------------------------------
Patrick Draper     "College is supposed to prepare you for the future,
cps.msu.edu               but all my future's behind me." 
draper@cps.msu.edu      -- My GrandPa, age 85, Fall 1990 graduate
                           of Western Michigan University 
------------------------------------------------------------------------

rick@always.com (Rick Wagner) (05/03/91)

Probably any 386 class machine (even the slowest of 'SX's) would
probably beat your '286 for this test.  This is because FRACTINT will
use 32 bit integer arithmatic on a 386* machine; which in this
application is substantailly faster than floating point; even compared
to using a math co-processor.  

	--rick

-- 
===============================================================================
Rick Wagner / Always Technology			email: rick@always.COM
31336 Via Colinas, Suite 101			Voice: 1-818-597-1400
Westlake Village, CA 91362			Fax: 1-818-597-1496

david@kessner.denver.co.us (David Kessner) (05/03/91)

In article <1991May2.142752.23003@msuinfo.cl.msu.edu> draper@buster.cps.msu.edu (Patrick J Draper) writes:
>Isn't there an option to use either integer or floating point math? If
>so, a coprocessor wouldn't save you anything in the integer mode.
>
>The time gap is WAY too large here to be explained by clock speed or the
>higher efficiency of a 386. As everyone knows, a 386 is only marginally
>faster than a 286 at the same clock speed, running a 16bit system like
>DOS.
>
>I'll bet that your friend's 386 is coonfigured for integer math, and the
>286 machine is configured for floating point math.

I have written integer code on the 386 that generates mandelbrot sets, and
here are some of my observations:

	Integer code is less precise than floating point code but is
	two to three times faster than a 387.  About the same as a Weitek.
	The biggest reason for this is the 386 has 32 bit registers which
	greatly speeds things up over the 286.  Fractint uses the 32 bit
	registers.

	My Mandelbrot program used integers, but was otherwise BRUTE FORCE.
	It used no other optimizations, like edge detection.  Still, it
	could genererate, on the average, an 800x600 picture at 2000 
	iterations in about 40 min!  This is at varying levels of zoom but
	the number of iterations tells just how complex the image was.
	320x200, 256 iteration pictures were done in less than 5 min.


If the 286 was indeed using floating point math without a FPU, it could 
take days.  Shift to integer and it will speed up by an order of magnatude.
Don't bother with an FPU, it's a waste of money (if all you are doing is
fractals).  A CPU upgrade will have the biggest effect.

The time given for the 386 is normal for floating point code-- but will be
much faster when using integer math (Fractint is about as fast as my program).

Mandelbrots is where the difference between the 286 and 386 is very evident.
The biggest reason for this is the 32 bit registers for integer math, and the
32 bit data-bus for moving those floatig point numbers to and from RAM.  When
32 bit registers are used, the 386 is three-four times faster than the 286
at the same clock speed (at least where Mandelbrots are concerned).

>Patrick Draper     "College is supposed to prepare you for the future,
>cps.msu.edu               but all my future's behind me." 
>draper@cps.msu.edu      -- My GrandPa, age 85, Fall 1990 graduate
-- 
David Kessner - david@kessner.denver.co.us            | do {
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) |    . . .
If you cant flame MS-DOS, who can you flame?          |    } while( jones);

edhall@rand.org (Ed Hall) (05/04/91)

In article <1991May2.142752.23003@msuinfo.cl.msu.edu> draper@buster.cps.msu.edu (Patrick J Draper) writes:
>Isn't there an option to use either integer or floating point math? If
>so, a coprocessor wouldn't save you anything in the integer mode.
>       .       .       .       .
>I'll bet that your friend's 386 is coonfigured for integer math, and the
>286 machine is configured for floating point math.

I believe that the later versions of fractint will use 32-bit integer
instructions on a '386.  Even without a coprocessor, all other things
being equal this can easily be a factor of 2 (adds) to 4 (multiplies)
faster.  Also, the '286 is hard pressed to hold in registers
everything needed in a mandelbrot inner loop (at two 16-bit registers
per value); the 32-bit registers on the '386 can do this easily.
Register-to-register operations are about twice as fast as
register-to-memory, on average.  Finally, the shifts necessary for
such fixed-point arithmetic are a lot faster on a '386, which has a
barrel-shifter, than the '286, which has to consume extra cycles for
each bit shifted.  Oh, and one last thing: the '386 uses an
"early-out" multiplication algorithm, where multiply cycles are only
performed until the multiplier runs out of significant bits.

So I'd give the '386 a factor of eight or so based upon architecture
alone.  That times 4 for the clock still falls far short of explaining
a 100:1 difference.  However, if the calculations were floating-point,
100:1 sounds small for a non-coprocessor 8MHz '286 versus a 33MHz '386
with coprocessor.  On some floating-point code I once ran for waveform
synthesis, a non-CP 10MHz '286 was about 200 times slower than a
25MHz '386 with CP.  (I'm assuming that the mandelbrot code is as
FP-intensive, which it should be.)

		-Ed Hall
		edhall@rand.org