Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!apple!rutgers!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.hardware Subject: Re: Slow GVP '030 accelerator board Message-ID: <16008@cbmvax.commodore.com> Date: 21 Nov 90 13:27:58 GMT References: <5765@crash.cts.com> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 76 In article <5765@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes: >daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1990Nov16.175346.4884@maverick.ksu.ksu.edu> yeewei@matt.ksu.ksu.edu (Yee-Wei Huang) writes: >>> When I run performance tests on the machine, I show only a 20% >>>increase over the stock 68000! >>That's just about what you should expect to see, without any 32 bit RAM. >Dave...this is one I need to disagree with. [Why do I see flames on the >horizon? :-)] No flames, just possible misconceptions... >Of course running in a 16-bit environment is killing a great deal of the >performance of the 68030...the extra cycles needed for the bus accesses are >quite time consuming. The extra cycles simply explain why, without the caches, the 68030 will be slower. You have to add to that the fact that the memory you're accessing is less that 1/2 the speed of normal 68030 32-bit memory. For example, the basic A2000 or Zorro II memory cycle is 560ns. The A2630 and A3000 memory systems (without burst enabled) cycle in 200ns. Then you have to consider synchronization delays -- the 68030 has to sync up to 16 bit memory, since they're based on different clocks, so you end up adding extra wait states for most of your memory accesses. >However, the figure of '20%' over a stock 2000 with a standard 68000 I cannot >agree on as being correct in any sense. For real system performance, it is. You can construct artificial benchmark conditions that make the '030 performance appear better. >If it were the case that it was this bad, there would be little market for the >various 68020 accelerators around which have no 32-bit memory facilities... Don't count on it. Those little accelerators sell because people THINK they'll go much faster with them. Market preception, above all else, is what sells. Why do think people bought Apple IIs for 3-4 times the price of C64s, when the C64 actually ran a hair faster? The only real significant speedup you get with these kind of '020 boards is via the math coprocessor. >Applicatons-wise, though, I DO agree with around 20-30% though, as benchmarks >are far too simple to measure over the entire spectrum of operations. That's what I'm talking about here. Benchmarks that don't track the behavior of applications should be erased from all your disks. They are totally meaningless. So anything that's telling you your 32-bit-memory-less 68030 is going 200% faster than a plain 68000 is measuring an artifical condition. It is, in effect, lying to you, since you cannot do any useful work and get anywhere near that performance level. >If this GVP board is being tested with any of the benchmarking tests I've seen >though (Ronin CPUSpeed, etc...), I'd more expect a reading as I mentioned >before. First thing you do, erase any copies of the Ronin CPUSpeed test you have around. That test basically measures CPU register speed, and as a side effect has a component that's based on memory speed. It tells you absolutely nothing about system performance. It is totally useless. It will tell you that a 50MHz 68030 system running out of slow 16 bit memory is faster than a 16MHz 68030 system running out of nearly 0 wait state 32 bit memory, which is totally wrong. While I can't recommend any really trustworthy benchmarks, Dhrystone 2.x is a decent one. Though, on the same hardware, you can easily get a 2:1 range of results depending on the compiler you use, sometimes even between different options on the same compiler. So simply quoting Dhrystones tends to be rather meaningless without also including the compiler information, unless you're simply going for bragging rights against a Mac or IBM. >--LaMonte -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM