Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!psuvax1!news From: melling@cs.psu.edu (Michael D Mellinger) Newsgroups: comp.windows.ms.programmer Subject: Re: NeXT or What MS Does Wrong! Message-ID: Date: 20 May 91 04:31:15 GMT References: Sender: news@cs.psu.edu (Usenet) Organization: Penn State Computer Science Lines: 25 In-Reply-To: Morrie_Wilson@p16.f8.n343.z1.fidonet.org's message of 6 May 91 16: 04:16 GMT Nntp-Posting-Host: sunws9.sys.cs.psu.edu In article Morrie_Wilson@p16.f8.n343.z1.fidonet.org (Morrie Wilson) writes: Actually, the skinny I've heard is that there are problems with the yields of the 486 processors with the built in co-processors. So Intel came up with the neat idea of being able to disable the co-processor and sell the result as a 486sx. In actuality, the co-processor does not lend a whole lot of speed to most applications. E.G. Lets say an application is 10% floating point intensive. Let say the coprocessor can speed up that portion 10X. The result is that with the co-processor it runs in 91% of the time, for a total savings of 9%. Like a speadsheet recalculation? How about graphics? Are all the calculations done in integer math? Do Adobe Type Manager or True Type fonts require floating-point calculations? I'm not sure, but I think that there should be enough "real" world applications that it would be nice to have a math co-processor. And when the application does require a co-processor it's going to be several(20? 30? 100 times?) times slower w/o it. -Mike