On Apr 23, 11:53am, "John D. McCalpin" wrote:
> Subject: Re: CPU Speed vs. Memory Bandwidth
> > For example, if you had an infinitely fast CPU
> >Key phrase: -------------------------------------------^^^^^^^^^^^^^^^^^^^
> >(Current R4400 CPUs are not infinitely fast :-) Thw wording was carefully
> >chosen!
>
> The bottleneck here is definitely not in the CPU, but in the cache
Sorry: when I said CPU in this context, I meant the CPU subsystem up to
the memory interface,(as opposed to the memory side of the interface).
This may be wrong thinking on my part, but I do it because there are
so many different partitionings of the CPU subsystem. After all,
for an R4400, all of the cache control is part of the CPU chip itself...
> It is interesting to hear that the TFP machines will not have level 2
> cache for the FP operands. The experience of Sun and SGI seems to be
> that 2-level caches are a risky proposition, performance-wise.
Well, yes, and no, depending on what people do.
For what *you* do, TFPs will be a much better match.
For many things, I'm quite happy with 2-level caches.
(In fact, TFP has 2-level caches for the code and integer data, 1 level for FP
data, i.e., it goes like this:
CPU + I-cache + D-cache (1 chip) ------- |
scache
FPU ------- |
that is, the FPU has direct access to multi-MB 4-set-associative cache,
and the whole CPU+FP complex can do 4 of:
2 64-bit loads/stores, including index FP load/stores
2 FP Mult-adds (or other FP ops)
2 integer operations
per cycle
and quite obviously, this won't help integer performance much directly,
i.e., not a lot faster than 150Mhz R4400 ... but it will certainly
help your apps. Also, the interface from system bus <-> cache is 128
bits rather than the 64 of the R4400s.
This archive was generated by hypermail 2b29 : Tue Apr 18 2000 - 05:23:02 CDT