Math Coprocessor?

[strollin]

Can anyone point me to some software that runs on 8088 or 80286 machines where adding an 8087 or 80287 makes any difference?

Over the years, I've had machines with and without a math coprocessor and could never discern any performance difference between the two. I imagine there has to be software out there, just none of the software I typically use.

Years ago when I was a big user of Lotus 1-2-3 on an 8088 machine, I was given an upgrade of Lotus from 1.x to 2.0. The new version took about 2-3 times longer to load any of my spreadsheets from disk. I complained and demanded my old version back but was told that the old disks had already been destroyed. As compensation, I was given an 8087 to add to my machine. I installed the 8087 but was very disappointed when I could not tell any difference in calc speed on any of my spreadsheets.

Later when the 80386 came out, I couldn't tell any difference in performance between the 386DX and the 386SX, the difference being the the DX had the math coprocessor built-in.

I suppose some fractal generator or something like that can use the math coprocessor to it's advantage but fractal generator's are not particularly useful software and I never run them.

 

[TNC]

Later when the 80386 came out, I couldn't tell any difference in performance between the 386DX and the 386SX, the difference being the the DX had the math coprocessor built-in.

Also the DX had no coprocessor inside. The SX had a limitation to 16 MB of adressable ram (24 bit) and a 16 bit limitation to other peripherials. For a programmer there is no difference to a DX.

 

[mbbrutman]

The 8087, 80287, and 80387 make the biggest difference under the following conditions:

• The software is doing floating point arithmetic
• The software or compiler runtime the software uses knows to check for a coprocessor

Normal DOS software does primarily integer math. 8, 16 or 32 bit quantities get added and multiplied and the data types are integer. The processors are designed to do these operations quickly.

Floating point is hard to do, hence the reason it was not included on the early processors. If you BASIC program or your spreadsheet wanted to divide 2 by 3, it had to be done using software routines which are orders of magnitude slower than having hardware that can do it.

The general approach was to assume that your machine did not have a floating point coprocessor, and to do all of the floating point math in a software library. Good software would check for the existence of the floating point coprocessor and use that instead, providing an incredible speedup.

Lotus 1-2-3 should benefit from a co-processor if you have a big spreadsheet with lots of floating point numbers in it. If you are using it as a mini-database and storing text in the cells a co-processor will do nothing for you. Programs like fractal generators, AutoCAD, ray tracers, etc. absolutely need the co-processor.


Mike

 

[Chuck(G)]

Add to the list "any spreadsheet program for x86". Supercalc from Sorcim is certainly one (I wrote the math package, so I should know). However, unless your spreadsheets involve a lot of floating-point math (particularly with transcendentals), the overhead of other tasks will swamp any gain out.

3D graphics-intensive programs use the NDP--doing high-quality graphics involves heavy use of transcendental functions and an NDP can make a huge difference.

 

[kb2syd]

I have the source code somewhere for a random walk particle trace in groudwater modelling. On my 8086 it would take 4 hours to run. With an 8087, less than 30 minutes. This was in Fortran 77 and running at 4.77 MHz. It took about 1.5 hours using just a 286 in an accelerator card on the same machine.

 

[strollin]

Also the DX had no coprocessor inside. The SX had a limitation to 16 MB of adressable ram (24 bit) and a 16 bit limitation to other peripherials. For a programmer there is no difference to a DX.

Oops! You're right it was the 486dx and 486sx that the diff was the match coprocessor.