Re: About GCC optimizations

["Joel CARNAT" <joel%carnat.net@localhost>]

> Joel CARNAT <joel%carnat.net@localhost> wrote:
>
>> On Tue, Mar 11 2008 - 17:47, Valeriy E. Ushakov wrote:
>>
>>> Having worked with people who do hardcoreperformance tuning as their
>>> day job, one thing I've learned from them is that you probably
>>> shouldn't even bother thinking about performance unless you measured
>>> it and you understand specific conditions under which your system runs
>>> and what kind of workloads you are optimizaing for.
>>>
>>> So don't lose much time on this, you'll waste more time than any
>>> improvements from highly fine-tuned -O* -f* are going to save you in
>>> the few following years while the system you are optimizaing is still
>>> useful. :) if -Os is what makes you feel good, just stick with it :)
>>
>> heh, not that I particularily matter at all.
>
> I'm sorry if that remark came across as a snub.  That's just something
> I have to remind myself about when I get into "let's `optimize' it"
> mood, so I though I might as well share it.  I didn't realize you had
> those specific conditions and workloads you are optimizing for.
>

No problem at all :-D
I ask for feedback, so I expect feedback ;-)

I use to use Gentoo Linux at works and used to apply bunch of CFLAGS all
over the Makefiles (as described in their docs). And I'm far from being
convinced that this gives "better" binary. I looked like it was more
trouble than anything else - but maybe only because of bad GCC. I often
read from here to there that GCC is not that nice. Some say it's getting
worse and worse with time.

The thing is I bought this little box to build a multimedia box.
It seems to be designed too (according specs reviews and people running XP
or Linux multimedia based things on it).
So I'm just trying to do the same with NetBSD - because I believe NetBSD
can do it too.

>
>> maybe I'm taking it from the wrong side.
>> but how to make sure that things that can be done on the hardware level
>> is not done on the software level. I'm thinking of hardware to MPEG2
>> decoding, or MMX/SSE CPU feature.
>
> As was already suggested make sure your packages are built with those
> features enabled if they provide such options.  If they do run-time
> autodetection, make sure they do detect MMX/SSE.
>

MPlayer says so at start time.

> Try both -O2 and -Os -freorder-blocks (i.e. -O2 sans -faling*) to see
> if there's any difference.
>

-Os and -O2 don't seem to be very different from what I tested.
I've never tried '-freorder-blocks' though.
So I'll go for another build process and try that.

Best regards,
   Jo