LINUX.ORG.RU

Увеличить скорость путем пересбора всего из сырцов? Не в этой жизни!


0

0

Доблестные бойцы из gentoo community решили доказать всему мира как это здорово - пересобирать весь софт при инсталляции с максимальной оптимизацией под текущее железо. Они взяли три идентичные машинки и установили на них Debian, Gentoo и Mandrake.

Результат тестов оказался обескураживающим, во всех проведенных ими экспериментах (загрузка большой gnumeric таблички, большие преобразования картинок в гимпе, пересборка ядра) gentoo показал заметно худший результат чем Mandrake (разница в 10% и более). Debian оказался местами быстрее чем MAndrake, а местами медленней.

>>> Подробности

★★★★★

Наглый гон!

anonymous
()

пять баллов! а теперь еще затраты времени посчитать на установку :) А вот вопрос к уважаемым знатокам gentoo - можно ли вмешаться в конфигурение софта перед компиляцией - потому как по дефолту частенько много лишнего включено.

Таппра Та

anonymous
()

А хули Gentoo под П4 компиляли как П3? Да и не все оптимизации задействованы; кроме того, эффект от неизбежной разницы в конфигурациях дистров с лихвой перекроет все эти игры с ключами компилеров.

anonymous
()

А я это уже полгода талдычу.
Грамотно собранный дистр не нуждается в пересборке.
Единственное исключение - на этапе пересборки включить _необходимые_ для работы фичи в том же ядре или программе или обеспечить работу дистра на старом железе.

AVL2 ★★★★★
()

Да в общем всегда было понятно что никакого 2х 3х и 4х кратного
прироста в скорости никакая сборка из сырцов не даёт,
да и не в этом её прелесть ....

ezhikov
()

Да не в скорости дело. Меня например прет компилячить из исходников что нибудь зверское. Чтобы не компилилось еще, чтобы похачить :)) Вот как гном местами.

Banshee
()

Likewise, the stock gentoo-sources kernel includes optimisations for interactive desktop usage but in our (limited) user impressions this benefit did not show through.

> Про -O2 - правда, а вот кернел был именно гентушный, читай внимательней.

Сорьки, и в правду Gentoo-шное, перечитал, кажется :-)

e-lite
()

это было предсказуемо... обычно выигрыш в производительности получается не ключиками компилятора, а эффективностью кода.

flynbit
()

Мда... Ядро было не gentoo-sources т.к. официальные gentoo-sources 2.4.20, а там ясно сказано, что ядро : "The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2 . ". Плюс разные версии компилера.

anonymous
()

Насчёт -O2 -O3 ... личный опыт показывает что
далеко не всегда O3 пашет быстрее чем O2 ровно как и наоборот.

ezhikov
()

гораздо любопытнее было бы сравнить скорость с ядрами suse и redhat...

flynbit
()
Ответ на: комментарий от anonymous

Снимись с ручника, 2.4.21 - это ядро КОТОРОЕ КОМПИЛИРОВАЛИ, а запущено было ядро из поставки.

green ★★★★★
() автор топика

Несерьёзная статья. не исключено, что машина с Gentoo была плохо настроена, более того камни в сторону source-based дистрибутивов вообще, это как-то глупо (slackware, gentoo, freebsd). Возможности настройки у них всё равно самые лучшие :-)

P.S. мандраки всякие это для криворуких админов и прочих быстро-программирующих-интерфейсы-на-кайликсе-для-маленьких-банков-программистов :-)

P.S. Тему для флейма кажись расширил ;)

zenkov ★★★
()

Почему это статья несерьезная? Только потому, что задето самолюбие кого-то из фанов? напрасно... Мне кажется, актуальность данной статьи именно в том, что порой повода для пересборки программ просто нет и получаем огромный выигрыш во времени, пользуясь готовым инструментом. PS. "возможности настройки" ограничены не дистрибутивом а пользователем

flynbit
()

Хммм, но все же...

Gentoo должен был бы показать хорошие показатели (потому-что в Gentoo используются всевозможные параметры оптимизации: GCC флаги, все strip-уется, собирается под систему (при march=blah blah blah), etc), у меня сложилось такое впечатление, что это сами тестеры плохие... :)

Все вышесказанное ИМХО ;)

e-lite
()

А ведь это - показатель уровня "оптимизации", обеспечиваемого GCC! Если уж дистр, целиком скомпилированный под P3, медленней заточенного под 386... ну знаете...

anonymous
()
Ответ на: комментарий от zenkov

>>>камни в сторону source-based дистрибутивов вообще, это как-то глупо (slackware, gentoo, freebsd).

Чего вдруг slackware source-based стал?

geekkoo
()

Использую Gentoo и SuSE 8.2. SuSE субьективно шустрее.

anonymous
()

На самом деле статья ничего не доказывает. Ровно половина объема статьи отведена под фразы типа "это у нас не получилось и мы вручную поменяли это на это". Так может быть результат больше зависит от того кто и как менял?

