home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / atari / st / tech / 6395 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  2.6 KB
  1. Xref: sparky comp.sys.atari.st.tech:6395 comp.sys.atari.st:18915 comp.sys.amiga.advocacy:32154
  2. Newsgroups: comp.sys.atari.st.tech,comp.sys.atari.st,comp.sys.amiga.advocacy
  3. Path: sparky!uunet!cs.utexas.edu!usc!elroy.jpl.nasa.gov!hanauma.jpl.nasa.gov!hyc
  4. From: hyc@hanauma.jpl.nasa.gov (Howard Chu)
  5. Subject: Re: Falcon BUS..
  6. Message-ID: <1992Dec24.234910.28952@elroy.jpl.nasa.gov>
  7. Followup-To: comp.sys.atari.st.tech
  8. Sender: news@elroy.jpl.nasa.gov (Usenet)
  9. Nntp-Posting-Host: hanauma.jpl.nasa.gov
  10. Organization: SAR Systems Development & Processing, JPL
  11. References: <1992Dec14.235558.17175@news.th-darmstadt.de>
  12. Date: Thu, 24 Dec 1992 23:49:10 GMT
  13. Lines: 47
  14.  
  15. Well, I finally got around to compiling this with GNU C. Here are some
  16. numbers for the Falcon in a couple different graphics modes:
  17.  
  18. Test        640x480x2    640x480x256    320x240x16
  19.  
  20. 16 bit read    6206061        3413333        5610959
  21. 16 bit write    16384000    6400000        14124138
  22. 32 bit read    6301538        3442017        5688889
  23. 32 bit write    31507692    7876923        24094118
  24.  
  25. Here's a comparison from my Mega with Turbo16:
  26.  
  27.         640x200x4
  28.  
  29. 16 bit read    7876923
  30. 16 bit write    2884587
  31. 32 bit read    7876923
  32. 32 bit write    2884587
  33.  
  34. First, looking at the Mega-ST, the numbers clearly agree with the fact that
  35. the ST has only a 16 bit bus. The read numbers appear exaggerated to me,
  36. probably due to how the Turbo-16 cache works.
  37.  
  38. The numbers for the Falcon are a little less clear, but I'd figure that the
  39. read speeds for 16 and 32 bit cases indicate a 16 bit bus, with the slightly
  40. higher speed in the 32 bit case due to having to execute one fewer instruction
  41. in the actual test loop. (Well, it's still the same instruction count, but does
  42. a NOP really consume as much time as a post-increment?) The write speeds again
  43. show the effect of caching, which makes this test a little suspect. As you
  44. can see in the 640x480x2 case, the video doesn't slow down the processor at
  45. all in the 16 bit write case, the write speed is the maximum achievable on
  46. a 16 MHz processor with a 2 cycle write. Or rather, the 68030 cache is able
  47. to make up for any delay that might be present. But for the 32 bit case,
  48. the impact of the video becomes noticeable, being about 4% slower than the
  49. theoretical maximum.
  50.  
  51. This test program only used a 2K data set, so the cache effects are too
  52. significant in these results. I guess I should try it again with a 64K
  53. data set, to override the Turbo-16's 32K cache and the 68030's on-chip
  54. caches...
  55.  
  56. In the meantime, I'd be curious to see the results of this program run on
  57. an Amiga, since we've been bandying around so much stuff about all this ...
  58. -- 
  59.   -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
  60.  
  61. There's a narrow border between genius and insanity, but I'm a dual citizen.
  62.