1 |
On 14/03/13 23:52, Dale wrote: |
2 |
> Mateusz Kowalczyk wrote: |
3 |
>> On 14/03/13 22:41, Dale wrote: |
4 |
>>> Grant Edwards wrote: |
5 |
>>>> On 2013-03-14, Dale <rdalek1967@×××××.com> wrote: |
6 |
>>>> |
7 |
>>>>> I was wondering. Has anyone ever seen where a test as been done to |
8 |
>>>>> compare the speed of Gentoo with other distros? Maybe Gentoo compared |
9 |
>>>>> to Redhat, Mandrake, Ubuntu and such? |
10 |
>>>> I just did a test, and they're all the same. |
11 |
>>>> |
12 |
>>>> CDs/DVDS of various distros dropped from a height of 1m all hit the |
13 |
>>>> floor simultaneously [there are random variations due to aerodynamic |
14 |
>>>> instability of the disk shape, but it's the same for all distros]. If |
15 |
>>>> launched horizontally with spin to provide attitude stability (thrown |
16 |
>>>> like a frisbee), they all fly the same. |
17 |
>>>> |
18 |
>>>> The point being, you're going to have to define "speed". |
19 |
>>>> |
20 |
>>>> Does speed refer to |
21 |
>>>> |
22 |
>>>> Installation time? |
23 |
>>>> |
24 |
>>>> Boot time? |
25 |
>>>> |
26 |
>>>> Linpack? |
27 |
>>>> |
28 |
>>>> Dhrystone? |
29 |
>>>> |
30 |
>>>> Whetstone? |
31 |
>>>> |
32 |
>>>> Time for me to figure out how to fix a configuration problem? |
33 |
>>>> |
34 |
>>>> Time to do to an update on a machine that's been unplugged for a year? |
35 |
>>>> |
36 |
>>>> Time to to produce a packaged version of some random C program that |
37 |
>>>> comes with a Makefile that uses autotools? |
38 |
>>>> |
39 |
>>>> Time for a reported bug to get fixed? |
40 |
>>>> |
41 |
>>> |
42 |
>>> OK. It appears not very many can figure out what I asked for. So, let |
43 |
>>> me spell it out for those who are challenged. LOL ;-) Read some |
44 |
>>> humor into that OK. |
45 |
>>> |
46 |
>>> Install a OS. Run tests on a set of programs and record the time it |
47 |
>>> takes to complete a certain task. More tasks the better. |
48 |
>>> |
49 |
>>> Then install another OS on the same hardware. Run tests on a set of |
50 |
>>> programs and record the time it takes to complete a certain task. More |
51 |
>>> tasks the better. |
52 |
>>> |
53 |
>>> The object of this is, does Gentoo with the customization it allows run |
54 |
>>> faster than some binary install that does NOT allow those controls? In |
55 |
>>> other words, can a Gentoo based install perform more efficiently than a |
56 |
>>> binary based install like Redhat, Ubuntu or some other distro? |
57 |
>>> |
58 |
>>> I am NOT concerned about compile times or the install itself. |
59 |
>>> |
60 |
>>> Does that put the dots closer together for the challenged ones? ROFL |
61 |
>>> |
62 |
>>> Dale |
63 |
>>> |
64 |
>>> :-) :-) |
65 |
>>> |
66 |
>> The point of the challenged ones was that while we can take measurements |
67 |
>> like these, it's rather meaningless to do so. The result will be |
68 |
>> different for every single person out there depending on their |
69 |
>> configuration, USE, CFLAGS and who knows what else. |
70 |
>> |
71 |
>> I can compile a package with support for 3 different DEs, few WMs, oss |
72 |
>> and alsa and about a billion things I will never use. Does this make for |
73 |
>> a more or less of a meaningful test than doing the same test with no |
74 |
>> flags what so ever? There is no correct answer as it varies per user |
75 |
>> basis. The most meaningful measurements that we can probably take would |
76 |
>> be between different USE flags configurations. Maybe we can say that |
77 |
>> package ‘foo’ with certain USE and CFLAGS runs in less average time than |
78 |
>> the same package on a distro Bar. |
79 |
>> |
80 |
>> In my opinion, it would be far more meaningful to measure the effect of |
81 |
>> different USE flags on the same package, *in relative time* on the same |
82 |
>> system. This would give us more idea about the impact of each flag as |
83 |
>> opposed to a very limited view of ‘package foo with certain specific USE |
84 |
>> flags runs 10ms faster than the same package on the same hardware on a |
85 |
>> binary distribution’. If you still want such measurements and you want |
86 |
>> them to be somewhat meaningful to you, it is you who will have to take |
87 |
>> them. Unless there are some gross inconsistencies in run times on |
88 |
>> different distributions, we have no use for such measurement. |
89 |
>> |
90 |
>> Everyone understood what you asked for. It's _you_ that misunderstood |
91 |
>> their explanation for why it's meaningless to ask such a question in the |
92 |
>> first place. |
93 |
>> |
94 |
> |
95 |
> I didn't miss anything. I get what some are saying. The reason for my |
96 |
> question is this. Gentoo allows a person to customize the OS to the |
97 |
> specific hardware it is being run on. Redhat and other binary distros |
98 |
> don't allow this, unless you compile your own packages which is no |
99 |
> longer really a binary install. |
100 |
> |
101 |
> So, if I install Redhat on my machine, would it be less efficient than |
102 |
> my Gentoo install which is customized for my hardware? Has someone else |
103 |
> tested this and made it public? |
104 |
> |
105 |
> If people can't get this, never mind. |
106 |
> |
107 |
> Dale |
108 |
> |
109 |
> :-) :-) |
110 |
> |
111 |
|
112 |
I don't think that it's plausible to take such measurement. We could set |
113 |
every USE flag possible for the package we are benchmarking to try and |
114 |
replicate the support for everything that the binary package is likely |
115 |
to have. We also have to do this for all its dependencies (and their |
116 |
dependencies and so on) to have nothing that could potentially influence |
117 |
the measurement. Assuming that portage complies with this (it won't), we |
118 |
compile the package with optimizations for our hardware. The result? We |
119 |
probably have the same result on Gentoo and the other distro. |
120 |
|
121 |
Why? The reason is simple: binary distributions provide packages |
122 |
compiled with optimizations turned on for specific architectures. Unless |
123 |
you are doing some unheard of optimizations for your obscure model of |
124 |
the CPU, I don't imagine you'd get much advantage at all. If the |
125 |
maintainer of the binary package compiles it with optimizations for an |
126 |
i7 and you do the same, why should the performance be different? |
127 |
|
128 |
If you install RedHat on your machine, it probably will be less |
129 |
efficient than Gentoo but for a different reason. It won't be |
130 |
(noticeably) more efficient because you've got your CFLAGS set in a |
131 |
particular way but it because you only install the packages you actually |
132 |
want and remove support for things you don't need. Why bloat a package |
133 |
and waste cycles having it try to poll a service you might never |
134 |
actually use? Gentoo lets you get rid (or never install in the first |
135 |
place) of this kind of… bloat while you don't have much choice on a |
136 |
binary package short of compiling everything by hand at which point you |
137 |
should be using Gentoo to do it for you. |
138 |
|
139 |
RedHat maintainers aren't stupid (you can probably tell I've never used |
140 |
RH) – they will release packages optimized for architectures they will |
141 |
run on. Overall you might get very slight performance boost because of |
142 |
some CFLAG you enable but you might as well have worse performance |
143 |
because you don't know as much about optimizations as the RH maintainers |
144 |
and developers. Bah, you can even find examples on Gentoo wiki where |
145 |
compiling certain packages with certain flags actually makes them slower |
146 |
and not faster where usually the opposite is the case. |
147 |
|
148 |
-- |
149 |
Mateusz K. |