1 |
On Wed, 2004-09-08 at 06:15, Klavs Klavsen wrote: |
2 |
> To me this clearly shows, that if Gentoo wants the best performance - we |
3 |
> can't use a "one cflags fits them all" approach. I do know that if a |
4 |
> program breaks, those CFLAGS are pulled out in the individual ebuild, but |
5 |
> this is not due to poor performance. |
6 |
|
7 |
Gentoo is not all about performance. While many of our users want to |
8 |
squeeze the every drop of performance out of their systems, many use |
9 |
Gentoo for any number of other reasons such as our philosophy, our |
10 |
community, the manageability of portage, or even because they think |
11 |
Larry the Cow just owns. |
12 |
|
13 |
> IMHO the only way for Gentoo to prove its true potential - is to somehow |
14 |
> build an array of compile options, with CPU's on X, programs on Y and |
15 |
> GCC-version on Z. Getting the numbers for each CPU, will ofcourse require |
16 |
> writing tests, for each program - but IMHO this can be done, if we do it |
17 |
> one at a time. |
18 |
|
19 |
I just want to ask where the manpower to do this will come from? We |
20 |
would have to start over with every CPU upgrade and every toolchain |
21 |
upgrade. It appears it would be an unending task of hours upon hours of |
22 |
labor for each package. Have you looked at the sheer number of CFLAGS |
23 |
available? |
24 |
|
25 |
> I would suggest these tests be included like the gentoo-stats program, as |
26 |
> something the individual Gentooist can choose to run after each compile - |
27 |
> which would give him the optimal performance (and recompile X number of |
28 |
> times to test different flags out) on his CPU/program/GCCversion |
29 |
> combination, and at the same time, send the result to a Gentoo database. |
30 |
|
31 |
I see no problem with it provided you could find someone to actually do |
32 |
the work. This would be *very* boring work for most, which means it |
33 |
would be abandoned by anyone but the most determined quite quickly. |
34 |
|
35 |
> I know I would definetely have the patience to let it test and test again, |
36 |
> if it meant more performance for me Smile |
37 |
|
38 |
Excellent. Nothing is stopping you from doing exactly this on your own |
39 |
machine, though, so go for it. |
40 |
|
41 |
> The end result should be, that Gentoo automagically selects the optimal |
42 |
> CFLAGS (in performance and stability - perhaps with some optimizations |
43 |
> flagged as "unstable" so people can select "optimize for performance" vs. |
44 |
> "optimize for stability") depending on the X, Y and Z from above. |
45 |
|
46 |
Well, as soon as you enter in the possibility of user-defined |
47 |
selections, then there is no point. If we're going for optimal |
48 |
performance, we shoot for optimal performance. After all, with all this |
49 |
test data who would know better, us, or each individual user who may or |
50 |
may not have performed all the testing? |
51 |
|
52 |
> I would very much like to be one of the guys that gets the ball rolling, |
53 |
> but as I'm not a Gentoo Dev - We (or just I) need to agree with the Gentoo |
54 |
> Dev's on how this could best be done. |
55 |
|
56 |
You don't have to be a developer to get involved. That is one of the |
57 |
greatest things about Gentoo. |
58 |
|
59 |
> What do you think? am I crazy? It seems to me that the anandtech tests |
60 |
> shows that it is more than just a 1% or 2% difference, with the right |
61 |
> CFLAGS - and that the right CFLAGS for one program, can be the worst for |
62 |
> another on same CPU/GCC combination. |
63 |
|
64 |
While I agree that there can be great performance increases, I believe |
65 |
that there is a definite trade-off between performance and |
66 |
manageability. This would be wholly unmanageable without an army of |
67 |
testers working around the clock until Gentoo ceased to be... *grin* |
68 |
|
69 |
-- |
70 |
Chris Gianelloni |
71 |
Release Engineering - Operations/QA Manager |
72 |
Games - Developer |
73 |
Gentoo Linux |
74 |
|
75 |
Is your power animal a penguin? |