Re: Memory access

From: Johan Klockars <>
Date: Tue, 13 Jan 1998 15:50:12 +0100 (MET)

> Well as you get 1000% on a AB040 and 2400% on ROM on the Hades it's a bit more than
> twice the performance of the AB040 which doesn't sound to far fetched.

What I'm trying to say is that none of the numbers are sensible.
You most definitely don't have 10 times the memory bandwidth on an AB040
compared to a normal Falcon or 24 times with a Hades.

> > A normal Falcon has something like 6Mbyte/s bandwidth to RAM. 24 times
> > that would be 144 Mbyte/s, which given a 32 bit bus would require all
> > accesses to take less than a single clock cycle at 32MHz.
> And as the bus is 64-bit but ineterleaved it will get a bit faster.

No, I'm taking that into account here. The bus is still 32 bit wide.

> You are ofcourse right but the interleaved memory architecture of the Hades

Naturally. ;-)

> will give you better performance. When the CPU has read one 32-bit word the
> next is already available. Or????

That's what those -1-1-1:s mean. We have -2-2-2 or -3-3-3 on our AB040's.

> And so 2400% for GEMBENCH sounds correct as it's about twice as fast as on the
> AB040. This is if you use _GEMBENCH_ you will get this 24 figure. :-)

Yes, but quoting GEMBench figures is not sensible in any case.

I've recently been involved in a thread on
concerning a very similar program on the PC, Wintune97.
That seems to have the same problem as GEMBench to some degree and to make
matters worse it gives a Megapixel/s value that is nearly useless. It's
still one of the most quoted graphics performance numbers...

If anyone has a PC, I'd really appreciate if you could run Wintune97 on it
and report the _detailed_ results to me. Take a look at the thread I
mentioned (it's easy to find on dejanews, just look for me) for furter info.

  Chalmers University   | Why are these |  e-mail:
     of Technology      |  .signatures  |  
                        | so hard to do |  WWW/ftp:
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)
Received on ti. jan. 13 1998 - 20:41:00 CET

This archive was generated by hypermail 2.3.0 : ti. nov. 03 2015 - 20:07:53 CET