home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / sgi / 18593 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  4.2 KB
  1. Path: sparky!uunet!olivea!sgigate!odin!fido!knobi.munich.sgi.com!knobi
  2. From: knobi@knobi.munich.sgi.com (Martin Knoblauch)
  3. Newsgroups: comp.sys.sgi
  4. Subject: Re: Indigo R4000 vs. R3000 4D/35
  5. Message-ID: <1ijjo9INN6mf@fido.asd.sgi.com>
  6. Date: 8 Jan 93 10:07:05 GMT
  7. References: <1993Jan7.142834.7127@jarvis.csri.toronto.edu>
  8. Organization: Silicon Graphics, Inc.
  9. Lines: 79
  10. NNTP-Posting-Host: knobi.munich.sgi.com
  11.  
  12. In article <1993Jan7.142834.7127@jarvis.csri.toronto.edu>,
  13. corkum@csri.toronto.edu (Brent Thomas Corkum) writes:
  14. |> We just installed a R4000 upgrade in an Indigo and after running an
  15. |> in house application
  16. |> that is completely cpu bound I found that it was only 1.8 times
  17. |> faster on the Indigo
  18. |> than on a R3000 4D/35. Now, both have the same amount of memory and
  19. |> the application
  20. |> doesn't use that much. Is this right? Do I need to recompile on the
  21. |> R4000 with some
  22. |> magic compiler option (the code is in kr C)? I'm using the:
  23. |> 
  24. |> -cckr -float -O2
  25. |> 
  26. |> command line options.
  27. |> 
  28. |> Brent
  29. Brent,
  30.  
  31.   first of all, I would say that a factor of 1.8 between a 50MHz R4K
  32. and a 36MHZ R3K is not bad at all for an image that has not been
  33. specially optimized for the R4K. Remember that you should look at
  34. your computer as a whole system and not just the CPU. IO speed and
  35. memory access are very important and usually do not double in
  36. performance when you double the performance of your CPU.
  37.  
  38.   When you compare the different published performance numbers for the
  39. R4K Indigo and the 4D/35 you will find the following factors:
  40.  
  41. MIPS (R4K vs. 4D/35):  85 / 33 = 2.58
  42. MFLOPS:                16 / 6  = 2.67
  43. Specmarkcs (89/92 ?):  70 / 31 = 2.26
  44.  
  45.   That means your speedup of 1.8 is between 67% (FPU) and 80% (Spec ==
  46. "real application") of what you can achieve in the "best" case. Not to
  47. bad. You did not mention which compiler version you are using. With
  48. IRIX 4.0.5 there are two flavours of the SGI/MIPS compilers: 2.20 and
  49. 3.10. The 3.10 compilers yield better results and were in fact used to
  50. produce the published specmark results. If you have the 2.20 version
  51. and want to get the 3.10 version, contact your local SGI office.
  52.  
  53.   To get more speedup you can try a few things:
  54.  
  55. a) use '-mips2'. This makes use of special hardware instructuions
  56.    of the R4K processor (double word (8 byte) load/store, sqrt) and
  57.    can give some more speed, especially if you use a lot of sqrt
  58.    operations, or move a lot of double variables around.
  59. b) The primary cache of the R4K (8K+8K) is considerably smaller than
  60.    the cache of the 4D/35 (64K+64K). You should analyze your program
  61.    for its CPU usage pattern and look for code where you can
  62.    improve the usage of the cache. Usually in the inner loop of
  63.    the algorithm. You should use a small amount of data as often
  64.    as possible, opposed  to the 'vector strategy', where you try to
  65.    use a small peace of code on as much data as possible. Usually
  66.    programs that run excellent on Crays or other vector-supercomputers
  67.    need optimization for cache based machines.
  68. c) to help you in b), you might want to try the '-sopt' options to
  69.    f77 and cc (3.10 only). These options invoke a special source code
  70.    optimizer that can help you in things like 'loop unrolling' and
  71.    'blocking', techniques that usually improve the performance of
  72.    cache based architectures. Be careful. The optimizer rearranges
  73.    your source code. The results are not always correct. Usually
  74.    you should apply it only to really CPU critical parts of your
  75.    program, not to the whole source.
  76.  
  77.   I hope this helps to see your speedup of 1.8 in the right
  78. perspective.
  79.  
  80. Martin
  81. -- 
  82. +---------------------------------+----------------------------------+
  83. |Martin Knoblauch                 | Silicon Graphics GmbH            |
  84. |Application Support              | Am Hochacker 3 - Technopark      |
  85. |Silicon Graphics Computer Systems| W-8011 Grasbrunn-Neukeferloh, FRG|
  86. |                                 | Phone: (+int) 89 46108-179 or -0 |
  87. |                                 | Fax:   (+int) 89 46108-222       |
  88. +---------------------------------+----------------------------------+
  89. |Network: <knobi@sgi.com>         | V-Mail: 8935   | M/S: IMU-315    |
  90. +--------------------------------------------------------------------+
  91.