Разное быстродействие дистрибутивов?

можно ответить так - в линуксе программы собираются из кусочков для обеспечения разной функциональности этих программ. К примеру для включения поддержки LDAP, которая отнюдь не всем нужна. в дистрибутивах вроде сусе все программы пытаются собрать наиболее универсальными, что бы они подошли всем. А в генту и подобных дистрибутивах ты можешь указать какие компоненты тебе нужны и все программы соберутся только с нужными тебе. ;)

Меньше кода - быстрее работа.

Вдобавок каждый из таких кусочков универсально собранный как уже писал автор работает на пару процентов медленнее собранным чисто под себя. А теперь представь что будет если одновременно задействовать дофига таки "кусочков"? Процентов 30 отставания от другого дистра запросто получится может. P.S. Еще не забывай что многие дистростроители накладывают патчи и на ядро и на софт и на библиотеки...;)

> на пару процентов медленнее

Расстояние между городами нельзя мерить с точностью до сантиметра. Синие писалки еще на клавиатуру прикрутите, 0.5% прироста скорости гарантировано.

>Меньше кода - быстрее работа.

в худшем случае, неиспользуемый код увеличит время загрузки в память. И то, при mmap он скорее всего так и останется лежать на диске. Ну ещё линковщик дольше проработает...А на скорость выполнения неиспользуемый код влиять не может.

geek ладно) меньше кода - меньше глюков ;)

>geek ладно) меньше кода - меньше глюков ;)

Да, но ведь спрашивал я про быстродействие и скорость, а не кол-во глюков... Вот :)

Тупо - разные версии компиляторов (пессимизации весьма часты в новых ветках), разные - библиотек, разные и по разному пропатченные ядра, свои патчи и опции сборки от разработчиков.

Короче говоря, сей клондайк и сравнивать противно. Мозгой не понимай, просто запомни: lfs реактивна, гента просто очень быстра, убунта нормальна, зюзя тормозна - поэтому весь прогрессивный люд сидит на дебиане, редхете и арче.

речь идет о тормозе прежде всего графических оболочек
а программы действительно везде одни и те же и работают одинаково

>а программы действительно везде одни и те же и работают одинаково

а вот и нифига. тот же FF в арче - тихий ужас, хотя в бубунте вполне нормален (заметно по скорости прокрутки)

> зюзя тормозна

щас прибежит Миша и начнет вопить, о том, что его сусю опять оболгали, и что у всех просто руки кривые :)

Ходили подтверждённые слухи, что разница между федоркой (или центосью, или ещё каким бинарным зверем) и гентой на замерах производительности mysql достигала более чем двух раз, и это факт. Сие очень даже согласуется с моим опытом.

И я бы сказал, подытожив: одним из определяющих факторов является карма хозяина системы, а потом или рядом идёт всё остальное.

Был тред с джедаем-оптимизаторов, что усердным трудом при помощи acovea подобрал опции сборки для libz (или gzip), что давали прирост в скорости в четверть или около того.

Так что, для прений тут поле непаханное, а голый "-O2" - отнюдь не предел мечтаний.

Про графику же - там как раз всё наоборот, слишком высоки абстракции и падение в 10% на каждом шаге оборачивается полной задницей в итоге, тогда как общее падение скорости на те же 10% для отдельных либок - не особо и заметно.

Короче, нужно брать и мерять ;)

Самое забавное что после того как я перешел с дебиана на арч я первым делом посмотрел как работает фф и был приятно удивлен ускорением его работы ;) Как сказал Гарик, карма тоже важна.

Кто-то мне говорил что типо Федора много быстрее Зюзи, но самому проверять это было влом.

А ещё разный набор софта и степень увешивания демонами

хм. У меня в бубунте был ужас. Самосборный 3.0pre7 значительно быстрее и памяти меньше жрёт :)

Время на компиляцию Генты нивелирует сэкномленное время от оптимизации. ;)

>вроде, Gentoo такой весь из себя скоростной, а SUSE сплошной тормоз...

Я тут уже кидал тест с тредами, который в Ubuntu на средней машине
отрабатывает за 1.2 - 1.4сек, а в Gentoo - за 40..50 сек. При чём
почему так - непонятно. У кого-то и в Gentoo за те же полторы
секунды, а у кого-то 50 секунд и в FreeBSD, SUSE...

А у кого-то этот тест вообще не проходит, ругаясь, что не может создать (начиная с какого-то числа) новые треды.

А, впрочем, вот повтор:

#!/usr/bin/env python 
# -*- coding: utf-8 -*- 

import threading 
import time 

def proc(n): 
    time.sleep(1) 

for i in xrange(10000): 
    threading.Thread(target=proc, name="t"+str(i), args=[i]).start()

Кто-то может объяснить?

А по сути - уже не раз писал, что когда на сервере, не справляющийся с нагрузкой, заменил RH7.3 на Gentoo-2004 всё просто залетало. На том же железе даже при возросшей впоследствии втрое нагрузкой в лимит производительности так и не упёрся. Сейчас, правда, памяти было добавлено, поскольку там кроме веб-сервера, отдающего до 2млн. хитов в сутки (и до 60млн. MySQL-запросов в сутки), ещё MMORPG-сервер на Яве висит :)

