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 |