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

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/

Relevant Pages

  • Re: [rfc][patch 3/3] x86: optimise barriers
    ... if loads are already in-order, then lfence is a noop, ... The chip could be completely backwards compatible, ... I expect any spec to describe current ... "This document contains information which Intel may change at any ...
    (Linux-Kernel)
  • Re: Intel Inside no more
    ... >compiler tricks and architectures geared towards achieving high SPEC ... >server chips competed with each other. ... When compared to AMD the clock speed difference wasn't as large, ... However they did so a 7 months after Intel had hit ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: ***NEED HELP PLEASE***
    ... Then I had an Amstrad 1512 with the extra plug in memory memory to give me ... At Intel, a third fabrication run of 4004 processors is made, with corrected masks. ... Intel renegotiates its contract with Busicom, gaining Intel the right to market the 4004 microprocessor openly in non-calculator applications. ... Texas Instruments runs an advertisement in Electronics magazine, showing a "CPU on a Chip" that it developed for Computer Terminal's Datapoint 2200 terminal. ...
    (microsoft.public.security.virus)
  • Re: Intel Article in Business Week Magazine
    ... Goodbye To The Chip Of The Future? ... Itanium server chip they had jointly developed three years ago, ... He announced that Intel will ...
    (comp.os.vms)
  • Re: AMD vs Intel
    ... Conroe chip simply because you will ultimately recognize after 3rd party ... adequate time to do your research and understand that Conroe is a winner. ... the current crop of Intel chips, ... afford one of those dual core AMD chips. ...
    (microsoft.public.windowsxp.hardware)