В ЗюЗЕ есть ЙаСТ. ЙаСТ - тормоз. Но удобный. В Debian есть APT и Synaptic/Adept. Они вот не тормоза. Но ЙаСТ универсальнее, так как для настрйоки всей системы в целом служит, а не только для пакетов.

> К примеру для включения поддержки LDAP, которая отнюдь не всем нужна

... в нормальных дистрибутивах используют PAM и NSS, вследствие чего у вас в каждой программе появляется на один джамп больше в середине очень короткого цикла, что экономит 0.01% процессорного времени. И если вы отключите эту функциональность, вы за 300 лет аптайма сможете сэкономить столько процессорного времени, что его вам хватит на перекомпиляцию XDM, GDM, su, sudo и sshd когда эта фича вам понадобится.

> когда на сервере, не справляющийся с нагрузкой, заменил RH7.3 на Gentoo-2004 всё просто залетало

А ты не пробовал сравнить версии:

1) компилятора

2) glibc

3) ядра

4) версии софта

прежде чем заявлять о немеряной производительности самосбора? :-)

> Процентов 30 отставания от другого дистра запросто получится может

НЕ МОЖЕТ. Посмотри в top на типичную загрузку своего компа. Заметный (вне погрешности измерения) плюс можно получить только на очень критичных к процессору (счетных в просторечии) задачах.

Может влиять конфигурация системы - это да.

>А ты не пробовал сравнить версии:

>1) компилятора

А нафига? В RH 7.3 я ничего не компилил, вообще-то :D А если дистроклепатели не смогли сделать лучший выбор - это их проблемы. У меня же тогда был какой-то из 3.4.x, кажется.

>2) glibc

2.4 и там, и там был, ЕМНИП. Если не старше. На 2.5 относительно недавно переполз.

> 3) ядра

2.6 и там, и там.

> 4) версии софта

Одинаковые мажорные версии. Apache 2.0, MySQL 4.0 (на 4.1 перешёл позже), PHP-4.1.

На RH7.3 никогда не было 2.6 ядра, было 2.4. Равно как и glibc 2.4, была glibc-2.2/ Соответственно, не было NPTL, которые ОЧЕНЬ нравятся джаве(порядка 50% по тестам только самого сана) и не только ей. Да и версия gcc там была не из лучших - 2.96. Зайди на страничку http://gcc.gnu.org/gcc-2.96.html :)

Так что, извини конечно, но твоё сравнение мимо кассы абсолютно.

Давно было, не помню уже деталей :)

Однако помню, что на RH7.3 у меня стояла тонна пакетов с FC1 и даже с FC2rc.

Но при этом же помню, что после перехода на Gentoo ничего (на прикладном уровне) переосваивать не пришлось, конфиги почти все оригинальные остались и т.п.

А Явы тогда _вообще_ ещё не было :) MMORPG появилась всего два года назад.

Ай, пробовал я как-то настроить через ЙаСТ систему. Сеть с iptables, кажется, строил. Ой, блиииин. Уж на что iptables замороченный, но ЙаСТ это ваще нечто. Ничерта не понятно - один искусственный интеллект. Нажмите, блин, кнопку, блин, и всё у вас будет зашибись, блин. Осталось только, чтобы система рассказывала пользователю, что именно у него зашибись (откиньтесь на спинку кресла, мы стали более удобны, более красивы, у нас в кедах кнопки не как у всех, а треугольные..), блин.

> Однако помню, что на RH7.3 у меня стояла тонна пакетов с FC1 и даже с FC2rc.

В принципе, сложно что-то говорить, не зная полной картины, но пакеты из FC2rc - это сильно :) Последними версиями федоры сразу после выхода пользоваться не особо можно, только после тонны обновлений, а ты rc на боевой сервер... Сильно.

>но пакеты из FC2rc - это сильно :)

Самое забавное, как система в uname представлялась: "Fedora Core 7.3" :)

Вообще, согласен, конечно, что сравнение не корректное, но иного не было :)

> Последними версиями федоры сразу после выхода пользоваться не особо можно, только после тонны обновлений, а ты rc на боевой сервер... Сильно.

Что делать, нужна была масса пакетов, которых не было в RH7.3, а развязывание завимостей повлекло за собой такое, вот...

А кончилось тем, что я попытался сделать дистапгрейд до FC1. Бескровно обновиться не удалось, а когда встал вопрос переустановки, решил попробовать Gentoo. Ибо измучился с зависимостями пакетов и не первой уже проблемой дистапгрейда :) Так с тех пор всюду Gentoo и использую. Хотя RH использовал начиная с 1997-го года и был его фанатом :D

> А, впрочем, вот повтор:
> 
> #!/usr/bin/env python 
> # -*- coding: utf-8 -*- 
> 
> import threading 
> import time 
> 
> def proc(n): 
>     time.sleep(1) 
> 
> for i in xrange(10000): 
>     threading.Thread(target=proc, name="t"+str(i), args=[i]).start()
> 
> Кто-то может объяснить?

