CFLAG optimization?

CFLAG optimization?

Post by Christoph » Thu, 20 May 2004 09:05:58


Hi there,

a friend of mine is using gentoo, and while talking he recommended me to optimize my make.conf. I
had a look around the web, but there does not seem to be much information on what is possible, what
is recommended, what is "stable" or "fast"...

right now I have
CPUTYPE?=athlon-xp
CFLAGS=-O -pipe

in there, but he said there are such things as -OS and -O3?

I appreciate any information :)
--
Focx

XXXX@XXXXX.COM
http://www.yqcomputer.com/
http://www.yqcomputer.com/

"F mich gibt es nur das Gehen auf Wegen die Herz haben, auf jedem Weg
gehe ich, der vielleicht ein Weg ist, der Herz hat. Dort gehe ich, und
die einzige lohnende Herausforderung ist, seine ganze Lge zu gehen.
Und dort gehe ich und sehe und sehe atemlos."
- Don Juan
 
 
 

CFLAG optimization?

Post by Devo » Thu, 20 May 2004 10:09:39


You'll find that -O3 will often break things (and you should not compile
a kernel with it). You can often get away with -O2...though sometimes
compiling a kernel with this won't work. As for the real speed
enhancements gained from such optimizations I can't comment as I haven't
done such testing. See the following for more info:

http://www.yqcomputer.com/

Devon

 
 
 

CFLAG optimization?

Post by Kris Kenna » Thu, 20 May 2004 18:00:02


Beyond the feelings of extreme leetness that compiling with high
optimizations can give you, you're unlikely to notice any performance
benefits, simply because most applications you run are not CPU bound.

For those applications that are CPU-bound, you might be able to
measure a performance improvement if you recompile them with higher
optimization settings, but you have to balance this against the very
real possibility that gcc will produce broken code at the higher
setting (yes, this sometimes happens!).

The bottom line is: unless you're willing to deal with the possibility
of your system misbehaving in very odd ways, stick with the system
defaults.

Kris
 
 
 

CFLAG optimization?

Post by jpd » Thu, 20 May 2004 19:08:43


[snip]

Kris hardly needs backing up, but I'm feeling silly today so I'm doing
so anyway. In short, ``What he said.'' I'll add some bits:

There are some specific applications that can --and do-- benefit from
compilation with processor-specific enhancement support. I'm not talking
about -O42 -fextra-fast but about things like using MMX and SSE if your
processor supports that. This usually has to do with practical math,
like fft-libraries (needed for certain video formats and such) and much
less with more mundane things like pushing data back and forth, waiting
for IO, doing context switches, ... The ports system usually has switches
for those libraries that support tricks like that, and some even announce
those capabilities when you build them. Those switches can go in make.conf.

(sidenote: using extentions and optimizations in your kernel --apart
from the extra-clever code that outsmarts and thus breaks the ``you
are not expected to understand this''-bits of code-- usually has to do
with making data transfers or zeroing pages faster. The data transfers
are (well, should be) IO-bound, not CPU-bound, so that doesn't get you
much. As for zeroing pages, FreeBSD pre-zeroes pages in the idle loop.
Meaning that you're optimizing your idle loop at the cost of system
stability. Great.)

On a more general level: Real benefits are much easier to be had by
optimizing on a global scale, like 1) replacing algorithms, 2) switching
to a better compiler like FreeBSD 5 did by moving to gcc 3, or using
using icc for your computationally intensive things, 3) tuning your
system (which is different from recompiling with higher optimisation),
4) changing the way you work.

Squeezing out the last little bit of theoretical performance there is
a bit futile. Of course you can, but I'd rather buy better designed
hardware instead. Come to think of it, here's an idea:

Putting your machine in a second hand fridge to make _sure_ it runs
cool may be the cheapest and easiest way to squeeze the last bits of
performance out of expensively bought peecee crap. Might help with
noise isolation, too. You will have condensation problems as soon as
you open the door, though.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
 
 
 

CFLAG optimization?

Post by Christoph » Fri, 21 May 2004 04:52:17


[snip]

thanks!

Then, beside the links already posted, are there any cheap tricks to tune my system (or complicated,
50-page-long cryptical stuff) you could recommend?

A friend of mine has a similiar machine and told me my system seems to be a lot slower than his -
any suggestions what a possible bottleneck could be?

--
Focx

XXXX@XXXXX.COM
http://www.yqcomputer.com/
http://www.yqcomputer.com/

"F mich gibt es nur das Gehen auf Wegen die Herz haben, auf jedem Weg
gehe ich, der vielleicht ein Weg ist, der Herz hat. Dort gehe ich, und
die einzige lohnende Herausforderung ist, seine ganze Lge zu gehen.
Und dort gehe ich und sehe und sehe atemlos."
- Don Juan
 
 
 

CFLAG optimization?

Post by karg » Fri, 21 May 2004 05:27:04

In article <c8gdss$l1i$ XXXX@XXXXX.COM >,
Christoph Rupprecht < XXXX@XXXXX.COM > writes:

This really depends on what you intend to do with the system.


A lot slower at doing what? Network transfer? Numerical computations?
*** ?

You also have failed to tell us anything about the hardware or
which version of FreeBSD you are using.

--
Steve
http://www.yqcomputer.com/ ~kargl/
 
 
 

CFLAG optimization?

Post by bv » Thu, 08 Jul 2004 02:55:01

In article <c8gdss$l1i$ XXXX@XXXXX.COM >,



Without knowing such critical things as CPU, memory, and brand and
model number of the disk drives, along with NIC cards [if you
include those in the slowness] there is no way to tell.

You need to perform timing. If something just 'feels' slower that
even could come down to a video card making things seem slower.

Run identical tests on both machines and then see how much slower
one is over the other - and the compare the pieces.

Anything else is just throwing time and money out the window.


--
Bill Vermillion - bv @ wjv . com