home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / ibm / pc / misc / 10955 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.5 KB
  1. Path: sparky!uunet!usc!wupost!waikato.ac.nz!aukuni.ac.nz!stuartw
  2. Newsgroups: comp.sys.ibm.pc.misc
  3. Subject: Re: 486/50's vs Sun 2's
  4. Message-ID: <1992Jul29.025353.7697@ccu1.aukuni.ac.nz>
  5. From: stuartw@ccu1.aukuni.ac.nz (Stuart Woolford)
  6. Date: Wed, 29 Jul 1992 02:53:53 GMT
  7. References: <1992Jul27.054828.21618@monu6.cc.monash.edu.au>   
  8.  <1992Jul27.173410.19470@leland.Stanford.EDU> <1992Jul27.213527.26349@ccu1.aukuni.ac.nz> <1992Jul28.021758.3111@infonode.ingr.com>
  9. Organization: University of Auckland, New Zealand.
  10. Lines: 44
  11.  
  12. bbrown@infonode.ingr.com (Bailey Brown) writes:
  13.  
  14. >stuartw@ccu1.aukuni.ac.nz (Stuart Woolford) writes:
  15.  
  16.  
  17. >>perhaps this would have more to do with the key-repeat rate on the 486 ??
  18. >>also: a 486 running 32bit OS/2 2.0 programs is about 4 time faster on
  19. >>integer code ( let alone floating point ) than the same machine under dos.
  20. >>(ie: think about what you are actually measuring !!!)
  21.  
  22. >I can't see how this is possible.  I can see how recompiling stuff for
  23. >32-bit *might* make it up to twice as fast, but not 4 times as fast. Please
  24. >justify this.  I, myself, have ported DFLAT (the text mode user
  25. >interface lib from Dr. Dobb's Journal) and it's sample application,
  26. >to 32-bit extended dos and have noticed no speed increase at all.
  27. >And this code is full of far pointers.  I have seen some small, tight
  28. >programs (gif decoder code) that does not benefit at all from
  29. >32-bit.  The pointers are all near and the words used are all 16bit, and
  30. >there is no reason to make them 32-bit.  From my experience, the 
  31. >advantages of having 32 bits are more in the form of having a large
  32. >flat address space, and much less in the form of more speed.
  33.  
  34. no.. but with a poor compiler the speedup will be 1-2x..
  35. a 486 is not just a 386 with a numeric copro..It has a complex pipeline, and
  36. gains significantly from instruction reordering on even 386 code...
  37. ( note: this requires the use of a compiler with 486 support, like Watcom C9 )
  38. so you get:
  39.     1) 1-2x from moving to 32bit for many app's.
  40.     2) 0.5-1x from moving to native-mode
  41.     3) 3-5x from using '486 code reorganisation.
  42.  
  43. so the total moving from 286 code on a 486 to 486 code is about 3-10x with a
  44.     GOOD COMPILER!!!
  45.  
  46. note: 486 mode does not stop it running on a 386. it just reorders the code to
  47.     stop pipeline stalls..also, pipeline may not be technically correct,
  48.     but the effect is the same as pipeline stalls..
  49.  
  50. -------------------------------------------------------------------------------
  51. stuartw@ccu1.aukuni.ac.nz
  52.  
  53.  
  54.             >>>>In VI Where Available<<<<
  55. -------------------------------------------------------------------------------
  56.