Сравнение производительности 32-битной и 64-битной версий дистрибутивов Fedora 9, OpenSUSE 11.0, Ubuntu 8.04.1

На 1 гб памяти ? Автор шутник однако

>На 1 гб памяти ? Автор шутник однако Нормально!!!

а самое главно, видео не кодировал...

Использую X_86-64 еще с версии Opensuse 10.1.

измерЕны. измерЕния.

Чето как-то подозрительно быстро ядро компилирутся... А вообще тест - говно.

Редкостные дебилы делали тест - "изменений не вносилось". Поставили все полность. Fedora, полигон серверного дистрибутива, имеет больше включенных сервисов. И ее решили сравнить с Ubuntu. (В Suse не силен.)

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

И нужно было тестить уже переделанные под 64 бита проги.

P.S. А федора на ext4 стояла или нет?

Я фигею. А скриншоты-то на фига?

А так, в целом, ничего обзор.

тест ничего нового мне не открыл. а вот что интерестно узнать - производительность нагруженного web сервера под i386 и под x64

последние 2 таблички имеют неправильные имена дистров в столбцах. в заголовке Сюся, в таблице Федора, потом опять Убунта а в таблице Федора

>Раз уж проги консольные, дык и тестили бы в консоли.

Это да, кстати.

>И нужно было тестить уже переделанные под 64 бита проги.

Это в смысле? А что тестировалось?

Сюда бы ещё до кучи любой source based дистр, собранный под железо на котором тестили. Просто интересно насколько убунта слила бы ему.

p.s: жду ебилдов... ;)

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

и они со страшной силой "едят" процессорное время? :))))

> Раз уж проги консольные, дык и тестили бы в консоли

вот уж не знал, что от этого скорость работы консольных программ меняется

> И нужно было тестить уже переделанные под 64 бита проги

99.999 прог пишут не "под 64 бит", а не выделываясь - на обычных С/C++ и т.п., и это правильно - оптимизацией под железо ( за редкими случаями - где действительно есть смысл ) занимается компилятор

make allnoconfig ?

>Чето как-то подозрительно быстро ядро компилирутся... А вообще тест - говно.

При компиляции ядра нужно как минимум -j2 ставить и на tmpfs это делать, иначе проц всё равно недогружен - всё в I/O упирается.

Кодирование видео (особенно - x264) - автор неасилил.

Выво - автор, мягко говоря, ньюб

Пользователи мандривы смеются над вами.

тесты пережатия видео где? какая нафиг разница за сколько _секунд_ пережимается аудио?

А вообще результаты шокировали, никак не ожидал. ну 1-2% разницу максимум, но Такую! о_о

>Пользователи мандривы смеются над вами.

Они вообще всегда смеются. Жалко их конечно, но это уже не лечится.

И как всегда Ubuntu всех сделала. Так держать №1 !!!

И как всегда доказано, что Бубунта и Федорено горе - это тормознутое дерьмо!

>И как всегда доказано, что Бубунта и Федорено горе - это тормознутое дерьмо!

...но им ещё далеко по этому показателю до ЛОРовских анонимусов!

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

>На 1 гб памяти ? Автор шутник однако

Ъ интырпрайз? даже 512 хватает на подавляющее большинство нужд. И даже на огромную кучу вендовых игр. Что за погоня такая за V?

>А вообще результаты шокировали, никак не ожидал. ну 1-2% разницу максимум, но Такую! о_о

Больше регистров, можно лишний раз не кидать результаты промежуточных расчетов в память или стек. Из этого во многом и получается преимущество в приложениях, которым не нужна работа с 64 битными числами. Я как раз удивился тому, что в некоторых случаях совсем небольшой прирост...

>А вообще результаты шокировали, никак не ожидал. ну 1-2% разницу максимум, но Такую! о_о

Я тоже не ожидал о_о. By the way, что там с потреблением памяти? =)

>даже 512 хватает на подавляющее большинство нужд.

Тогда и 32 бит хватает для "подавляющее большинство..." ТВОИХ "...нужд" и резултаты сравнения ТЕБЯ вобще никак не должны волновать.

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

32-битное ядро было без PAE? 4Г памяти на приличном десктопе - это уже норма, значит при 32 битах придётся включать PAE - вот тогда и посмотреть на скорость x86 vs. x86_64, особенно на приложениях, которые память "любят":)

Обзор делали неучи, не имеющие никакого понятия о том, как проводить измерения.

Одно то, что они видя, что в двух дистрах из трех в тесте сжатия флак разница - от 0.6% до -6%, не выбросили из рассмотрения явно ошибочную дельту в 45%, которую показал третий дистр, говорит само за себя. Но они пометили как "ошибочный" результат в -6%, хотя отклонение в этом случае в 8 раз меньше!

Последний абзац с "усреднением" результатов тянет на твердый кол даже в техникуме, не то что в институте.

