[gentoo-user] -march=native is *EXTREMELY* conservative

[gentoo-user] -march=native is *EXTREMELY* conservative

[Walter Dnes]

  Here's the setup of my secondary machine..  It's a Dell Inspiron
Desktop 530, with 2 gigs of ram, assembled and shipped August 2007.  It
has an Intel Core2 (*NOT* a "Core2 Duo") cpu.  From /proc/cpuinfo...

vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Genuine Intel(R) CPU            2140  @ 1.60GHz
stepping        : 2
cpu MHz         : 1595.660
cache size      : 1024 KB

  Here are the cpu flags...

waltdnes@d530 ~ $ grep flags /proc/cpuinfo
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl
est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts

  Then I ran "gcc -march=native -Q --help=target" and got a major shock.
It's a long output listing of what -march=native thinks about my cpu.
Here are some relevant items...

-march=                               core2
-mmmx                                 [disabled]
-msse                                 [disabled]
-msse2                                [disabled]
-msse3                                [disabled]
-mssse3                               [disabled]

  It properly identified the cpu as "core2".  But mmx, sse, sse2, sse3
(aka pni), and ssse3 are disabled!!! 

  The reason I dug into this was that I was trying to 1920x1080i
streaming video from my HDHomerun TV tuner box.  I originally used

CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe"

when setting up the system.  It could not handle 1920x1080i streaming TV
video.

  After findinding out about "-native", I changed CFLAGS to...

CFLAGS="-O2 -march=native -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=sse -fomit-frame-pointer -pipe"

...and emerged system and world and rebuilt the kernel.  Now the onboard
Intel GPU handles 1920x1080i flawlessly.  As a matter of fact, it
handles 1080p flawlessly.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] -march=native is *EXTREMELY* conservative

[Dale]

Walter Dnes wrote:
> gcc -march=native -Q --help=target

If that shows something disabled that cat /proc/cpuinfo shows as 
available, is it safe to turn it on?  So far all I have found that is 
disabled that cpuinfo shows is mmx.  I'm still looking tho.

Also, I think the native setting is a setting that is known to be 100% 
safe.  It is likely one of those things that if you use anything not 
safe and have problems, you get to keep the pieces.  I think if the CPU 
supports it should be fine to turn but wanted to ask and make sure.  I 
paid almost $200 for my CPU and I would like to get $200 out of it and 
use it all.  I bought the whole thing so may as well use the whole 
thing.  ;-)

Thoughts?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[gentoo-user] Re: -march=native is *EXTREMELY* conservative

[Nikos Chantziaras]

On 12/17/2011 11:07 PM, Walter Dnes wrote:
>
>    Then I ran "gcc -march=native -Q --help=target" and got a major shock.
> It's a long output listing of what -march=native thinks about my cpu.
> Here are some relevant items...
>
> -march=                               core2
> -mmmx                                 [disabled]
> -msse                                 [disabled]
> -msse2                                [disabled]
> -msse3                                [disabled]
> -mssse3                               [disabled]
>
>    It properly identified the cpu as "core2".  But mmx, sse, sse2, sse3
> (aka pni), and ssse3 are disabled!!!

The output lies.  It's a known issue.  Use this instead:

   echo | gcc -dM -E - -march=native

You should see stuff like:

   #define __MMX__ 1
   #define __SSE3__ 1

Re: [gentoo-user] Re: -march=native is *EXTREMELY* conservative

[Walter Dnes]

On Sat, Dec 17, 2011 at 11:58:36PM +0200, Nikos Chantziaras wrote

> The output lies.  It's a known issue.  Use this instead:
> 
>    echo | gcc -dM -E - -march=native
> 
> You should see stuff like:
> 
>    #define __MMX__ 1
>    #define __SSE3__ 1

  The onboard GPU was initially incapable of handling 1080i video without
stuttering badly and dropping frames.  After explicitly changing the
flags and rebuilding system+world+kernel, it displays 1080p videos
flawlessly.  That's one big "co-incidence".

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] Re: -march=native is *EXTREMELY* conservative

[Walter Dnes]

On Sat, Dec 17, 2011 at 08:10:54PM -0500, Walter Dnes wrote

