home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / bsd / 2781 < prev    next >
Encoding:
Text File  |  1992-07-24  |  3.1 KB  |  63 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!laphroaig!cflatter
  3. From: cflatter@nrao.edu (Chris Flatters)
  4. Subject: Re: Jolitz 386BSD-0.1 -- floating point perform
  5. Message-ID: <1992Jul24.161646.22896@nrao.edu>
  6. Sender: news@nrao.edu
  7. Reply-To: cflatter@nrao.edu
  8. Organization: NRAO
  9. References: <l6qc51INN1gu@neuro.usc.edu>
  10. Date: Fri, 24 Jul 1992 16:16:46 GMT
  11. Lines: 50
  12.  
  13. In article l6qc51INN1gu@neuro.usc.edu, merlin@neuro.usc.edu (merlin) writes:
  14. >I have most of the US Army BRLCAD three dimensional CSG modeling and
  15. >distributed ray tracing system ported to the Jolitz 386BSD-0.1.  But,
  16. >I am getting only about one fifth of the floating point performance
  17. >previously measured using AT&T pcc and GNU gcc 1.4x on ATT UNIX SYSV.
  18. >
  19. >Does the compiler default to '387 emulation?  Is there some flag which
  20. >needs to be set to actually use the coprocessor?  Or are there reasons
  21. >386BSD-0.1 would exhibit relatively poor floating point performance?
  22.  
  23. I ran some checks last night and 386BSD is certainly exploiting the coprocessor.
  24. These are the results from the Plum2 benchmark (See section 8.2 of "C++
  25. Programming Guidelines" by Thomas Plum and Dan Saks.  The results are
  26. the average time for a register int, auto short, auto long and auto float
  27. operation and the average time to call and return from an empty function.
  28. Times are in nominal milliseconds (CLOCKS_PER_SEC was missing from <time.h>
  29. so I guessed a value of 100 --- I now think that it should have been 60.
  30. The tests were performed on a CompuAdd 325s (25MHz 80387SX CPU) with a
  31. Cyrix 83S87 FasMath coprocessor.
  32.  
  33.                        register      auto      auto  function      auto
  34.                             int     short      long  call+ret    double
  35.             386BSD gcc    0.178     0.448     0.474      1.62      4.94  
  36.          386BSD gcc -O    0.159     0.207     0.159      1.75      3.37  
  37.  
  38. The ration of floating-point time to auto long is 21.2 (with optimization)
  39. which is in the correct ball park for a 386SX/387SX system but a little
  40. on the long size.
  41.  
  42. As a control, I made a copy of the dist.fs disk with a compiled version of
  43. bench2 on it and booted it on my portable: a 16 MHz 80386SX system without
  44. a coprocessor.  The results were
  45.  
  46.                        register      auto      auto  function      auto
  47.                             int     short      long  call+ret    double
  48.          386BSD gcc -O    0.240     0.317     0.242      2.32       346  
  49.  
  50. Note that the ratio of of f-p time to auto long is now 1429.8 --- in other
  51. words emulation is more than 60 times slower than the coprocessor.  Unless
  52. BRLCAD uses very little floating-point I believe that the coprocessor is
  53. active on Alexander-James Annala's machine too (If Alexander-James wants to
  54. try these tests I'll send him the source code if he drops me a line).
  55.  
  56. For final comparison, I have some old figures from Linux with gcc 2.1.
  57. Using the register int time to place the results on the same scale as
  58. the 25MHz results above the mean time for a f-p operation was 2.09 usec
  59. without optimization and 0.936 usec at -O1 and above.
  60.  
  61.     Chris Flatters
  62.     cflatter@nrao.edu
  63.