На этом фоне сам факт того, что сравнивался скорее результат сравнения производительности сборки для i386 и i686, чем i686 и x86_64 - уже мелочи.

Короче позор авторам, что так затупили и позор модерам, что пропустили такое на лор...

>что там с потреблением памяти?

Уже сто раз "обсосали": +5-15% на x86_64 (это если 32 бита без PAE, иначе PAE отхавает неслабый кусок памяти под свои нужды, так что на x86_64 потребление памяти даже меньше будет).

Ясно, а чо это многозвездночники такие злые сегодня? :))

> Больше регистров,

Больше сами регистры. Вот и получаем хорошую оптимизацию для кодирования аудио, где активно плавающая запятая используется. При компиляции ядра какой выигрыш получили?

>а чо это многозвездночники такие злые сегодня? :))

Если это про меня, то ты сам виноват: если тебе 512М "достаточно", то как ты можешь вообще судить о 32 vs. 64?:)

До 768М x86 в 99% предпочтительнее, до 2Г - сильно от задач зависит, но для большинства не-числодробильных машин скорее 32 бит предпочтительнее, до ~3,5 - 50/50, выше - нужны уже слишком веские основания, чтобы использовать x86, а не x86_64

> Они вообще всегда смеются.

Но над вами не всегда.

>> Больше регистров,

>Больше сами регистры.

И регистров ТОЖЕ в два раза больше (в том числе и SSE-регистров).

Т.е. "В два раза больше в два раза больших регистров"

Ыы ,на нотыке Acer Aspire 9305 T60 2 Gib Ram Debian Lenny Amd64
рвет как тузик тряпку эту святую троицу дистров и без тестов всяких хитрых.

>> Больше регистров,

>Больше сами регистры. Вот и получаем хорошую оптимизацию для кодирования аудио, где активно плавающая запятая используется. При компиляции ядра какой выигрыш получили?

В amd64 увеличена ширина только целочисленных регистров. И давно целочисленные регистры используются для вычислений с плавающей запятой? Размер XMM регистров не изменился, только удвоилось их количество (как и целочисленных).

Слаквари нехватает для сравнения, она бы им показала...

> рвет как тузик тряпку эту святую троицу дистров и без тестов всяких хитрых.

Ну дык.

А вообще статья полезная. Теперь я знаю, что федора тоже тормозное поделие, хотя ни разу её не ставил.

>32-битное ядро было без PAE? 4Г памяти на приличном десктопе - это уже норма, значит при 32 битах придётся включать PAE - вот тогда и посмотреть на скорость x86 vs. x86_64, особенно на приложениях, которые память "любят":)

Да причем тут память? Изменения в x86_64 не ограничиваются только 64 битными регистрами, операциями над ними и 64 битной адресацией. Этих самых регистров стало в два раза больше. Я тестировал одну свою программку, у нее был прирост в районе 20%, просто от того, что она была собрана под x86_64, естественно gcc. И примерно такой же результат наблюдал на другом софте. А на счет PAE, не думаю, что от него будет серьезная просадка производительности.

>А на счет PAE, не думаю, что от него будет серьезная просадка производительности.

Подумай. Иногда это полезно.

А где Слака? Плак-плак. Во имя Патрега - будьте вы прокляты!

Из статьи: time make && make modules_install Вообще-то в данном варианте тайм будет считать только мейк, а мейк модулес_инсталл пройдёт просто.

> В качестве тестов выступали скорости загрузки системы, кодирование звука и другое. Приведены конкретные цифры производительности вышеприведенных систем.

Очередной раз сравнили теплое с мягким

p.s. хоть бы графики iostat / vmstat что ли осилили нарисовать, узнали бы, на что больше перформанса тратится при разных архитектурах в процессе исполнения говнозадач

p.p.s. вот сортировка пары террабайт данных была бы более интересным тестом ;)))

Весь "обзор" - голимый бред.

1. Кодировать/сжимать надо со сбросом не на диск, а в /dev/null

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

3. Сравнивать "время загрузки" - вообще клиника

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

хы 64 жжот. cудя по сервакам - (RHEL, Debian), прОцентов эдак на ~80%. FPU(Fedota: PCB разводить, cчитать Blender-ом или RenderMan-ом или PovRayNet или банально транскодить в хы264 mencoder-ом) - минимум на ~50%) лайв экспириэнс. с легаси софтом - не всегда все хорошо, но то лишь с проприетарным, который "низя пересобрать". что вообще - не для всех(спектрограф шел с гавно-либой(статической, к счастью))

Какой смысл сравнивать разные дистры при указанных условиях? Интересно именно варианты 32/64 посмотреть, да и то результаты не везде дают повод им верить

Это не тест, а просто феерическая бредятина.

Статью осуждаю.

Мда... Отсутствие знания методики проведения экспериментов, это плохо.