1 |
On 14/03/2013 15:40, Mark David Dumlao wrote: |
2 |
> On 03/14/2013 09:28 PM, Alan McKinnon wrote: |
3 |
>> On 14/03/2013 14:12, Pandu Poluan wrote: |
4 |
>>> On Mar 14, 2013 4:14 PM, "William Kenworthy" <billk@×××××××××.au |
5 |
>>> <mailto:billk@×××××××××.au>> wrote: |
6 |
>>>> Did this few years back for an online magazine sponsored by a local |
7 |
>>>> linux sysadmin company who wanted to see the difference between generic |
8 |
>>>> debian and optimised (not necessarily gentoo, but thats what I used.) |
9 |
>>>> |
10 |
>>>> Difference in times was ~10% across the board for graphics manipulations |
11 |
>>>> (gimp scripts), spreadsheet tasks (gnumeric) and the like. |
12 |
>>>> |
13 |
>>>> The "kicker" - simple optimisations gained far, far more than generic |
14 |
>>>> compiler settings. e.g., initially, the gnumeric versions were slightly |
15 |
>>>> different, with some wild times across the tasks. Make em the same |
16 |
>>>> version (and cuedos to the gnumeric maintainer for jumping in and |
17 |
>>>> helping diagnose/fix the problem - newer version on gentoo was heaps |
18 |
>>>> slower :) and there was little difference. |
19 |
>>>> |
20 |
>>>> Shared libs like glibc didnt make a huge difference, but being smart |
21 |
>>>> about how/what a "particular" task was handled gained more. If a debian |
22 |
>>>> app was compiled with similar options as to gentoo, little difference |
23 |
>>>> between them in performance which considering shared libs etc wasn't |
24 |
>>>> what I expected. |
25 |
>>>> |
26 |
>>>> The intel compilers are/were said to be a lot better than gcc, not sure |
27 |
>>>> if the gap is still there (supposedly 20% better again) |
28 |
>>>> |
29 |
>>>> Its how long is a piece of string kind of question if considered OS |
30 |
>>>> wide, but pick a narrow task and optimise away with smart programmers |
31 |
>>>> and you will do well on almost anything. |
32 |
>>>> |
33 |
>>>> Big advantage of gentoo - configurability, version control (what version |
34 |
>>>> is installed and changing it at short notice) and general flexibility. |
35 |
>>>> |
36 |
>>> This. |
37 |
>>> |
38 |
>>> Why I prefer Gentoo over other distros: Full control. |
39 |
>>> |
40 |
>>> I mean, I can (and do) leverage "-march=native". And I certainly have an |
41 |
>>> overly long USE flags... but it's the sheet satisfaction of knowing that |
42 |
>>> my system is MY system that made me stick with Gentoo... |
43 |
>>> |
44 |
>>> It's eminently satisfying -- a geekgasm, if you will -- to know that |
45 |
>>> one's kernel is lean and customized, all the toolchains have been tuned, |
46 |
>>> and there are no useless things being installed... |
47 |
>>> |
48 |
>>> In regards to performance, the benefits might not be groundbreaking, but |
49 |
>>> it's there, and when your server is being relentlessly hammered by |
50 |
>>> requests, Gentoo seems to have additional breathing space where other |
51 |
>>> distros choke... |
52 |
>> |
53 |
>> Gentoo excels as a -dev system where your devs need to test things in |
54 |
>> different environments. |
55 |
>> |
56 |
>> A classic case is different pythons. We have many Centos 4 machines in |
57 |
>> production that run python-2.4, the developers naturally run something |
58 |
>> bleeding edge like 2.7 or 3.3 on their laptops. |
59 |
>> |
60 |
>> Many many times they need to know if their bespoke code runs properly on |
61 |
>> Centos, or PyPy or whatever other valid environment difference could |
62 |
>> happen in the real world. |
63 |
>> |
64 |
>> Tweak USE, tweak the masking and let emerge world do it's thing. Now the |
65 |
>> dev can do valid tests. If the dev machines are VMs, snapshot them just |
66 |
>> before starting this and you have the best possible solution for my money. |
67 |
>> |
68 |
>> Or, try remove LDAP, NIS and PAM support for auth from a RHEL machine to |
69 |
>> test if it works without those things in place. |
70 |
>> RHEL? Impossible. |
71 |
>> Gentoo? Trivially easy. |
72 |
> "Trivially easy", of course, means an emerge -euDNtv world && emerge |
73 |
> -ctv && revdep-rebuild -i && revdep-rebuild ... ehehehe |
74 |
> |
75 |
> I dunno, it might actually be easier to setup the said distros in a VM. |
76 |
> And if those configurations don't work, you shouldn't have to support |
77 |
> them, eh? ;) |
78 |
> |
79 |
|
80 |
|
81 |
Well, devs tend to ask questions like "would this thing X work in |
82 |
practice? or do I have to munge my code?" |
83 |
|
84 |
They want to know if shipped code supports something. And, I don't get |
85 |
to say "I'm sorry, I cannot support Centos 4 on this" |
86 |
|
87 |
Business has a stock answer "Well, find a way to make it work." |
88 |
|
89 |
Flexibility is the key. At least with |
90 |
|
91 |
"emerge -euDNtv world && emerge -ctv && revdep-rebuild -i && revdep-rebuild" |
92 |
|
93 |
I can walk away and come back in three hours, look at logs and tell them |
94 |
to test. Plus I don't have to re-install their customer code everyt time |
95 |
from scratch (said code *never*, of course, coming with anything |
96 |
resembling a MakeFile) |
97 |
|
98 |
|
99 |
|
100 |
-- |
101 |
Alan McKinnon |
102 |
alan.mckinnon@×××××.com |