Gentoo Archives: gentoo-amd64

From: Beso <givemesugarr@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Problems configuring gentoo
Date: Sat, 04 Oct 2008 14:37:40
Message-Id: d257c3560810040737u635e562ag36b4f6637b1baf40@mail.gmail.com
In Reply to: Re: [gentoo-amd64] Problems configuring gentoo by Richard Freeman
1 2008/10/4 Richard Freeman <rich0@g.o>:
2 > Ben de Groot wrote:
3 >>
4 >> -Os optimizes for size, while -O2 optimizes for speed. There is no need
5 >> at all to use -Os on a modern desktop machine, and it will run
6 >> comparatively slower than -O2 optimized code, which is probably not what
7 >> you want.
8 >>
9 >
10 > There are a couple of schools of thought on that, and I think performance
11 > can depend a great deal on what program you're talking about.
12 >
13 > On any machine, memory is a limited resource. Oh sure, you could just
14 > "spend a little more on decent RAM", but you could also "spend a little more
15 > on a decent CPU" or whatever. For a given amount of money you can only buy
16 > so much hardware, so any dollar spent on RAM is a dollar not spent on
17 > something else.
18 >
19 > So, if you reduce the memory footprint of processes, then you increase the
20 > amount of memory available for buffers/cache. That cache is many orders of
21 > magnitude faster than even the fastest hard drive. You also reduce swapping
22 > which obviously greatly slows things down.
23 >
24 > On the other hand, if you have a smaller program that does
25 > highly-CPU-intensive tasks like compression/transcoding/etc then speed
26 > optimization makes sense just about all the time (generally -O2 only - -O3
27 > sometimes does worse due to L2 cache misses).
28 >
29 > So, there are trade-offs. To make things even more complicated the
30 > practical results can be impacted by your CPU model - different CPUs have a
31 > different cost for looping/jumping/branching vs cache misses. And the
32 > compiler makes a big difference - many of these observations date back to
33 > the gcc 3.4 days. I've heard that newer GCC versions are more aggressive
34 > with size optimization at the expense of speed, which could tip the balance.
35 >
36 > A while back there were some posts from folks who had done some actual
37 > benchmarking. I don't think it has been repeated. Note that I wouldn't
38 > expect -Os to have much benefit unless you compile EVERYTHING on the system
39 > that way - since the freeing up of memory is cumulative. The rather high
40 > level of pain associated with rebuilding your system with -Os vs -O2 for
41 > some benchmarking and subjective evaluation is probably the reason why
42 > everybody has an opinion but there isn't much hard data.
43 >
44 > Right now I'm using -Os across the board, and -O2 on an exception basis.
45 > Maybe I should give that some more thought...
46 >
47 >
48
49 well, Os not only does O2 but does also some O3 safe flags and some
50 size optimizations. if you look at the -Os vs O2 and vs O3
51 optimization you'll see that most of the O3 flags that you want over
52 O2 are insinde Os. i've actually tried out O2, O3 and Os and found out
53 that O3 is sometimes faster (not everytime and especially with system
54 packages is even slower than O2) while Os is almost always faster than
55 O2. this leads me to think that if something is faster and also
56 smaller then it really worths trying it out. i've made a comparison on
57 gcc 4.1.0 with all the system and world built with a single option (of
58 course some packages have harcoded ebuild optimization and won't be
59 affected). when i'll have some spare time i'll look out for the
60 reports and post them.
61
62 --
63 dott. ing. beso