4:28 a.m.
As I was educating myself on the intricacies of building rpms last
night,
I was just a little nonplussed to see the following scroll by, in
particular the last little bit:
CFLAGS='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64
-mtune=nocona'
Of course, on through -m64 was as expected. I'm just a bit surprised
that it didn't say mtune=k8 since it was definitely building on one ...
which begs the question ... is GCC (and hence the entire x86_64
distribution) being built this way? What are the K8 performance
implications? I've seen a few things that indicate that Nocona cores
running K8 code look pretty bad in some areas compared to optimized
code...however, I find nothing to indicate how nocona optimized code
runs on the K8.
Karen
5:09 a.m.
Of course, on through -m64 was as expected. I'm just a bit
surprised
that it didn't say mtune=k8 since it was definitely building on one ...
which begs the question ... is GCC (and hence the entire x86_64
distribution) being built this way? What are the K8 performance
implications? I've seen a few things that indicate that Nocona cores
running K8 code look pretty bad in some areas compared to optimized
code...however, I find nothing to indicate how nocona optimized code
runs on the K8.
AMD cpus are very good at running just about anything you throw at it
(think about it; with their marketshare... most code out there is
optimized for intel cpus so their cpus are effectively required to deal
well with such code). The reverse unfortunatly isn't the case.
7:13 a.m.
On Thu, Jun 09, 2005 at 12:09:08PM +0200, Arjan van de Ven wrote:
AMD cpus are very good at running just about anything you throw at
it
(think about it; with their marketshare... most code out there is
optimized for intel cpus so their cpus are effectively required to deal
well with such code). The reverse unfortunatly isn't the case.
And when Intel shows up late to the party with a solution that can only
be described as crap, we bow in their direction. I'm not saying that it
is the wrong decision, but it is disheartening.
In any case, AMD's architecture still retains numerous advantages.
-Bill
9:03 a.m.
Arjan van de Ven <arjanv(a)redhat.com> wrote:
> Of course, on through -m64 was as expected. I'm just a bit
surprised
> that it didn't say mtune=k8 since it was definitely building on one ...
> which begs the question ... is GCC (and hence the entire x86_64
> distribution) being built this way? What are the K8 performance
> implications? I've seen a few things that indicate that Nocona cores
> running K8 code look pretty bad in some areas compared to optimized
> code...however, I find nothing to indicate how nocona optimized code
> runs on the K8.
AMD cpus are very good at running just about anything you throw at
it
(think about it; with their marketshare... most code out there is
optimized for intel cpus so their cpus are effectively required to deal
well with such code). The reverse unfortunatly isn't the case.
AFAIU, they are talking about /64 bit/ code here. There the situation is
almost exactly the other way around, isn't it?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
9:15 a.m.
On Thu, 2005-06-09 at 10:03 -0400, Horst von Brand wrote:
Arjan van de Ven <arjanv(a)redhat.com> wrote:
> > Of course, on through -m64 was as expected. I'm just a bit surprised
> > that it didn't say mtune=k8 since it was definitely building on one ...
> > which begs the question ... is GCC (and hence the entire x86_64
> > distribution) being built this way? What are the K8 performance
> > implications? I've seen a few things that indicate that Nocona cores
> > running K8 code look pretty bad in some areas compared to optimized
> > code...however, I find nothing to indicate how nocona optimized code
> > runs on the K8.
> AMD cpus are very good at running just about anything you throw at it
> (think about it; with their marketshare... most code out there is
> optimized for intel cpus so their cpus are effectively required to deal
> well with such code). The reverse unfortunatly isn't the case.
AFAIU, they are talking about /64 bit/ code here. There the situation is
almost exactly the other way around, isn't it?
What Arjan is saying is this: AMD Opteron/Athlon64 CPUs do much, much
better with -mtune=nocona than Intel EM64T CPUs do with -mtune=k8. It
appears that the Opteron/Althon64 are more flexible in this regard.
Therefore, since the hit for -mtune=nocona on Opteron is much smaller
than -mtune=k8 on EM64T, the distro uses -mtune=nocona.
The question, distilled:
Would you like: (a) Small speed hit for Opteron users, OR (b) much
larger speed hit for EM64T users?
(a), ie -mtune=nocona everywhere, seems to be the fairest option here
for everybody since we obviously cannot make 1 build of Fedora Core for
Opteron and 1 comletely separate build of Fedora Core for EM64T.
Dan
9:28 a.m.
Arjan van de Ven wrote:
On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote:
>The question, distilled:
>
>Would you like: (a) Small speed hit for Opteron users, OR (b) much
>larger speed hit for EM64T users?
note the hit is REALLY REALLY small. Hard to measure kind of small.
Have you compared -march=k8 with -mtune=nocona ?
--
Pádraig Brady - http://www.pixelbeat.org
--
10:18 a.m.
On Thu, 2005-06-09 at 15:28 +0100, P(a)draigBrady.com wrote:
Arjan van de Ven wrote:
> On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote:
>
>>The question, distilled:
>>
>>Would you like: (a) Small speed hit for Opteron users, OR (b) much
>>larger speed hit for EM64T users?
>
> note the hit is REALLY REALLY small. Hard to measure kind of small.
Have you compared -march=k8 with -mtune=nocona ?
I didn't personally, but our gcc guys did and they said it was hardly
measureable if at all.
9:21 a.m.
On Thu, 2005-06-09 at 10:15 -0400, Dan Williams wrote:
The question, distilled:
Would you like: (a) Small speed hit for Opteron users, OR (b) much
larger speed hit for EM64T users?
The question is how small is the small hit and how large is the large
one. Percentage numbers anyone?
(a), ie -mtune=nocona everywhere, seems to be the fairest option
here
for everybody since we obviously cannot make 1 build of Fedora Core for
Opteron and 1 comletely separate build of Fedora Core for EM64T.
Yes, that's
true.
--
Tomas Mraz <tmraz(a)redhat.com>
9:33 a.m.
Tomas Mraz wrote:
On Thu, 2005-06-09 at 10:15 -0400, Dan Williams wrote:
>The question, distilled:
>
>Would you like: (a) Small speed hit for Opteron users, OR (b) much
>larger speed hit for EM64T users?
>
>
The question is how small is the small hit and how large is the large
one. Percentage numbers anyone?
I have an old data for gcc3.4. Data should be practically the same for
gcc4 because tuninng affect back back end optimizations which have not
been changed since gcc3.4.
In brief, when we use tuning to AMD64, SPECFP2000 (floating point
programs) is 28% worse and SPECINT2000
(integer benchmarks) is 0.6% worse on Intel nocona processor.
When we use tuning to Intel Nocona, SPECFP2000 is 2.7% and SPECINT2000
is 1.6% worse on Opteron.
Code tuned for Intel Nocona parctically always has smaller size.
So I think tunning to nocona by default is a right decision.
10:28 a.m.
On Thu, Jun 09, 2005 at 10:33:03AM -0400, Vladimir Makarov wrote:
When we use tuning to Intel Nocona, SPECFP2000 is 2.7% and
SPECINT2000
is 1.6% worse on Opteron.
And neither specfp or specint are related to anything but compiler and processor
benchmarketing in my experience.
Code tuned for Intel Nocona parctically always has smaller size.
That could well make up for some of the other hit on a real systems
10:27 a.m.
On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote:
Would you like: (a) Small speed hit for Opteron users, OR (b) much
larger speed hit for EM64T users?
(a), ie -mtune=nocona everywhere, seems to be the fairest option here
for everybody since we obviously cannot make 1 build of Fedora Core for
Opteron and 1 comletely separate build of Fedora Core for EM64T.
That sort of depends on market share. I would put a beer on almost all Fedora
64bit users being AMD users because Fedora is appealing to the technically
aware community rather than those whose choice is driven by "business
relationships" as happens in the enterprise space
Alan
10:28 a.m.
On Thu, 2005-06-09 at 11:27 -0400, Alan Cox wrote:
On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote:
> Would you like: (a) Small speed hit for Opteron users, OR (b) much
> larger speed hit for EM64T users?
>
> (a), ie -mtune=nocona everywhere, seems to be the fairest option here
> for everybody since we obviously cannot make 1 build of Fedora Core for
> Opteron and 1 comletely separate build of Fedora Core for EM64T.
That sort of depends on market share. I would put a beer on almost all Fedora
64bit users being AMD users because Fedora is appealing to the technically
aware community rather than those whose choice is driven by "business
relationships" as happens in the enterprise space
However, simply due to sheer marketshare, Intel may in the future have
the most x86_64 processors out there. Where does that leave us?
Dan
6:37 p.m.
Dan Williams wrote:
On Thu, 2005-06-09 at 11:27 -0400, Alan Cox wrote:
>On Thu, Jun 09, 2005 at 10:15:48AM -0400, Dan Williams wrote:
>
>>Would you like: (a) Small speed hit for Opteron users, OR (b) much
>>larger speed hit for EM64T users?
>>
>>(a), ie -mtune=nocona everywhere, seems to be the fairest option here
>>for everybody since we obviously cannot make 1 build of Fedora Core for
>>Opteron and 1 comletely separate build of Fedora Core for EM64T.
>
>That sort of depends on market share. I would put a beer on almost all Fedora
>64bit users being AMD users because Fedora is appealing to the technically
>aware community rather than those whose choice is driven by "business
>relationships" as happens in the enterprise space
However, simply due to sheer marketshare, Intel may in the future have
the most x86_64 processors out there. Where does that leave us?
Including x86_64 celerons...
Warren
10:55 a.m.
On Thu, Jun 09, 2005 at 11:27:03AM -0400, Alan Cox wrote:
That sort of depends on market share. I would put a beer on almost
all
Fedora 64bit users being AMD users because Fedora is appealing to the
technically aware community rather than those whose choice is driven by
"business relationships" as happens in the enterprise space
I'm not sure that's a safe beer. At Boston University, there's big pressure
to buy from Approved Vendors, and the current Approved Vendor Of Choice is
Dell -- and that means, pretty much Intel. Academia isn't exactly
"enterprise space" but we definitely have some things in common.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Current office temperature: 80 degrees Fahrenheit.
9:15 a.m.
On 6/9/05, kas <kas11(a)tampabay.rr.com> wrote:
Of course, on through -m64 was as expected. I'm just a bit
surprised
that it didn't say mtune=k8 since it was definitely building on one ...
which begs the question ... is GCC (and hence the entire x86_64
distribution) being built this way? What are the K8 performance
implications? I've seen a few things that indicate that Nocona cores
running K8 code look pretty bad in some areas compared to optimized
code...however, I find nothing to indicate how nocona optimized code
runs on the K8.
Well... if you really want to find out for yourself you could run benchs.
I'm pretty confident that the distro-wide settings are close to the
best if not the best settings to provide the best average performance
for people using the variety of x86_64 chips in the wild. I highly
doubt Core is ever going to decide its worth the support and
maintainence hassle to distro tuned optimally for just a 64bit amd
chip or just a 64bit intel chip. When you are only going to ship one
version of the distro to cover several chips.. you make choices as to
what performance hits your are going to allow. I'm very confident that
the choices made for Core allow both intel and amd hardware users to
have reasonable good performance from the same binaries.
-jef
1:34 a.m.
On Thu, 2005-06-09 at 10:15 -0400, Jeff Spaleta wrote:
I highly
doubt Core is ever going to decide its worth the support and
maintainence hassle to distro tuned optimally for just a 64bit amd
chip or just a 64bit intel chip. When you are only going to ship one
version of the distro to cover several chips.. you make choices as to
what performance hits your are going to allow.
Also, nothing stops anyone to respin the distro with different compiler
options.
(nothing besides time and effort)
--
Florin Andrei
http://florin.myip.org/
6913
days inactive
6917
days old
17 comments
13 participants
participants (13)
-
Alan Cox -
Arjan van de Ven -
Bill Rugolsky Jr. -
Dan Williams -
Florin Andrei -
Horst H. von Brand -
Jef Spaleta -
kas -
Matthew Miller -
Pádraig Brady -
Tomas Mraz -
Vladimir Makarov -
Warren Togami