anonymous
()
Ответ на: комментарий от e-lite

Параметры оптимизации - фигня. Все дело в том что ов обычных дистрибутиводелающих конторах обычно есть люди которые ДУМАЮТ как сделать систему быстрее концептуально. Видимо в gentoo таких людей нет и там надеются на "а вот мы щас как все пересоберем и оно все кааак полетит!" ;)

green ★★★★★
() автор топика

Вот еще что хотел сказать. Не согласны с результатами статьи? Проведите свой эксперимент и опубликуйте результаты.

green ★★★★★
() автор топика


1) Интересно было бы поглядеть на результаты _нормальных_ тестов --
Linpack, FFT, etc.

2) Есть вещи, производительность которых _действительно_ меняется
в разы в зависимости от -march. Примеры: MPICH , xloops, GiNaC.
Но это совсем не повод делать из Вашего дистрибутива LFS :)

Dselect ★★★
()

А вот у меня (B)LFS живет. Все, как положено, собрано из официальных исходников. По скорости с другими дистрибутивами не сравнивал (и так хватает), но зато по другим параметрам LFS идет на 100 очков вперед. 

1) Обновление патчами или через cvs (на dialup хорошо экономит деньги и время)
2) Возможность собрать так, как мне надо (интересно, RedHat все еще не поддерживает active-filter в pppd?), с запрещением всего глючного
3) Возможность самостоятельно исправлять глюки, поддающиеся легкому исправлению (владельцы alsa+fm801+kde 3.1.3 наверняка мечтают об этом)
4) Возможность не дожидаться релиза, чтобы баг, отмеченный в Bugzilla как FIXED, действительно отсутствовал на моей машине
5) Возможность держать одновременно две версии програмы на тот случай, что в новой версии есть и новые фичи и новые баги
6) Возможность делать мелкие изменения в лучшую сторону (добавил кодировку cp866 в список поддерживаемых в kwrite)
7) На домашней машине мало лишнего (нет sendmail и аналогов)
8) Возможность плевать на американские патенты
9) Все параметры во всех файлах конфигурации известны. Не надо производить reverse engineering скриптов инициализации, чтобы понять, как, например, заставить OpenLDAP слушать через ssl (нужно было для отладки своей программы)
10) Не боюсь, что какая-то неизвестная мне автоматика перепортит все настройки, которые я старался прописывал в конфигурационных файлах

Не так давно я скопировал свою инсталляцию приятелю, которому надоели глюки Mandrake 9.1 (дистрибутивы у него дольше 2 дней не жили именно по причине глюков и плохих настроек по умолчанию). Реакция: он доставил LICQ и KOffice и на глюки не жалуется.

anonymous
()

> Параметры оптимизации - фигня. Все дело в том что ов обычных дистрибутиводелающих конторах обычно есть люди которые ДУМАЮТ как сделать систему быстрее концептуально.

Согласен на все 100%

e-lite
()

>Доблестные бойцы из gentoo community решили доказать всему мира как это
>здорово - пересобирать весь софт при инсталляции с максимальной
>оптимизацией под текущее железо. Они взяли три идентичные машинки и
>установили на них Debian, Gentoo и Mandrake.

Во-первых, люди, которые проводили тестирование, насколько я понял,
не имеют непосредственного отношения к Gentoo community и они не
собирались никому ничего доказывать, откуда такие утверждения?!

Во-вторых, тесты проводились в спешке и не очень чисто. Как вам это:
"The Gentoo machine seemed to draw a little slower than the others which
perhaps indicates that the vesa framebuffer is a better choice than the
SIS driver."?

anonymous
()

Дебиановское ядро они из дистрибутива взяли или скомпилировали новое? Почему тогда ничего не сказано про параметры компиляции нового ядра?

anonymous
()
Ответ на: комментарий от anonymous

Как не имеют? gentoo пользуют же ;) Опять же тесты проводятся с целью что-то доказаьт или показать.

Про фреймбуффер - что генту поставило то и было использовано.

Начсчет спешки согласен, однако! спешка наблюдалась в отношении всех трех машинок, так что тут начальные условия - разные.

Жду результатов ваших тестов выполненных не в спешке и, желательно, еще и с тестами относительно шапки 9.

green ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Все взято из дистрибутива, сказано же в самом начале.

green ★★★★★
() автор топика

сказано только что "новое":
As the stock kernel did not contain framebuffer support a new one (v2.4.21) was compiled to get video working.

anonymous
()
Ответ на: комментарий от anonymous

И правда, ну напиши им письмо и спроси.

green ★★★★★
() автор топика

2green:
>Как не имеют? gentoo пользуют же ;) Опять же тесты проводятся с целью
>что-то доказаьт или показать.

Я имею в виду, что нигде в статье не написано, что целью теста было
доказать неоспоримое преимущество Gentoo (и вообще всех source-based)
над другими дистрибутивами. Читаем:
"Scott gets the credit for thinking of this test. He said "We're
constantly hearing how the source based nature of the Gentoo distro
makes better use of your hardware, but no-one seems to have really
tested it. What kind of gains are involved over distros which use binary packaging?""

Замечу, что я не являюсь фанатиком Gentoo (или вообще какого-то
дистрибутива), я использую то, что мне кажется самым удобным на
этот момент. Дома и на работе у меня AltLinux Master (плюс на работе
еще с LFS экспериментировал -- хорошая вещь, кстати :-))

anonymous
()
Ответ на: комментарий от anonymous

Ну как же небыло, там же прямым текстом написано: "Мы постоянно слышым как всякие основанные на сырцах дистрибутивы рулят патамучто blah blha, но почему-то никто их не тестировал" ,ну вот они взяли и протестировали чтоб увидеть как же они рулят... Оказалось что рулят они как-то странно.

green ★★★★★
() автор топика

2green:
Еще раз:

>Доблестные бойцы из gentoo community решили доказать всему мира как
>это здорово - пересобирать весь софт при инсталляции с максимальной
>оптимизацией под текущее железо.

и

>Мы постоянно слышым как всякие основанные на сырцах дистрибутивы рулят
>патамучто blah blha, но почему-то никто их не тестировал

-- это разные вещи...

anonymous
()

для anonymous (*) (2003-08-04 11:48:34.142126)
А вот я злостный спамер, и мне sendmail на локальной машине просто необходим! ;)

anonymous
()

А где реплики про красноглазых?

anonymous
()

DEDIAN - RULEZZZ!!!

anonymous
()

Mandrake рулит, Debian рулит

Gentoo - для детишек, которым некуда больше приложить шаловливые ручонки ...

Murr ★★
()

Возможно, у меня просто кривые руки, но поэкспериментировав с Gentoo вернулся обратно на Слаку именно по причине джентушной неторопливости. Это как же так нужно умудриться составить конфиги пакаджей и их зависимостей...

anonymous
()

пророчествую что слово "слака" было сказано зря ....

ezhikov
()

вот и придурки, орущие везде, что всё надо пересобирать из сорцов, оказались в глубокой жопе!

anonymous
()

Бля ))) Ахтунг Ахтунг Ахтунг Ахтунг Ахтунг ))))))

я раньще тусился на падонковских сайтах теперь ,но потом нашел более лучше )) LOR ))))))

особенно когда одни спорят с другими )) наверное тож думают что в споре раждается истина ) я думаю иначе у кого пистолет лучше и реакиция.... ну это в жизни так ) тут не пристрелишь, а то пару дибилов бы я с радость ёбнул )

Порты, это круто !!! это в первую очередь очень гибко ).... больше я думаю писать нет смысла....

anonymous
()

2Dselect:
Слушай, а с тобой можно поподробнее про MPICH побеседовать?



А сатья - лажа. Где, собственно, список ключиков, которые они использовали?

К тому же, действительно, есть огромная куча примеров, когда код с оптимизацией на i386 работает чуть ли не в 2 раза быстрее, чем тот же код от P/PII/PIII/PIV...

Скажем, конкретный пример - использование MMX/SSE/SSE2 команд. Зачастую тот же код реализовать без использования этих команд получается быстрее.

R00T
()
Ответ на: комментарий от R00T

Список ключиков перечислен в секции с название "install".

green ★★★★★
() автор топика

Как я понял в статье говорится, что в ОДНОМ отдельно взятом случае разные дистрибутивы установленные на одинаковых машинах разными людьми показали разные результаты на странном наборе нерепрезентативных тестов. И gentoo не оказался лидером. Все.

anonymous
()

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

anonymous
()

Мне кажется, что было бы интересно взглянуть на то с какой оптимизацией собраны пакеты в Debian и Mandrake. В деталях, т. е. не только -O, но и -MCPU. Высока вероятность того, что дистрибьюторами предполагается, что используется наиболее распространенный на данный момент процессор, и оптимизация идет под него. А MARCH ставится для обратной совместимости. Интересно было бы также сравнение на обычном пне и может быть на AMD.

Не флейма ради, а чтобы понять - когда пересборка действительно имеет смысл.

Dimai
()

А мне если честно хватает того что gentoo _НЕ_ быстрее всех остальных. Даже это сводит на минимум все приемущества данного дистра.



Dead ★★★★
()

ради этого качать ?

anonymous
()

Да и я, если честно, когда ставил Gentoo думал об оптимизации не в первую очередь. Уж очень мне portage их понравился. Возможно, что это от "неумения готовить" package manager'ы других дистров. Но сейчас я уже подсел.

kwas
()

кто-нибудь прочитал статью внимательно??? а то сразу кучка засранцев нашла ещё один дистр которой можно опоносить! ведь в статье явно сказано, что gentoo работал на STOCK-ядре, то бишь ядре с kernel.org без единого патча!!! блин... тестеры херовы сейчас в любом дистре ядро с патчами/бэкпортами идет, а обычно такие патчи в архиве на добрых пару метров в tar.bz2. Естественно это dramatically сказывается на производительности.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.