Объясняю:

calculus ~ # time python test.py 

real    2m38.036s
user    0m0.034s
sys     0m0.011s

2 оптерона с 2 ядрами каждый о 2.0 ГГц каждое ядро.
Видимо в питоне кривые треды и галимый менеджмент памяти
(883 метра под сегмент данных - это да), и к тому же
происходит постоянное переключение туда-сюда между
процессорами, что на SMP очень невесело.

...а на NUMA - видать вообще атас.

> Самое забавное, как система в uname представлялась: "Fedora Core 7.3"

блин, вот ламерюга. откуда в uname название дистра??

>Видимо в питоне кривые треды и галимый менеджмент памяти (883 метра под сегмент данных - это да), и к тому же происходит постоянное переключение туда-сюда между процессорами, что на SMP очень невесело

В том-то и дело, что на одинаковой конфигурации в Ubuntu - 1.2сек, в Gentoo - 42сек. И Питон - один и тот же. Более того, даже от версии это не зависит. 42 сек. в Gentoo выходит и в 2.4, и в 2.5

> блин, вот ламерюга. откуда в uname название дистра??

Из /etc/redhat-release

> А нафига? В RH 7.3 я ничего не компилил, вообще-то

> > 2) glibc

> 2.4 и там, и там был, ЕМНИП. Если не старше

Чего-чего?!?!?! glibc-2.2 была в RH 7.3, если не вообще 2.1

> > 3) ядра

> 2.6 и там, и там.

В RH 7.3 ядро 2.4, и прикручивать туда 2.6 было не самым простым и приятным занятием, которое приводило к необходимости апгрейда половины системы.

> Одинаковые мажорные версии. Apache 2.0, MySQL 4.0

В RH7.3 MySQL был версии 3, и апач 1.3

$ rpm -q glibc glibc-2.2.5-42

$ rpm -q apache apache-1.3.27-2

$ rpm -q mysql mysql-3.23.54a-3.73

$ cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla)

В общем ты просто гонишь.

man uname

> помню, что на RH7.3 у меня стояла тонна пакетов с FC1 и даже с FC2rc.

гг. силен. из srpm не дано было собрать, если уж так надо?

По поводу замены ядра: замена ядра с 2.4 на 2.6.2 на RH8 - одно из первых моих действий в линуксе после переезда с виндов - иначе не пахал звук. Заменять пришлось только modutils или что-то в этом духе. Вот замена glibc 2.2->2.4 - это да, жопа. Так и не осилил

>из srpm не дано было собрать, если уж так надо?

Я и собрал потом... Gentoo :D

time python test.py
Traceback (most recent call last):
  File "test.py", line 11, in <module>
    threading.Thread(target=proc, name="t"+str(i), args=[i]).start()
  File "/usr/lib/python2.5/threading.py", line 434, in start
    _start_new_thread(self.__bootstrap, ())
thread.error: can't start new thread

real    0m1.427s
user    0m0.030s
sys     0m0.030s

Arch

Короче, вот, что я обнаружил по поводу медленного создания тредов в python'е:

в Gentoo (во крайней мере) в файле /usr/lib64/python2.4/threading.py в строке 418:

_sleep(0.000001) # 1 usec, to let the thread run (Solaris hack)

Если закомментировать эту фигню - то всё сразу становится быстрым. У меня на ноуте за 5 сек справилось.

Ну опять же, взять хоть мой личный опыт перехода с деба на арч. Никаких лишних демонов не висело что там, что там. Системы были настроены практически идентично(насколько это возможно) и всетаки фф той же версии что и в дебе в арче работает _ГОРАЗДО_ быстрее, уж я то на своем 700 мегагерцном целероне это почувствовал сразу ;) .

Не ври, в Дебиане нет FF ;)

> В том-то и дело, что на одинаковой конфигурации в Ubuntu - 1.2сек, в Gentoo - 42сек. И Питон - один и тот же. Более того, даже от версии это не зависит. 42 сек. в Gentoo выходит и в 2.4, и в 2.5

Есть маза - у меня ядро "сервачное" о 100 Hz, может быть поэтому, разница с десктопным как раз на порядок, плюс - миграции процессов.

Вахъ! Из за того что название изменилось на IceWeasel и картинки поменялись- упала производительность? :)

> Из за того что название изменилось на IceWeasel и картинки поменялись- упала производительность? :)

Ага, мозилловцы сделали хак: если котрольная сумма картинки не совпадает - FF начинает тормозить. =)

> фф той же версии что и в дебе в арче работает _ГОРАЗДО_ быстрее

кстати, да. в слаке тоже фокс работал быстрее чем в дебиане. Причем в дебе тормозит и iceweasel и оригинальный firefox

>Причем в дебе тормозит и iceweasel и оригинальный firefox

причем в дебе iceweasel летает в сравнении с бубунтой

"s/в сравнении с бубунтой/в сравнении с firefox в убунте/" конечно же :)