gnu (02/17/83)
Anyone who thinks the 286 (80287 co-processor really) is fast on floats has not read the specs. Some timings from published Intel documents: Load 64-bit 10 us Store 64-bit 21 us Add/Sub 14/18 us Mul 32-bit 19 us Mul 80-bit 27 us Div 39 us While the chip can indeed multiply pretty fast, it takes it almost as long to store the result in memory as it does to do the multiply! And to load a value, add another, and store the result takes 45 us -- our 68000 software float is faster than that (tho: it is only operating on 32-bit floats). I can't understand how it can take them 21 us to store 4 words in memory. (Note, these timings are for 5MHz parts. 8MHz parts will be available "later"... I don't know if you can run a 5MHz 80287 with an 8MHz 80286, or even if 8MHz 80286's are available, but of course the 8MHz is what all the slanted comparison ads have been for.) John Gilmore, Sun Microsystems
gordonl (02/17/83)
A recent article claims that the 68K can emulate floating the floating point sequence: load multiply store faster than the Intel 286 Floating point chip (80287, I think its called) This is, of course, an interesting comparison. First, the comparison is invalid as the particular example is load/store intensive; something a coprocessor will naturally do less well. I'm sure the timings heavily favor the chip in a "real world" example. Further, John Gilmore was comparing the 32-bit floating point on the SUN with an 80-bit IEEE standard floating point chip! Those that have studied the chip know that theres a hell of a lot of work in supporing a IEEE standard floating point unit. There are several kinds of rounding, several kinds of infinity control, etc. I'm sure that the SUN package ignores these things. So long as we're going to compare apples and oranges I'd like to point out that my Heath H8 is faster than the Sun system becase the H8 can compliment a register faster than the 68K can. Its easy for systems software hacks (such as myself) to say "well, who cares about all that crazy floating point stuff?" Unfortunately, an important set of end-users of these machines are people who care very very much. The IEEE FP standard is not that complex because it was "designed by comittee", its that complex because the users of FP need those things. I'm sure we wouldnt like it if a bunch of FP hacks got together and speced out what an OS should look like and laughed at us when we complained... By the way, I thought that SUN was planning on marketing to scientific users. If thats so, they certainly have a wider package than the 32-bit version. Its important to compare the speeds of the "full strength" packages 'cause people who care about FP timings also (usually) care about precision. Can you fill us in, John? gordon letwin microsoft decvax!microsoft!gordonl
mark (02/23/83)
#R:microsof:-553700:zinfandel:8000003:000:664 zinfandel!mark Feb 18 17:10:00 1983 "What a pleasant register!" Seriously, your H8 can COMPLEMENT a register faster than a 68000? My manual says that the 68000 can complement an 8-bit or 16-bit register in 4 cycles; a 32-bit register in 6 cycles. Even on an 8 MHz 68000 (and SUN is shipping 10 MHz boards) this is 500 ns for 8- or 16-bits and 750 ns for 32-bits. I am assuming that the H8 is an 8080; can it really complement a register (or do any instruction) in less than 500 ns? Note that I am not claiming that the original comparison is valid, nor that yours is; I am just wondering about your claim, since I don't know much about H8s or 8080s. Mark Wittenberg ...!decvax!sytek!zehntel!mark
henry (03/01/83)
No offense to John Gilmore and the other folks at Sun, but comparing Sun's 32-bit software floating point to the IEEE-standard 8087/80287 is really comparing a Piper Cub to a Concorde. What are the error bounds of the Sun package? What is its roundoff algorithm, and why? Under what circumstances is it unsafe to use? (Alas, considering my past experience with software floating-point packages, a better question would probably be "under what circumstances is it safe to use?".) I don't doubt that the folks who did it were competent -- certainly the Sun people that I know are pretty good -- but designing floating-point arithmetic algorithms is a job for a numerical-mathematics expert, not a systems programmer. It really is too big and too hard a job for an amateur to do well. If somebody like (say) Kahan was numerical-mathematics consultant to the project, and is satisfied with the result, then I'd be happy to use it. Otherwise, I wouldn't trust the numbers coming out. Sorry. Actually, what I would like to see is a decent 68000 or 16032 system (the Sun is reasonable) with an 80[2]87 on it for floating-point work. The promised 68000 and 16032 floating-point auxiliaries are useful things, but they don't have quite the same awe-inspiring capabilities and specs as the Intel chips. A lot of people have cursed the 8087 for being impossible to interface to anything but an 8086; by the sounds of things, the 80287 may be easier to deal with. Henry Spencer U of Toronto
gnu (03/08/83)
Henry Spencer of U.T. is right about the relative capabilities of 32-bit software float and 64-bit (80-bit internally) IEEE float. 32-bit float is not for serious float work. It does OK for graphics, though. By the way, anyone have a decent exponential routine for the 8087? A friend of mine is doing the float math routines for an APL on the IBM PC and since the 8087 only does sorta exponential on a very limited domain, his routine turns out longer and slower than he expects is possible. The documentation claims the domain of the critical instruction is 0 to .5 whereas -.5 to +.5 would be reasonable -- if this is known to be a typo, please let me know. (What was this about Intel's "awe-inspiring" specs? At least the 68881 will have a true exponential instruction -- when it arrives in a year...) John Gilmore, Sun Microsystems