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

[Jarek Poplawski]

On Tue, Oct 16, 2007 at 02:14:17AM -0700, david@xxxxxxx wrote:
...
> 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.

It's a good point to always consider when you analyze how something
new should work if it's used with older programs too. But with newer
things like SMP or multithreading they probably have more choice, and
you can only guess what it's done 'officially'.

> 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)

The failure of an architecture doesn't mean all specific new
technologies used in itanium were failure too, so they could be back
when needed (and nothing better in reserve) yet.

...
> 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.

I don't think 'not breaking' is much problem here, rather how to use
all new features (which you seem to ignore a bit) to get maximum of
performance without breaking older things. Or, like current problem:
go rational and remove useless (acording to new specs) things, even
without performance gain, or stay 'safe'?

Jarek P.
-
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/