Re: [rfc][patch 3/3] x86: optimise barriers

From: david
Date: Tue Oct 16 2007 - 05:10:36 EST


On Tue, 16 Oct 2007, Jarek Poplawski wrote:

On Tue, Oct 16, 2007 at 02:50:33AM +0200, Nick Piggin wrote:
On Mon, Oct 15, 2007 at 11:10:00AM +0200, Jarek Poplawski wrote:
...

As a matter of fact it's not natural for me at all. I expected the
other direction, and I still doubt programmers' intentions could be
"automatically" predicted good enough, so IMHO, it's not for long.

Really? Consider the consequences if, instead of releasing this latest
document tightening consistency, Intel found that out of order loads
were worth 5% more performance and implemented them in their next chip.
The chip could be completely backwards compatible, but all your old code
would break, because it was broken to begin with (because it was outside
the spec).

I've different opinion on this: I expect any spec to describe current
implementation. Before issuing new models any changes of
implementation should be made public with proper margin of time. Then
system could be optimally adjusted to a real hardware, instead of
planned only, but possibly never realized (plus doing such not used
things with old means is usually more costly: lock vs. lfence). There
is still problem of specs' completness: there are probably often some
things unspecified which could brake on a new model, so never 100%
guarantee anyway.

what you don't realize is that Intel (and AMD) have built their business on makeing sure that their new CPU's run existing software with no modifications, (and almost always faster then the old versions). remember that for most of the world, getting the software modified would mean buying a new version, if the vendor bothered to make a different version for the new chip.

if they required everyone to buy new software to use a new chip it wouldn't work well. In fact Intel tried to do exactly withat with the itanium and it has been a spectacular failure (or t the very least, not a spectacular sucess)

IMO Intel did exactly the right thing from an engineering perspective,
and so did Linux to always follow the spec.

But, if you follow the spec - you don't follow the spec! Why do you
ignore so much this part of Intel's spec:

"This document contains information which Intel may change at any
time without notice. Do not finalize a design with this information."

Maybe it's a real Intel intention and not for lawyers only? (Btw, it
seems we have an example.)

in theory they could change anything at any time, in practice if they break old software they won't sell the chips, so the modifications tend to be along the lines of this one, adding detail to the specifications so that programmers can get more performance.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/