>   The onboard GPU was initially incapable of handling 1080i video without
> stuttering badly and dropping frames.  After explicitly changing the
> flags and rebuilding system+world+kernel, it displays 1080p videos
> flawlessly.  That's one big "co-incidence".

  This was only recently installed.  Is it possible that the generic x86
code from the initial install was the problem?  And that emerging
system+world got me full optimization?

-- 
Walter Dnes <waltdnes@waltdnes.org>

[gentoo-user] Re: -march=native is *EXTREMELY* conservative

[Nikos Chantziaras]

On 12/18/2011 12:34 PM, Walter Dnes wrote:
> On Sat, Dec 17, 2011 at 08:10:54PM -0500, Walter Dnes wrote
>
>>    The onboard GPU was initially incapable of handling 1080i video without
>> stuttering badly and dropping frames.  After explicitly changing the
>> flags and rebuilding system+world+kernel, it displays 1080p videos
>> flawlessly.  That's one big "co-incidence".
>
>    This was only recently installed.  Is it possible that the generic x86
> code from the initial install was the problem?  And that emerging
> system+world got me full optimization?

Could be.  It could also be it's because of "-mfpmath=sse".  That's only 
used by default on 64-bit.  On 32-bit, the FPU is used for floating 
point operations by default, which gives better precision (80 bit vs 64 
bit) but slower speed.

But then again, that sounds too much of a performance difference.  So if 
I had to guess, I'd say it's because of the world rebuild that made sure 
everything was built with proper optimizations.

Re: [gentoo-user] Re: -march=native is *EXTREMELY* conservative

[Andrea Conti]

> Could be.  It could also be it's because of "-mfpmath=sse". 

AFAIK most video decoders (outside of reference implementations) are
written using integer math only... -O3 is a much more likely candidate.

andrea

[gentoo-user] A tale of computing thud and blunder

[Walter Dnes]

On Sun, Dec 18, 2011 at 12:45:27PM +0200, Nikos Chantziaras wrote
>
> On 12/18/2011 12:34 PM, Walter Dnes wrote:
> >
> >    This was only recently installed.  Is it possible that the generic x86
> > code from the initial install was the problem?  And that emerging
> > system+world got me full optimization?
> 
> Could be.  It could also be it's because of "-mfpmath=sse".  That's only 
> used by default on 64-bit.  On 32-bit, the FPU is used for floating 
> point operations by default, which gives better precision (80 bit vs 64 
> bit) but slower speed.
> 
> But then again, that sounds too much of a performance difference.  So if 
> I had to guess, I'd say it's because of the world rebuild that made sure 
> everything was built with proper optimizations.

  It's probably the sum total of the effect of all the flags.  I've
renamed the thread, to be more accurate.  Here's how things went...

* right after the install (presumably with generic i686 code) the PC
  could not handle streaming 1080i video from my HDHomerun TV tuner

* I misinterpreted output from gcc diagnostics, and concluded that
  "march=-native" left several flags disabled that shouldn't be

* acting on that (mis)information), I emerged system+world+kernel and
  found that not only could my system handle 1080i, it could handle a
  1080p Youtube clip without problems, after a lot of buffering.  My 5
  megabit ADSL connection was the limiting factor there.  It's supposed
  to be upgraded to 6 megabits one of these days, for some minor
  improvement.

* I mistakenly thought that it was the additional flags in CFLAGS during
  the emerge system+world that boosted the video.  Actually, the emerge
  would've done the trick.

  The lesson from this is that, before doing any benchmarking or
heavy-duty usage, one should emerge system+world, to replace the generic
code from the install CD with fully optimized code.  It's easiest to so
right after the initial install, so that there are as few packages to
emerge as possible.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] A tale of computing thud and blunder

[Dale]

