home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text3581.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  3.5 KB  |  85 lines
  1. >>>>> "Michelle" == Michelle Pankowski <d9060469@helios.usq.edu.au> writes:
  2. In article <Pine.HPP.3.91.960710223755.28583C-100000@helios.usq.edu.au> Michelle Pankowski <d9060469@helios.usq.edu.au> writes:
  3.  
  4.  
  5.     Michelle> Here are my Executor 2 speedo test results under linux
  6.     Michelle> 2.0 and Windows95. (on a 486dx2-50 with a slooo...w hard
  7.     Michelle> drive)
  8.  
  9.     Michelle>            Windows95 linux-svga linux X
  10.     Michelle> video        7.6        4.6    2.7
  11.     Michelle> cpu        8.8        7.9    7.9
  12.     Michelle> disk        2.2        2.0    2.0
  13.  
  14.     Michelle> My question is this;
  15.  
  16.     Michelle> Linux 2.0 is linux at its finest, all 32 bit and really
  17.     Michelle> fast drivers, (tested with the fastest X server
  18.     Michelle> available too).  Windows95 is all 16 bit with a .hfv
  19.     Michelle> volume to slow thing down as well...
  20.  
  21.     Michelle> So why the hell is it so much faster in every damn area,
  22.     Michelle> and would it completely destroy Linux when the VCPU and
  23.     Michelle> a 32 bit port comes on line?
  24.  
  25. It's hard to say without looking carefully at your system.  One thing
  26. to bear in mind is that the Linux system might have been doing other
  27. things at the time, since it's sometimes hard to tell what is going on
  28. behind your back.  Here are the results of me running Speedometer 3.23
  29. under DOS mode of Windows '95 and under Linux (kernel 2.0.3) on the
  30. same 133 MHz P5 laptop.  All tests were run for 10 iterations:
  31.  
  32.         Linux X         DOS/Windows'95        
  33. cpu        38.444        37.608
  34. video         7.443        19.593
  35. disk        18.011         2.445
  36. math        80.777        81.695
  37.  
  38. I didn't run Linux-SVGA, because currently SVGAlib doesn't know that
  39. the Cirrus 7548 chip can be driven like a Cirrus 5428, and when it
  40. does, that will make a big difference.
  41.  
  42. On my system, Linux did slightly better in CPU and slightly worse in
  43. math.  The video difference is the difference of being able to
  44. directly access the screen, and the disk difference is that under
  45. Linux, when writing to a non-HFV, we don't flush the disk cache when
  46. new files are created, so every iteration of the disk test after the
  47. first one just whizzes by.
  48.  
  49.     Michelle> Maybe you should write a 16 bit version for Linux to see
  50.     Michelle> if you could make it go faster. (Yes, I know, it was a
  51.     Michelle> joke)
  52.  
  53.     Michelle> I only tried linux to see if I could wring a few more
  54.     Michelle> bits/sec out of Executor. Tried and failed that is;)
  55.  
  56. If you run multiple iterations you might see a dramatic speedup
  57. (depending on how much free memory you have) in the disk access.  Once
  58. we support (and the appropriate X servers support) direct video access
  59. under X, then the video speeds will equalize.
  60.  
  61.     Michelle> Makes you wonder why the linux/os2'ers are always
  62.     Michelle> bagging Windows95.  It is also by far the easiest
  63.     Michelle> platform to print out PostScript files when you don't
  64.     Michelle> have a postscript printer.
  65.  
  66. We drive our non-PostScript printer using GhostScript.  Granted, it
  67. took a little fiddling to get it set up correctly, but it works fine
  68. for us, although most of us came from a UNIX background.
  69.  
  70. I prefer Linux, but I certainly don't claim that it's the right
  71. solution for everyone -- heck, I don't even claim that Executor is the
  72. right solution for everyone, and I have a vested interest in Executor.
  73.  
  74.     Michelle> Just the facts maam...  Michelle;)
  75.  
  76. I'm still surprised that W'95 gave you a 10% gain in CPU.  One thing
  77. that could conceivably be slowing you down would be if you were short
  78. on memory and Linux was doing various disk stuff (writing old dirty
  79. buffers or prefetching) behind your back as you were running the
  80. benchmark.
  81.  
  82. --Cliff
  83. ctm@ardi.com
  84.  
  85.