home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10582 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  2.4 KB
  1. Xref: sparky comp.arch:10582 comp.lang.misc:3570
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!swrinde!elroy.jpl.nasa.gov!ames!agate!doc.ic.ac.uk!uknet!lsl!snail
  3. From: snail@lsl.co.uk
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: <None>
  6. Message-ID: <1992Nov10.172402.2628@lsl.co.uk>
  7. Date: 10 Nov 92 16:24:01 GMT
  8. References: <1992Oct23.004313.29196@ntuix.ntu.ac.sg> <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM> <BwxsF6.3DF@mentor.cc.purdue.edu> <1ct342INNd4k@agate.berkeley.edu>
  9. Organization: Laser-Scan Ltd., Cambridge
  10. Lines: 41
  11.  
  12. In article <1ct342INNd4k@agate.berkeley.edu>, jhauser@pine.CS.Berkeley.EDU (John Hauser) writes:
  13. [code example deleted]
  14. > The second piece of code is easier to understand and no slower than the
  15. > first.  Depending on the compiler, it's likely faster.
  16.  
  17. Absolutely 
  18.  
  19. > Exactly how much duplication to tolerate can be an engineering decision.
  20. > However, if I hear you right and you're trying to get every possible ounce
  21. > of speed out of a single subroutine, you'd be wise to trade off an increase
  22. > in program size for an increase in the distance between branches and a
  23. > reduction in the number of `goto's.
  24.  
  25. There's a guy here, (as raster handling expert) and he needs to handle data in
  26. many word sizes, but do the same operation (filtering, shearing etc) so he
  27. has several routines and in each routine is a switch statement for each data
  28. size. Recently the compiler fell over... the branches in the case statements
  29. were over 32K in length! Typical of a 32 bit machine that, 16 bit branch
  30. offsets. We had a good laugh at that. However, he's done a slight change so
  31. that doesn't happen now, and the code performance before and after is excellent
  32. - don't worry about large switch/case statements, if performance is what you're
  33. *really* after.
  34. >  As long as you don't bloat your code so
  35. > badly that it won't fit in the on-chip cache, you can improve both the
  36. > speed and the structure of your code this way.
  37.  
  38. Not knowing how big the cache on a MIPS R3000/SPARC 2/HP SNAKE PA CHIP/RS 6000
  39. /ALPHA and they're all different, we just go ahead and do the code anyway.
  40. > 
  41. > Just my $10 worth.
  42. > 
  43. > ----------------------------------------------------------------------------
  44. > Boycott redwood.  Boycott Louisiana-Pacific.  Keep the forests.  YYYYYYYYYYY
  45. > John Hauser---jhauser@cs.berkeley.edu  YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
  46.  
  47. Just my new 10p (horrible coin) worth
  48. -- 
  49. snail@lsl.co.uk      
  50.  
  51. You Have To Remember, You Need To Beleive,
  52. The Time Has Past, Dust In The Leaves.
  53.