home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.os.os2.programmer:4487 comp.os.os2.misc:28423
- Newsgroups: comp.os.os2.programmer,comp.os.os2.misc
- Path: sparky!uunet!grebyn!daily!richk
- From: richk@grebyn.com (Richard Krehbiel)
- Subject: Re: Does math coprocessor speed up GUI (here: OS/2 presentation mgr)?
- Message-ID: <1992Aug27.213432.27548@grebyn.com>
- Organization: Grebyn Timesharing
- References: <17fuahINN1tl@iraul1.ira.uka.de> <19920826.074333.779@almaden.ibm.com> <1992Aug27.102130.9367@cam-orl.co.uk>
- Date: Thu, 27 Aug 1992 21:34:32 GMT
- Lines: 20
-
- In article <1992Aug27.102130.9367@cam-orl.co.uk> thg@cam-orl.co.uk (Tim Glauert) writes:
- >In article <19920826.074333.779@almaden.ibm.com>, ADUNSMUI@TOROLAB6.VNET.IBM.COM (Al Dunsmuir) writes:
- >|> Having said that, having a math coprocessor (especially a tightly coupled
- >|> one as implemented in the 486) can speed up OS/2 applications. For example,
- >|> IBM's X-Windows server (PM screen interface for TCP/IP) achieves __dramatic__
- >|> performance gains when a math coprocessor is present.
- >
- >I wonder why that is? The MIT X sample server only uses floating-point code
- >where the integer equivalent is likely to be slower, and only for primitives
- >such as arcs and wide lines.
-
- They are probably determining whether integer code is likely to be
- slower on *workstations*, where floating point hardware is the norm
- and is probably only slower than integer code by a factor of two or
- three. On a 386 without a 387, floating point code is slower by
- several orders of magnitide, worse if the 387 instructions are being
- trapped and emulated.
- --
- Richard Krehbiel richk@grebyn.com
- OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
-