Re: performance stuff [Re: Kernel Rebuild & Status...]

Jeff Noxon (jeff@mrsagw.mrsa.com)
Fri, 18 Aug 1995 08:00:15 -0500 (CDT)


> [Deleita about AXPpci33 board]
> > One reason could be: L2 cache of 256 KB is too less, should be 1MB !
>
> I don't think it would matter much. The memory bus runs at 33 MHz according
> to the specs I have. Seems rather silly for a CPU this fast.
>
> (a) It's the other way round: the bigger the bandwidth discrepancy
> between main-memory and CPU, the *more* cache you want. I don't know
> the benchmark that was used, but if 256KB vs. 1MB makes the difference
> between the benchmark fitting into or exceeding the cache, a
> performance difference of an order of magnitude is not unusual. Also,
> the benchmark may suffer from conflict-misses (the caches are
> direct-mapped). In such a case, it often is sufficient just to
> reorganize the data a little to gain significantly more performance.
>
> (b) The 33MHz you mention most likely refer to the PCI bus speed. The
[chop]

The PCI bus speed, of course, is irrelevant to memory performance.

I thought for sure that the CPU<->memory interface ran at 33MHz, including
the cache, but you may be correct. Does anyone have the specs to verify
this?

If the memory interface *does* run @ 33MHz, the poor CPU is going to
be stalling all the time no matter what kind of memory/cache you have.

> [Chop]
> > After this, I got an Alpha box (Sirius275), with 2MB L2 Cache, 275 Mhz
> > and 64 MB memory. And this was, when computing really got fast !
> > This box was in the XLispStat test factor 3 faster than the Alpha 166 box.
> > (it is significantly more expensive, too ;-))
>
> 21064 chip, much faster memory bus. The cache is actually given a chance
> to work.
>
> More likely: bigger & faster cache (2MB @ 12ns) and wider memory-bus
> (128bit vs. 64bit), i.e., the CPU gets to wait less often for memory
> accesses. Of course, the memory-system is what makes those boxes more
> pricey (and, I'd venture, for exactly the same reasons there are
> low-cost Pentium boxes and not-so-low-cost ones). The fact these days
> is just that: the performance of low-end systems is in practice much
> more affected by memory- and i/o-performance than by CPU performance
> (now what does that say about cheap multiprocessors? :).

Sure, memory systems like that are more expensive, but I think it's
generally due to the increased number of pins/traces.

Have you checked the price of a 21064 *chip* lately? Eek. Those CPUs
cost many thousand dollars. Maybe as much as US$4K for the faster ones.
It's the multiplexed bus, lower pin count, and greater simplicity that
makes the 21164 so much cheaper. (If anyone has recent OEM pricing,
I would be interested to see the comparison.)

A 12ns async cache isn't nearly fast enough for a CPU running at 275 MHz.
Burst cache, RDRAM, or possibly both are needed to approach the full
capabilities of a CPU that fast.

> One note: when doing performance measurements on Linux/Alpha, please
> bear in mind that (as far as I know) neither the kernel nor the
> library have experienced much performance tuning as of yet. There are
> lots of places that could improve, but, right now, most people are
> busy getting the functionality into the system. Compute-bound
> benchmarks may not be that sensitive to such factors, but
> system-benchmarks certainly are.

True. I especially wonder about gcc on the Alpha.

> And, once again: I still think that Linux/Alpha should also provide a
> user-level environment with 32-bit pointers/longs. This can reduce
> both memory-consumption and memory-bandwidth requirements. But before
> this happens, somebody needs to find the time and actually do it.

Uh-oh, back to multiple memory models.. :) But, right again. :)

Again, if anyone has any relevant facts here please set us straight.

Jeff