baer@uwovax.uwo.ca (03/09/91)
Re: Intel 387 chips
I understand that the 387 chip is supposed to be a big improvement
over the 287 chip. I have heard manufacturers claim that it works
up to 5x as fast (though some of this difference will evidently
be attributable to clock speed differences).
I believe this claim is overblown. I tried running a math-intensive
application on 2 machines I own. One is a 286 w/ 287 , and the
other is a 386sx w/387sx. (I also ran the application on a 386dx-20/no
cache with a 387 chip). The application is *quite* math intensive:
although it runs without the co-processor, in earlier tests with
other machines, I ascertained that it speeds up by a factor of
between 5 and 10 with the math chip (vs. no chip on an equivalent
machine). The application involves stats work probably originally
written in Fortran -- with a lot of matrix inversions/multiplications,
etc. Probably little or no trig. Here are the timings:
286 10mHz. w/ 287 - math chip is rated at 8mHz.; not sure if
the clock speed of the chip is 8mHz. or 10*(2/3) = 6.67 mHz.
1273 seconds
386sx 16mHz w/ 387sx - 623 seconds
386dx 20mHz no cache w/ 387 456 seconds
Now, most of the differences above can be attributed to speed differences
in the clock speed at which the chips were running: the 286 takes twice
as long, but we'd expect that from a chip that's running at half the
speed. I expected a bigger speed difference between the sx and the dx
given the fact that the application does gobble a bit of memory --
after all, 456/623 = .73 -- approximately the speed ratio between
20 mHz. and 16 mHz. (though, in fairness, the absence of a cache for
the dx could have slowed it down).
I'm not saying that the 387 chip mightn't be faster for certain
applications (correcting for clock speed) -- I've read that its improvements
for trig functions are important, and this could be important for CAD
applications (though the overall speedup in many CAD applications with
a math chip -- vs. without -- is nowhere near the overall speedup
with math intensive applications grinding away with matrix inversion
routines).
--
---------------------------------------------------------------------
Douglas Baer,
University of Western Ontario, London, Canada N6A 5C2
Internet: BAER@UWO.CA Bitnet: BAER@UWOVAXplim@hpsgwp.sgp.hp.com (Peter Lim) (03/11/91)
/ baer@uwovax.uwo.ca / 6:57 am Mar 9, 1991 / writes:
$ Re: Intel 387 chips
$ I understand that the 387 chip is supposed to be a big improvement
$ over the 287 chip. I have heard manufacturers claim that it works
$ up to 5x as fast (though some of this difference will evidently
$ be attributable to clock speed differences).
$
I have one data point. Running the SST test program, 287 in a zero-
waitstate 12 MHz 286 machine register 280 Kilo-Wheatstones. 387 in
a one-waitstate (interleaved memory) 25 MHz 386 machine register
1,200 Kilo-Wheatstones. So, not quite 5x unless you don't count
the clock speed ratio :-). ... But then, I believe this program
doesn't make use of 387 specific instruction either.
$ Now, most of the differences above can be attributed to speed differences
$ in the clock speed at which the chips were running: the 286 takes twice
$ as long, but we'd expect that from a chip that's running at half the
$ speed. I expected a bigger speed difference between the sx and the dx
$ given the fact that the application does gobble a bit of memory --
$ after all, 456/623 = .73 -- approximately the speed ratio between
$ 20 mHz. and 16 mHz. (though, in fairness, the absence of a cache for
$ the dx could have slowed it down).
$
Yeap ! Running MesSy-DOS at the same clock frequency, a 286 would run
faster than a 386-SX because 386 machine usually has 1 waitstate unless
it is a cached machine.
Regards, . .. ... .- -> -->## Life is fast enough as it is ........
Peter Lim. ## .... DON'T PUSH IT !! >>>-------,
########################################### :
E-mail: plim@hpsgwg.HP.COM Snail-mail: Hewlett Packard Singapore, :
Tel: (065)-279-2289 (ICDS, ICS) |
Telnet: 520-2289 1150 Depot Road, __\@/__
Singapore 0410. SPLAT !
#include <standard_disclaimer.hpp>