jfbruno@rodan.acs.syr.edu (John Bruno) (06/07/90)
In article <10373@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: >In article <1990Jun6.044350.20403@cbnewsh.att.com> wolf@cbnewsh.att.com (thomas.wolf) writes: >>Could you contain your mindless ravings? The poster mentioned that 1/3 >>increases were with non-030 applications (ie those written for the MC68000). >>I seriously doubt your claim that a ~9-fold increase was achieved on the A2500 >>WITHOUT optimizing the code towards a 68030. I doubt it too! > >That wasn't mindless ravings. Seriously, that 1/3 number confuses me--it >should be lots higher. Going from a 16 bit to 32 bit machine and doubling >the clock speed (8 MHz to 16 MHz) should give you at least a factor of 4, How do you figure that???? I would expect a CPU with twice the clock rate to execute instructions twice as fast. However, the difference between a 32 bit bus and a 16 bit bus will not double your execution speed (unless every single instruction in the testing program operates on 32 bit objects). Sure there will be more speed improvement, but definitely NOT enough to double the speed. You can always whip up some special optimal program that will run 4 times as fast with the above configuration. That is, if you just want to impress those people that like to say "MY machine does more Giga-hoozits than..." In real life, though, it don't work that way. I still feel that the most important and effective things you could possibly do to speed up your computer is to learn how to type and operate a mouse faster and get a faster hard drive. Even a ZILLION-MHz machine is gonna twiddle its thumbs waiting for you (operating at about 3Hz) to tell it what to do. [ Rest of 68030/68000 discussion ZAPPED ] ---jb PS - A request for posters to this group: Please make sure that the subject of your article agrees with the body of your article!!!!!!!!!!!!!
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (06/07/90)
In article <3647@rodan.acs.syr.edu> jfbruno@rodan.acs.syr.edu (John Bruno) writes: > >That wasn't mindless ravings. Seriously, that 1/3 number confuses me--it > >should be lots higher. Going from a 16 bit to 32 bit machine and doubling > >the clock speed (8 MHz to 16 MHz) should give you at least a factor of 4, > >How do you figure that???? I would expect a CPU with twice the clock rate to >execute instructions twice as fast. However, the difference between a 32 >bit bus and a 16 bit bus will not double your execution speed (unless every >single instruction in the testing program operates on 32 bit objects). Sure >there will be more speed improvement, but definitely NOT enough to double the >speed. My "double the bus width, double the speed" was a bit glib. I was assuming that the TT has a decent 32-bit memory subsystem, and that the instruction and data caches are enabled. If those conditions are true, then a '30 should have at least a factor of two advantage over a 68000 of the same speed. If you turn off the cache, that drops. If you turn off the cache and force it to use 16-bit memory, a '30 may well perform worse than a 68000 at the same clock speed. It is true that, in general, a 32-bit bus machine isn't a priori twice as fast as a 16. However, with the built-in 256-byte instruction and data caches and a pipelined architecture, a 68030 in practice is at least that much faster than a 68000, if it has decently fast 32-bit memory to talk to. >You can always whip up some special optimal program that will run 4 times >as fast with the above configuration. That is, if you just want to impress >those people that like to say "MY machine does more Giga-hoozits than..." Yeah, but I'm not talking about special cases. On generic 68000 integer code, with decent 32-bit memory and both caches enabled, a '30 should be more than twice as fast as a 68000 of the same clock speed. If we give Atari the benefit of the doubt and assume a competent hardware design for the TT, then it should be at least 4 times as fast as an 8 MHz 68000 running generic 68000 code. I'm just curious why they might not get this running ST applications. Anyway, as has been pointed out, we don't have real specs or benchmarks for the TT, so this line of discussion is premature. I'll shut up now until some real specs are out. -Dan Riley (riley@riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
dac@ukc.ac.uk (David Clear) (06/07/90)
In article <10373@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: > >[...]. Seriously, that 1/3 number confuses me--it >should be lots higher. Going from a 16 bit to 32 bit machine and doubling >the clock speed (8 MHz to 16 MHz) should give you at least a factor of 4, Doesn't the 68030 have internal cache memory and pipelining? I took a look in a 68030 reference manual and some (non-register direct) addressing modes are given as taking ZERO cycles to evaluate. This, of course, is because of the pipeline. If you think about it, then a machine running and twice the speed of an 8MHz 68000 with twice the data bus width and assuming that the memory will run with zero wait state (I don't know if the TT does) then you are looking at everything running at least twice the speed by default. That figure shouldn't even take into account the 32-bit bus which would further increase the speed. The cache and pipeline will further increase the speed. At the end of the day, you're looking at one SWIFT machine! As someone else said, though, let's wait for some REAL benchmarks before we over-state the acceleration and maybe end up a little disappointed. After all, the new TOS might, for example, disable the internal cache. The new RAM might be slower than it could have been. I don't know... do you? Oh yes, I almost forgot the most important message: + My Atari 800XL is better than your Commodore 64 because it's mine. + My Atari ST is better than your Commodore Amiga because it's mine. + If I get an Atari TT then will be better than your Commodore Amiga 3000 because it will be mine. I have a friend who owns a 64 and an Amiga and he uses the same arguments against me. Don't try to camouflage your argument with technical specs, prices or software surveys. This is a religious argument and has been since time began (ie when the 64 and 800s came out). Everyone knows which machine is the best... THEIR machine. If ever they lose faith then they buy a new machine. But that's between them and their own religion. Please don't push your faith on me, I don't want to know. Religious wars never end... Ever. Dave. -- % cc life.c | David Clear <dac@ukc.ac.uk> % a.out | Computer Science, University of Kent, Segmentation fault (core dumped) | Canterbury, England.
jgp@fctunl.rccn.pt (Jose Goncalo Pedro) (06/08/90)
Well, you get the two-fold speed increase going form a 16 bit bus and a 32 bit bus this way: The 68030 has a built-in instruction cache (don't know about a prefetch queue, but shouldn't need it), which, when the 030 is fetching an instruction not present in the cache, fetches a 32 bit long word from memory and stores it in the cache, too. So, when the 030 fetches the next 16 bit instruction (or operands, or whatever) it goes directly to the cache (or maybe prefetch queue) and gets it much faster than ram (I don't think TT's ram runs at 0 wait states!). For most purposes, and for the vast majority of programs, this represents a 2-fold speed increase. But all this is incorrect because I am not taking into account the fact that the place where programs generaly spend more time, i.e. short inner loops (i think) have a good chance to be executed from the cache after the first pass, and i think that a 256 byte cache is enough for most such loops. And the 030 has got also a 256 byte data cache... All this coupled to an increase from 8 Mhz to 16 Mhz, and the fact that the 030 takes half as many clock cicles to do a memory access than the 68000 (memory speed permiting), without using the burst transfer mode which transfers 4 32 bit words in 5 clock cicles to the cache (but i doubt that the TT uses that) (I hope I am not confusing this with the 68040!!!), should give better than a fourfold speed increase! I'd like to state that ever since i read about the TT i have sort of dreamed of owning one, but have always had my doubts of Atari's capabilities to make this a real, usable computer (and supported, almost forgot that one), with real software that can be used to develop applications for more than one platform (I live in a country where the vast majority of PC's [not counting Spectrum's] are IBM compatibles, and I wouldn't try to make a living developping only for the ST). Here, there are almost no third party dealers (almost no official atari dealers, also), harddisks and the like are 2* or 3* the price one can get them abroad, software for the ST is virtually non-existent, and I barely use the ST anymore (1040ST with SM124, no HD, 1Meg), and turn to my brother's IBM PS/2 55 SX, with a 16Mhz 386SX, colo(u)r VGA monitor, 60Mb HD, 2Meg ram, and a decent (portuguese) keyboard. I still prefer the ST, but.... The TT would be my salvation from the PC world, where I developed some applications (and got sick of it, when i needed to write a windowing environment for the next versions of those program, you know, those little windows and menus that every Mac, ST or Amiga programmer takes for granted), but, as i said, my faith in Atari isn't very high... Enough complainig! Two (three? 4?) more questions. Why isn't there a 25 Mhz TT ? Apple has got a 40 MHz MacIIfx, and I think Motorola already ships 50Mhz '030's. Will it bee so difficult to upgrade has the other models? And what about a 68040 based TT ? (I think I'm in love with that chip) And why not a proper GEM implementation, with more services managers (for sound, comms, or even extending th
l86@nikhefh.nikhef.nl (Hugo Burm) (06/12/90)
The developers version of the TT (16 MHz) runs at 4100 Dhrystones (Turbo C 2.0, 68020 compiler switch on, cache on, run in dual purpose RAM (time sliced with the video logic)) A normal ST runs at 1700.
larserio@IFI.UIO.NO (LarsErikOsterud) (06/13/90)
Atari Norway just told us that the TT will be delivered NOT with a 16 MHz 68030 but with a 32 MHZ 68030 INSTEAD !!!!!!!! OHHH BOY !!!!! Lars-Erik / ABK-BBS +47 2132659 / ____ ______ ________________________ Osterud / larserio@ifi.uio.no / /___ / The norwegian ST __________/ ______________________/ ____/ / Klubben, user association
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (06/13/90)
l86@nikhefh.nikhef.nl (Hugo Burm) writes: >The developers version of the TT (16 MHz) runs >at 4100 Dhrystones >(Turbo C 2.0, 68020 compiler switch on, cache on, >run in dual purpose RAM (time sliced with the video logic)) >A normal ST runs at 1700. Which Dhrystone version? 1.1 oder 2.1? This is important! The TT we tested calculated a new move in our mill game in a bit more than a quarter of the time it took on the ST. The cache was enabled, and everything ran in slow RAM. As strategy game move searchers are extremely CPU-bound, this should be interpreted as a kind of upper speedup limit for real-world applications that aren't recompiled. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
scott@cs.odu.edu (Scott Yelich) (06/14/90)
>Atari Norway just told us that the TT will be delivered NOT with a 16 MHz >68030 but with a 32 MHZ 68030 INSTEAD !!!!!!!! OHHH BOY !!!!! Please, someone revive me....
hans@duttnph.tudelft.nl (Hans Buurman) (06/14/90)
Image processing with Aim on the TT runs at about 4 times ST speed too. Just my 2 dhrystones worth.... Hans ======================================================================== Hans Buurman | hans@duttnph.tudelft.nl | hans@duttnph.UUCP Pattern Recognition Group | 31-(0)15-78 46 94 | Faculty of Applied Physics | Delft University of Technology
gmaster@malihh.hanse.de (Carsten Lutz) (07/04/90)
Im Artikel <SCOTT.90Jun23011233@croaker.cs.odu.edu> schreibt scott@cs.odu.edu (Scott Yelich): > >>32 Mhz in Europe. As far as I have read in several (european) magazines, > >>the TT will have a 16 Mhz (alas). > >It is also possible that some new person with no experience got mixed > >up about the difference between Mhz and bits. > > 32mHz? I hears it was 32MiPs! Really. I think it were 32 serial ports... 8-) gm -- + Carsten Lutz, Rellingen, FRG + + gmaster@malihh.hanse.de ( & g.master@mcshh.sub.org ) + + Voice : 04101/207871 Fax : 04101/27757 malihh : 04101/22306 +
ignac@electro.com (Ignac Kolenko) (07/05/90)
In article <3210744@malihh.hanse.de> gmaster@malihh.hanse.de (Carsten Lutz) writes: >Im Artikel <SCOTT.90Jun23011233@croaker.cs.odu.edu> schreibt scott@cs.odu.edu (Scott Yelich): >> >>32 Mhz in Europe. As far as I have read in several (european) magazines, >> >>the TT will have a 16 Mhz (alas). >> >It is also possible that some new person with no experience got mixed >> >up about the difference between Mhz and bits. >> >> 32mHz? I hears it was 32MiPs! Really. > >I think it were 32 serial ports... 8-) sure it wasn't 32 pounds in weight?? (liberal sprinkling of smilies) -- ========Ignac A. Kolenko (The Ig)=======watmath!watcgl!electro!ignac========= "Blowed up REAL good!" - Big Jim McBob (Celebrity Blowup - SCTV) =============================================================================