Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!HNYKUN53.BITNET!KRUYSBER From: KRUYSBER@HNYKUN53.BITNET Newsgroups: comp.sys.atari.st Subject: QINDEX15 measurents : QuickST 1.46 vs TurboST 1.2 Message-ID: <8908140948.AA13449@ucbvax.Berkeley.EDU> Date: 14 Aug 89 10:28:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 48 To complete the QINDEX15 measurements I've compared QuickST 1.46 and TurboST 1.2. These two only affect the BIOS operations, so I'll give you these results only. All measures were done with a 1040ST with no accessories or AUTO folder programs (except QSTAUTO.PRG...) Normal QuickST TurboST BIOS character output 99 150 312 BIOS string output 99 578 725 BIOS text scrolling 99 175 178 GEM resource drawing 99 167 125 Psychological data: a difference between 578-725 is not 3.5 times the difference between 167-125! The ratio 725/578 = 1.25 and 167/125 = 1.31, so these differences are about the same. 578 is however 5.78 as fast as a normal 1040ST! The difference 167-125 is very noticeable. GEM resources are drawn much quicker. This favours QuickST. The difference 578-725 is pure mathematical, since the increase in speed of 578% in the QuickST case is already striking enough! Another increase up to 725 is merely 'for the record': this is hardly noticable in reality. Conclusion: the measures indicate a better BIOS text handling by TurboST and a better GEM resource handling by QuickST. These measures however have to be seen in the light of the human, indicating that QuickST is (in the comparison of these two versions) preferable. I'm not in the possession of QuickST 1.5 (witch should even be faster), nor am I in the possession of TurboST 1.6 (yet?). The new TurboST should handle GEM drawing much better one promissed to me... Noud van Kruysbergen N.I.C.I. Mail Box 9104 6500 HE Nijmegen The Netherlands kruysbergen@hnykun53 P.S. I haven't done any QINDEX15 testing using cache programs, since these programs keep the last information used in RAM. Reading the same infor- mation 64 times increases the QINDEX measure considerable, but this is not real! You'll never read the same information more than once normally, so unless your cache memory is rather big you'll never reach this measure in practice! Using a cache with these kind of measurements is one of the pitfalls I mentioned the first time.