On Aug 31, 1:57=A0pm, Robert Redelmeier <red...@[EMAIL PROTECTED]
> wrote:
> Robert Myers <rbmyers...@[EMAIL PROTECTED]
> wrote in part:
>
> > If hardware latency matters, you're in deep doo-doo, to quote George
Bu=
sh. =A0
>
> Then that is were you are, at least on some apps.
>
> > The only thing that matters is *predicatbility*.
>
> Yes, that is the Intel thinking since the i440BX. =A0They have
> put in hardware into their Northbridges/MCH to detect memory
> access patterns and trigger speculative prefetches. =A0Clever.
>
> There are two problems with this: =A01) =A0not all fetches are
> predictable (relational DB is particularly bad) and =A02)
> OS memory fragmentation by 4 KB pages hurts predictability.
> Of course some apps are much worse than others (SETI@[EMAIL PROTECTED]
).
>
> I view all apps as a combination of CPU time, bandwidth time
> and latency time. =A0Sometime those times can be overlapped.
> But as CPU and bandwidth improvements drive those times down,
> the unimproved latency becomes more im****tant for all apps.
>
> Still, the situation is not at all bad for pure memory rippers.
> 300 CPU clocks of latency is tiny when spread out over a 4KB
> page: 0.07 clk/byte. =A0No problems for video.
>
Then hardware latency isn't im****tant. Intel, AMD, and IBM both have
to present platforms that achieve acceptable performance on a wide
array of problems. How they do it is up to them. Your constant
harping on a single figure of merit is beyond tiresome.
It's true, the smaller the hardware latency, the less you have to
scramble to cover it. Personally, I'm amazed that Intel has gotten
away with the strategy they've chosen, but the fact is that they
have. There's no "See I told ya so" about putting the memory
controller on the die, and AMD wasn't the first to do it.
If you go onto the ACM digital library and search on prefetch, you
will get dozens and dozens of articles. Without a subscription, you
can't read the level of serious effort that has gone into thinking
about that question. And, without having read a substantial part of
that body of work, it's very likely that anything that anyone says on
the subject of managing latency will be uninformed or misinformed. I
provided the example of the compiler developer to indicate the lengths
to which people go to solve this problem. The subject just doesn't
lend itself to sweeping generalization.
In any case, memory latency is a hundred or so cycles. Absolutely
****d latency on the critical path is unacceptable. If you can't hide
it in most cases, you might as well be using a 486.
> > If you can't predict memory fetches with some accuracy, you're
> > going to spend all your time stalled. =A0There is no hardware fix.
>
> Sure there is: =A0AMD has a 30% solution with an integrated memory
> controller. =A0Ultimately, we will go to some flavor of SRAM. =A0Yes,
> it takes 2-6x the transistors per cell, but we're already having
> trouble finding other things to do with the xtors.
>
AMD's solution isn't AMD's solution, and a 30% fix just reduces the
amount of latency hiding you have to do, as I've already noted. And,
yes, you could change the memory architecture completely.
> > 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.
>
> Guess what? =A0For some things they aren't. =A0For very few apps
> is performance a direct function of CPU clock or mem bandwidth.
> Double speed seldom yields double performance.
>
For the thousandth time, my problems tend to be memory bound. Finding
a reasonable compromise among all the competing needs of different
problems is a major challenge to the manufacturer. As to using older
architectures, that's clearly happening, because the modern
developments don't really help in some situations, like transaction
servers.
It's not as if what you think about this were irrelevant or totally
crazy. It's your focus on a single aspect of a very complicated
problem that just makes me crazy. You can find similar single
mindedness among some posters obsessed with the memory wall, which is
another name for the same subject. For the most part, we've driven
right up to that wall and through it without mussing a hair. It's a
crazy way to live, but it is the way we are living: through fakery and
bulltet-dodgin, not through brute force hardware design.
One final thought. The predictability problem is everywhere in
computing. You can call it the latency problem if you wish, but
you're always stuck trying to anticipate. From a theoretical point of
view, it's a much more interesting subject than AMD vs. Intel.
Robert.
|