Walter Dnes wrote:
> It's probably the sum total of the effect of all the flags. I've 
> renamed the thread, to be more accurate. Here's how things went... * 
> right after the install (presumably with generic i686 code) the PC 
> could not handle streaming 1080i video from my HDHomerun TV tuner * I 
> misinterpreted output from gcc diagnostics, and concluded that 
> "march=-native" left several flags disabled that shouldn't be * acting 
> on that (mis)information), I emerged system+world+kernel and found 
> that not only could my system handle 1080i, it could handle a 1080p 
> Youtube clip without problems, after a lot of buffering. My 5 megabit 
> ADSL connection was the limiting factor there. It's supposed to be 
> upgraded to 6 megabits one of these days, for some minor improvement. 
> * I mistakenly thought that it was the additional flags in CFLAGS 
> during the emerge system+world that boosted the video. Actually, the 
> emerge would've done the trick. The lesson from this is that, before 
> doing any benchmarking or heavy-duty usage, one should emerge 
> system+world, to replace the generic code from the install CD with 
> fully optimized code. It's easiest to so right after the initial 
> install, so that there are as few packages to emerge as possible. 


That is good advice too.  When I do a install, I unpack the tarball and 
do the normal things and get my make.conf settings done.  Since there is 
very little installed anyway, I do a emerge -ev world.  It usually takes 
only a hour or so depending on the speed of the rig.  Thing is, you then 
have everything compiled with your settings and not the generic ones the 
tarball had.  It also updates anything that needs it too.  Even before 
amd64 came along I did it this way.  Lots of people use Intel CPUs but I 
use AMD.  I don't know what the person that made the tarball uses but 
either way, he has to make it generic so that it will run on ANY CPU.

I wonder if they should mention this in the docs?  It seemed to have 
made a difference in your case for sure.  You went from not being able 
to play a video to being able to play a HD video.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] A tale of computing thud and blunder

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

On Dec 19, 2011 7:20 AM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Walter Dnes wrote:
>>
>> It's probably the sum total of the effect of all the flags. I've renamed
the thread, to be more accurate. Here's how things went... * right after
the install (presumably with generic i686 code) the PC could not handle
streaming 1080i video from my HDHomerun TV tuner * I misinterpreted output
from gcc diagnostics, and concluded that "march=-native" left several flags
disabled that shouldn't be * acting on that (mis)information), I emerged
system+world+kernel and found that not only could my system handle 1080i,
it could handle a 1080p Youtube clip without problems, after a lot of
buffering. My 5 megabit ADSL connection was the limiting factor there. It's
supposed to be upgraded to 6 megabits one of these days, for some minor
improvement. * I mistakenly thought that it was the additional flags in
CFLAGS during the emerge system+world that boosted the video. Actually, the
emerge would've done the trick. The lesson from this is that, before doing
any benchmarking or heavy-duty usage, one should emerge system+world, to
replace the generic code from the install CD with fully optimized code.
It's easiest to so right after the initial install, so that there are as
few packages to emerge as possible.
>
>
>
> That is good advice too.  When I do a install, I unpack the tarball and
do the normal things and get my make.conf settings done.  Since there is
very little installed anyway, I do a emerge -ev world.  It usually takes
only a hour or so depending on the speed of the rig.  Thing is, you then
have everything compiled with your settings and not the generic ones the
tarball had.  It also updates anything that needs it too.  Even before
amd64 came along I did it this way.  Lots of people use Intel CPUs but I
use AMD.  I don't know what the person that made the tarball uses but
either way, he has to make it generic so that it will run on ANY CPU.
>
> I wonder if they should mention this in the docs?  It seemed to have made
a difference in your case for sure.  You went from not being able to play a
video to being able to play a HD video.
>

Kind of like what I always do when I switch from -march=nocona to
-march=native. (Usually I use -march=nocona to ensure seamless VM migration
on my XenServer-equipped boxen, but for some VMs, i.e., those requiring me
to wring out every last drop of performance, I go native.)

That said, if you want to experience fully the "GCC Graphite"
optimizations, you'll also want to do emerge -ev ;-)

Rgds,

[-- Attachment #2: Type: text/html, Size: 2821 bytes --]

Re: [gentoo-user] A tale of computing thud and blunder

[Dale]

Pandu Poluan wrote:
>
> Kind of like what I always do when I switch from -march=nocona to 
> -march=native. (Usually I use -march=nocona to ensure seamless VM 
> migration on my XenServer-equipped boxen, but for some VMs, i.e., 
> those requiring me to wring out every last drop of performance, I go 
> native.)
>
> That said, if you want to experience fully the "GCC Graphite" 
> optimizations, you'll also want to do emerge -ev ;-)
>
> Rgds,
>


Is Graphite worthwhile on a desktop system or is it better suited for 
servers or both?  I found this but still not sure what it is intended for:

http://gcc.gnu.org/wiki/Graphite/4.5

Are there any reasons to leave this be for a while?  You know, bugs or 
packages that don't work with it?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[gentoo-user] Re: A tale of computing thud and blunder

[Nikos Chantziaras]

On 12/19/2011 08:15 AM, Dale wrote:
> Pandu Poluan wrote:
>>
>> Kind of like what I always do when I switch from -march=nocona to
>> -march=native. (Usually I use -march=nocona to ensure seamless VM
>> migration on my XenServer-equipped boxen, but for some VMs, i.e.,
>> those requiring me to wring out every last drop of performance, I go
>> native.)
>>
>> That said, if you want to experience fully the "GCC Graphite"
>> optimizations, you'll also want to do emerge -ev ;-)
>
>
> Is Graphite worthwhile on a desktop system or is it better suited for
> servers or both?

This isn't something that even remotely has anything to do with servers 
or desktops.  Just like -O2 does not magically work better on servers.


> I found this but still not sure what it is intended for:
>
> http://gcc.gnu.org/wiki/Graphite/4.5

It's an optimization that produces faster running executables.  Are you 
interested in *how* it works :-)


> Are there any reasons to leave this be for a while? You know, bugs or
> packages that don't work with it?

Just like with any other optimization switch, there can be bugs.  If 
Gentoo says it doesn't support graphite, then I'd stay away from it 
because Gentoo devs might not listen to your bug reports if you use it. 
  I don't know if they support it or not though.

Re: [gentoo-user] Re: A tale of computing thud and blunder

[Dale]

Nikos Chantziaras wrote:
> On 12/19/2011 08:15 AM, Dale wrote:
>> Pandu Poluan wrote:
>>>
>>> Kind of like what I always do when I switch from -march=nocona to
>>> -march=native. (Usually I use -march=nocona to ensure seamless VM
>>> migration on my XenServer-equipped boxen, but for some VMs, i.e.,
>>> those requiring me to wring out every last drop of performance, I go
>>> native.)
>>>
>>> That said, if you want to experience fully the "GCC Graphite"
>>> optimizations, you'll also want to do emerge -ev ;-)
>>
>>
>> Is Graphite worthwhile on a desktop system or is it better suited for
>> servers or both?
>
> This isn't something that even remotely has anything to do with 
> servers or desktops.  Just like -O2 does not magically work better on 
> servers.
>
>

Sounds like it may work on both then.  That's sort of what I was 
thinking but wasn't sure.

>> I found this but still not sure what it is intended for:
>>
>> http://gcc.gnu.org/wiki/Graphite/4.5
>
> It's an optimization that produces faster running executables.  Are 
> you interested in *how* it works :-)
>
>

 From what I read it makes some processes run in parallel instead of 
serial or one at a time.  Some think it is meaningless but some think it 
is awesome.  I don't know what to think since I have not used it or 
compared the differences.


>> Are there any reasons to leave this be for a while? You know, bugs or
>> packages that don't work with it?
>
> Just like with any other optimization switch, there can be bugs.  If 
> Gentoo says it doesn't support graphite, then I'd stay away from it 
> because Gentoo devs might not listen to your bug reports if you use 
> it.  I don't know if they support it or not though.
>

That would be another good thing to know.  I don't file many bug reports 
but if something breaks and it needs one, I do file them.  This may be 
like good wine.  It may need to rest a while longer unless someone else 
knows it is supported and works well.  I got a good install and I don't 
want to break it.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

[gentoo-user] Re: A tale of computing thud and blunder

[walt]

On 12/18/2011 10:49 PM, Nikos Chantziaras wrote:

> Just like with any other optimization switch, there can be bugs. If
> Gentoo says it doesn't support graphite, then I'd stay away from it
> because Gentoo devs might not listen to your bug reports if you use
> it.

I've been using gcc with graphite support for about a year or so and
I've had zero problems so far.  (I should also mention that I haven't
measured how much difference it makes, either.)

Very important to notice that *building* gcc with graphite support is
not at all the same as *using* graphite support while compiling.

To actually *use* your graphite support, you must include these CFLAGS
while compiling each package:

-floop-block -floop-strip-mine -floop-interchange

That implies that you can turn off graphite support by removing those
flags and recompiling your buggy package before filing a bug report.
(I did that only once and discovered that it didn't change the bug
at all.)

IIRC, gcc doesn't use those flags while compiling itself, but I could
be mistaken about that.  I'll check again next time I compile gcc.

Re: [gentoo-user] A tale of computing thud and blunder

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Dec 19, 2011 1:18 PM, "Dale" <rdalek1967@gmail.com> wrote:
>
> Pandu Poluan wrote:
>>
>>
>> Kind of like what I always do when I switch from -march=nocona to
-march=native. (Usually I use -march=nocona to ensure seamless VM migration
on my XenServer-equipped boxen, but for some VMs, i.e., those requiring me
to wring out every last drop of performance, I go native.)
>>
>> That said, if you want to experience fully the "GCC Graphite"
optimizations, you'll also want to do emerge -ev ;-)
>>
>> Rgds,
>>
>
>
> Is Graphite worthwhile on a desktop system or is it better suited for
servers or both?  I found this but still not sure what it is intended for:
>
> http://gcc.gnu.org/wiki/Graphite/4.5
>
> Are there any reasons to leave this be for a while?  You know, bugs or
packages that don't work with it?
>

In my experience, I've never encountered any bugs due to graphite. And I've
"graphite-ed" 4 production servers, including 2 firewalls, 1 DNS server,
and 1 mail server.

Of course, YMMV.

Rgds,

[-- Attachment #2: Type: text/html, Size: 1362 bytes --]

Re: [gentoo-user] A tale of computing thud and blunder

[Paul Hartman]

On Mon, Dec 19, 2011 at 12:15 AM, Dale <rdalek1967@gmail.com> wrote:
> Pandu Poluan wrote:
>>
>>
>> Kind of like what I always do when I switch from -march=nocona to
>> -march=native. (Usually I use -march=nocona to ensure seamless VM migration
>> on my XenServer-equipped boxen, but for some VMs, i.e., those requiring me
>> to wring out every last drop of performance, I go native.)
>>
>> That said, if you want to experience fully the "GCC Graphite"
>> optimizations, you'll also want to do emerge -ev ;-)
>>
>> Rgds,
>>
>
>
> Is Graphite worthwhile on a desktop system or is it better suited for
> servers or both?  I found this but still not sure what it is intended for:
>
> http://gcc.gnu.org/wiki/Graphite/4.5
>
> Are there any reasons to leave this be for a while?  You know, bugs or
> packages that don't work with it?

I used it for @world and ran into a couple times when things were
broken with it enabled... Don't really remember specifics. I didn't
notice any perceivable speed difference, so I stopped using it just to
simplify things in the future. :)

In general,I have changed my CFLAGS to be less aggressive over the
past years. I started with the most aggressive optimizations, and
using -march=whatever... At some point I researched compile times for
different optimizations and realized some packages were taking tens of
minutes longer to compile! Surely whatever potential speed increase of
-O3 vs -O2 was not going to give me tens of minutes cumulatively. If
there is a package that really benefits from some specific
optimization (and doesn't already set those flags itself in the
ebuild), I'll set the CFLAGS for that individual package but leave the
rest of world very simplistic.

Same with -march, I've gone to using -mtune instead, after having to
move hard drives into a system with different CPU feature set. And for
virtual machines (in hosts I don't control, especially), they could be
migrated to some other machine without my knowledge, and i don't want
it to stop working if that happens.

Re: [gentoo-user] -march=native is *EXTREMELY* conservative

[Paul Hartman]

On Sat, Dec 17, 2011 at 3:07 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> -march=                               core2
> -mmmx                                 [disabled]
> -msse                                 [disabled]
> -msse2                                [disabled]
> -msse3                                [disabled]
> -mssse3                               [disabled]
>
>  It properly identified the cpu as "core2".  But mmx, sse, sse2, sse3
> (aka pni), and ssse3 are disabled!!!

I think you may be misinterpreting that output. It's not telling you
that MMX etc. are disabled, it's telling you that the /commandline
options/ are disabled. Why?

From the GCC docs:
"core2: Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3
and SSSE3 instruction set support."

That means those features are implied by -march=core2, adding those
commandline switches would be redundant.