A tale of computing thud and blunder
 

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>

A tale of computing thud and blunder
 

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"

A tale of computing thud and blunder
 

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,

A tale of computing thud and blunder
 

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"

A tale of computing thud and blunder
 

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.

A tale of computing thud and blunder
 

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"

A tale of computing thud and blunder
 

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,

A tale of computing thud and blunder
 

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.

A tale of computing thud and blunder
 

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.