1 |
Chris Gianelloni said: |
2 |
[SNIP] |
3 |
> Gentoo is not all about performance. While many of our users want to |
4 |
> squeeze the every drop of performance out of their systems, many use |
5 |
> Gentoo for any number of other reasons such as our philosophy, our |
6 |
> community, the manageability of portage, or even because they think |
7 |
> Larry the Cow just owns. |
8 |
> |
9 |
hehe. I totally agree. I choose Gentoo for the flexibility, for instance |
10 |
in getting the programversions I want to use - except I'm sad that |
11 |
gcc-versions get phased out too quickly IMHO, so I can't easily choose to |
12 |
stay with an "old" gcc like 3.2.2 - without running into packages I |
13 |
suddenly can't upgrade automatically, because they depend on a newer GCC, |
14 |
which I can see no reason for them to do. |
15 |
|
16 |
This would ofcourse not be so big a problem, if we had proper reverse |
17 |
depedencies - but like things are now - I must admit I'm afraid of |
18 |
upgrading gcc/glibc on a machine in production.. have been bitten by that |
19 |
one before (I always have package of the old one - but still). |
20 |
[SNIP] |
21 |
> |
22 |
> I just want to ask where the manpower to do this will come from? We |
23 |
> would have to start over with every CPU upgrade and every toolchain |
24 |
> upgrade. It appears it would be an unending task of hours upon hours of |
25 |
> labor for each package. Have you looked at the sheer number of CFLAGS |
26 |
> available? |
27 |
> |
28 |
You are probably right - especially when I'm told that gcc-3.5 has great |
29 |
profiling capabilities (GIMPLE - whatever that is :) - which I agree would |
30 |
be the better solution (so people can easily optimize their machine - |
31 |
doing profiles for their usage). |
32 |
|
33 |
>> I would suggest these tests be included like the gentoo-stats program, |
34 |
>> as |
35 |
>> something the individual Gentooist can choose to run after each compile |
36 |
>> - |
37 |
>> which would give him the optimal performance (and recompile X number of |
38 |
>> times to test different flags out) on his CPU/program/GCCversion |
39 |
>> combination, and at the same time, send the result to a Gentoo database. |
40 |
> |
41 |
> I see no problem with it provided you could find someone to actually do |
42 |
> the work. This would be *very* boring work for most, which means it |
43 |
> would be abandoned by anyone but the most determined quite quickly. |
44 |
> |
45 |
Agreed - that's why I wanted to "throw it out there" - so I could get |
46 |
some feedback on the idea and see if it would stick. |
47 |
|
48 |
[SNIP] |
49 |
>> What do you think? am I crazy? It seems to me that the anandtech tests |
50 |
>> shows that it is more than just a 1% or 2% difference, with the right |
51 |
>> CFLAGS - and that the right CFLAGS for one program, can be the worst for |
52 |
>> another on same CPU/GCC combination. |
53 |
> |
54 |
> While I agree that there can be great performance increases, I believe |
55 |
> that there is a definite trade-off between performance and |
56 |
> manageability. This would be wholly unmanageable without an army of |
57 |
> testers working around the clock until Gentoo ceased to be... *grin* |
58 |
> |
59 |
The idea would ofcourse be that, only the "obvious" programs would be |
60 |
tested - but if profiling were implemented/possible with gcc-3.5 and |
61 |
portage easily - I'm fairly certain that would be of more value (would |
62 |
that also help select the right CFLAGS ?) |
63 |
|
64 |
-- |
65 |
Regards, |
66 |
Klavs Klavsen, GSEC - kl@××××.dk - http://www.vsen.dk |
67 |
PGP: 7E063C62/2873 188C 968E 600D D8F8 B8DA 3D3A 0B79 7E06 3C62 |
68 |
|
69 |
"Those who do not understand Unix are condemned to reinvent it, poorly." |
70 |
--Henry Spencer |
71 |
|
72 |
|
73 |
-- |
74 |
gentoo-dev@g.o mailing list |