From: Jarek Poplawski <jarkao2@o2.pl>
To: david@lang.hm
Cc: Nick Piggin <npiggin@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Helge Hafting <helge.hafting@aitel.hist.no>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andi Kleen <ak@suse.de>
Subject: Re: [rfc][patch 3/3] x86: optimise barriers
Date: Tue, 16 Oct 2007 14:49:16 +0200 [thread overview]
Message-ID: <20071016124916.GE1000@ff.dom.local> (raw)
In-Reply-To: <Pine.LNX.4.64.0710160205100.1538@asgard.lang.hm>
On Tue, Oct 16, 2007 at 02:14:17AM -0700, david@lang.hm 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.
next prev parent reply other threads:[~2007-10-16 12:46 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 5:21 [rfc][patch 1/3] x86_64: fence nontemproal stores Nick Piggin
2007-10-04 5:22 ` [rfc][patch 2/3] x86: fix IO write barriers Nick Piggin
2007-10-04 17:32 ` Dave Jones
2007-10-04 17:53 ` Andi Kleen
2007-10-04 18:10 ` Dave Jones
2007-10-04 18:21 ` Andi Kleen
2007-10-04 18:41 ` Dave Jones
2007-10-04 18:58 ` Andi Kleen
2007-10-04 19:08 ` Dave Jones
2007-10-04 20:52 ` Alan Cox
2007-10-04 5:23 ` [rfc][patch 3/3] x86: optimise barriers Nick Piggin
2007-10-12 8:25 ` Jarek Poplawski
2007-10-12 8:42 ` Helge Hafting
2007-10-12 9:12 ` Jarek Poplawski
2007-10-12 9:44 ` Nick Piggin
2007-10-12 10:04 ` Jarek Poplawski
2007-10-12 12:44 ` Helge Hafting
2007-10-12 13:29 ` Jarek Poplawski
2007-10-15 10:17 ` Helge Hafting
2007-10-15 11:53 ` Jarek Poplawski
2007-10-12 8:57 ` Nick Piggin
2007-10-12 9:55 ` Jarek Poplawski
2007-10-12 10:42 ` Nick Piggin
2007-10-12 11:55 ` Jarek Poplawski
2007-10-12 12:10 ` Jarek Poplawski
2007-10-12 15:13 ` Linus Torvalds
2007-10-15 7:44 ` Jarek Poplawski
2007-10-15 8:09 ` Nick Piggin
2007-10-15 9:10 ` Jarek Poplawski
2007-10-15 9:24 ` Jarek Poplawski
2007-10-16 0:50 ` Nick Piggin
2007-10-16 9:00 ` Jarek Poplawski
2007-10-16 9:14 ` david
2007-10-16 12:49 ` Jarek Poplawski [this message]
2007-10-15 14:38 ` David Schwartz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071016124916.GE1000@ff.dom.local \
--to=jarkao2@o2.pl \
--cc=ak@suse.de \
--cc=david@lang.hm \
--cc=helge.hafting@aitel.hist.no \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox