On Aug 30, 12:49=A0pm, Robert Redelmeier <red...@[EMAIL PROTECTED]
> wrote:
> Robert Myers <rbmyers...@[EMAIL PROTECTED]
> wrote in part:
>
> > The im****tance of latency has been hammered utterly to death
> > in this group. =A0
>
> That is your opinion. =A0I disagree. Bandwidth is so well known that
> it is used for product names. =A0Latency less often, and indirectly.
> Bandwith is easy to measure and the results generally accepted.
> How do _you_ measure latency? =A0I posted my pgm & results.
>
If hardware latency matters, you're in deep doo-doo, to quote George
Bush. The only thing that matters is *predicatbility*. If you can't
predict memory fetches with some accuracy, you're going to spend all
your time stalled. There is no hardware fix.
Because prefetch is so im****tant and so proprietary, measuring
hardware latency is masturbation for geeks. Well, unless you're doing
measurements that effectively test the prefetch, which isn't the same
as testing latency.
After a discussion from another forum a compiler developer from
<unnamed big company> mailed me privately and said that they had found
a way to predict memory fetches from static analysis. I'm almost more
inclined to believe in Santa Claus. In any case, latency is addressed
by situationally-dependent bags of ticks that include the programmer,
the compiler, instruction-window parallelism, software prefetch, and
hardware prefetch. All more im****tant than a raw latency number
(unless you're marketing for AMD).
The energy directed at latency mostly has to go into faking it rather
than to fixing it, and faking it works rather well, otherwise "modern"
processors would be no better than not modern processors.
Bandwidth and huge cache allow reckless prefetch, with I assume is
Intel's way around its latency issues. You can trade bandwidth for
latency, but not the other way around. If your program is memory-
bound and the pipe is full, that's as fast as you're going to go. End
of story.
Robert.
|
