obrien@venus.ycc.yale.edu (10/02/90)
I'm trying to figure out my options for programming applications that require
floating point (80x87) calculations. I'm currently using Actor 3.0, but that
doesn't have floating point support. (Can anyone tell me whether Whitewater
plans to add floating point support?) My applications, typically engineering
computations of phase and chemical equilibria, require solving systems of
nonlinear algebraic equations, which are numerically intensive.
I'm further confused by my reading of Petzold, where (I'm trying to recall
from memory) he says that you can't use the floating point math library. I see
that there's a DLL supplied which appears to be related to the math chip, but
how is one supposed to use it? Are such topics covered in any detail in the
SDK manuals? To be more specific, do I have any option other than getting the
SDK (I don't have it - I use Actor, as I've mentioned above) and trying to
implement my compute-intensive code as a DLL?
My apologies if these are trivial questions, but not all applications can be
made to work with strings and integers!
========================================================================
OBRIEN%OBRIEN@YALEVMS Jim O'Brien, Dept. of Chem. Engrg.
OBRIEN%OBRIEN@VENUS.YCC.YALE.EDU Yale University
OBRIEN@YALEVMS 2159 YS, New Haven CT 06520, U.S.A.
OBRIEN@VENUS.YCC.YALE.EDU +1 203 432 4382 (days)
>INTERNET:OBRIEN@VENUS.YCC.YALE.EDU (from Compuserve Easyplex)
========================================================================burgoyne@eng.umd.edu (John R. Burgoyne) (10/07/90)
In Article: 5855 of comp.windows.ms Jim O'Brien writes: >I'm trying to figure out my options for programming applications >that require floating point (80x87) calculations. I'm currently >using Actor 3.0, but that doesn't have floating point support. >(Can anyone tell me whether Whitewater plans to add floating point >support?) My applications, typically engineering computations of >phase and chemical equilibria, require solving systems of >nonlinear algebraic equations, which are numerically intensive. I don't use Actor, but this answer is relevant. I am solving about the same type of mathematical problem for a different physical phenomena with a Win 3.0 program using MS C 6.0 and the SDK. The machines we run the software on are 80386 based with either 25 MHz or 20 MHz clock speed. Every machine has an 80387 of the appropriate clock speed. The coprocessors were purchased for the normal reasons. The instructions for how to get your application to link with and use the appropriate 80387 libraries are given on page 2-12 of Microsoft Windows Programming Tools (New for Version 3). I discovered the additional words of wisdom well into the project, and was delighted at the prospect of having my application now run at much greater speed since we hadn't really been using the coprocessor yet. AND . . . . . there was no speed improvement. We checked and rechecked to confirm that we were in fact using the 80387s now that we had the proper linking instructions. WHAT'S WRONG HERE? ^^^^^^^^^^^^^^^^^^ It turns out that the 80386 handles most floating point math pretty well all by itself, but the communication between 80386-80387 is not so efficient. This is one of the reasons why the 80486 incorporates the 80387 on chip. With previous generations of Intel microprocessors, (80286, 808x) the math coprocessors (80287, 8087) made a great difference because the processors weren't too swift at floating point math. SO WHY DO I NEED AN 80387? ^^^^^^^^^^^^^^^^^^^^^^^^^^ Some transcendental functions I.E. Logarithms and Trigonometric functions are computed in 1/80th the number of clock cycles using an 80387. If you calculate enough of them, you will notice a speed improvement. This is the case for CAD programs which do rotations of objects. For solving mathematical problems which are only algebraic equations, I don't think it is possible to get a speed improvement by using the 80387. With older microprocessor architectures, you should gain a performance improvement by using an 80287 or an 8087. I haven't mentioned accuracy, which may or may not be one of your reasons for wanting to use a coprocessor. The accuracy of the emulator model is more than enough (about 5 orders of magnitude) for my application. Your mileage may vary. As far as I'm concerned, my investment in the 80387s was a total waste, and that money could have been put to much better use. *-----------------------------------------------------------------------------* | Robert Burgoyne CALCE Center for Electronics Packaging | | Industrial Liaison University of Maryland | | burgoyne@eng.umd.edu College Park, MD 20742 | | (301)-405-5323 | | Compu$erve: 76234,2425 | | | | "Improving the quality of electronics hardware through software | | development and research into physics of failure models." | | | | I speak for myself, CALCE has enough people speaking for it already. | *-----------------------------------------------------------------------------*
pnl@hpfinote.HP.COM (Peter Lim) (10/09/90)
> > It turns out that the 80386 handles most floating point math > pretty well all by itself, but the communication between > 80386-80387 is not so efficient. This is one of the reasons why the > 80486 incorporates the 80387 on chip. With previous generations of > Intel microprocessors, (80286, 808x) the math coprocessors (80287, > 8087) made a great difference because the processors weren't too > swift at floating point math. > This is not quite correct. The 8087 and 8088 is a great combination. Both CPU and interface speed is just right to give lots of improvement. The 80287 and 80286 is very bad combination. The CPU speed is substantially increase over the 8088 whereas the interface speed is not. In fact, for some application, 80287 actually SLOW DOWN the 80286 .... according to an old BYTE magazine. The 80387 and 80386 while not as well matched as the 8087 and 8088; is definitely much better matched than 80287 and 80286. All in all, it depends on the application you are running ? For most application, 80x87 will almost not help at all. For CAD, engineering simulation, FFT stuffs, the speed gain is very substantial. For spreadsheet, the speed gain is very mediocre; you'll be lucky to get double the speed. Another 2 cents' worth. 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, __\@/__ ... also at: pnl@hpfipnl.HP.COM Singapore 0410. SPLAT ! #include <standard_disclaimer.hpp>