Сравнение производительности 32- и 64-х разрядных серверных платформ

Я так понял, почитав pdf'ки, что запускался какой-то их фирменный бенчмарк. Результаты любопытные, но боюсь практической пользы от них мало.

Интересно бы было увидить что именно они тестировали (код).

Просто я знаю куски которые оптероны выполняют как и быстрее в 64битном режиме, так и медленнее в 64битном режиме....

Впечателние от теста -- просто график "мол программа xyz работает быстрее в suse linux 10 32 bit"... Или я чего-то не понял?

>сделан вывод о том, что 32-битная версия ОС Suse Linux Enterprise Server 10 более чем на 35% быстрее исполняет некоторые задачи, чем ее 64-битное воплощение.

Это может истолковываться двояко. И как то, что 32-х битные платформы быстрее вообще, и как то, что 64-х битная SuSe построена неудачно.

Бинарные дистрибутивы тут всё решают за тебя :)

имхо суся 64-битная кривая. из-за того и результаты такие. пусть на slamd64 протестят =)

Да, конечно, в новелле сидят идиоты. А какой-то там один студентик - он конечно круче их всех вместе взятых...

И эти идиоты будут что-то говорить не в свою пользу? :))

Результаты бенчмарка _БЕЗ_ исходного кода бенчмарка не значат вообще ничего. Точка.

Пионеры уже давно стоят на улицах с транспарантами "Все на 64 бита !!!!". В общем случае 64 битные программы работают медленнее. А уж 64 бита не интелах это вообще полный лол.

Как может работать медленнее проц с более простой архитектурой, но с такими же возможностями? Только если прога кривая. Например, если в ней повсюду неоправданно используются переменные типа long, которые много умножаются и делятся...

За то можно памяти в 64 впихнуть больше.

На основании тестов в лаборатории Нила Нельсона Small Business Transaction был сделан вывод о том, что 64-битная платформа не дает 2-х кратный прирост производительность относительно 32-битных.

> Бинарные дистрибутивы тут всё решают за тебя :)

Странно, за других не решают, а за тебя - решают. Может, в консерватории что поправить надо? :)

Да, определённо, в данном случае 32-битная версия ОС Suse Linux Enterprise Server 10 несколько быстрее исполняет некоторые задачи, чем ее 64-битное воплощение, но, я полагаю, найдуться и такие задачи, где 64-битное воплощение будет вести себя получше, чем 32-битное.

Странно как-то. После переезда с 2xXeon 3.0 на 2xOpteron 1.8 производительность нашей аппликухи увеличилась в 1.5-2 раза. Ядро собиралось 4 минуты, стало собираться чуть больше 1(имеется ввиду make -jN bzImage разумеется)

Не имеет смысла говорить сколько времени собирается ядро, не приложив .config. Вот  я сделал make allmodconfig с скомпилоил на разных платформах

=======================
allmodconfig
-----------------------
Athlon64 3700+ 1Mb
---
real    30m7.806s
user    26m23.920s
sys     3m11.300s
----------------------
Athlon64x2 3800+ 2x512Kb (частота 2ГГц)
---
real    22m41.157s
user    29m24.180s
sys     4m21.620s
----------------------
Athlon64 3500+ 512Kb 2.2GHz
---
real    36m43.190s
user    29m11.428s
sys     4m44.001s
---------------------
Celeron 1.7GHz
---
real    145m35.194s
user    129m14.073s
sys     12m35.359s
---------------------
2xOpteron242 1600MHz (правда немного под нагрузкой был)
---
real    51m1.706s
user    36m42.754s
sys     6m8.771s

Еще бы коре дуо найти где-нить и посмотреть что там будет.

Собственно говоря: ничего удивительного. Качество кода у GCC даже для 32 бит (x86) оставляет желать лучшего, а для 64 бит оно, мягко говоря, никакое - хорошо что работает вообще. Да и у других компиляторов похвастаться особо нечем на 64 битном поприще. Со временем все проблемы утрясутся, а пока 64 битные приложения будут выигрывать только на специфических задачах. Даже если бы код генерился сопоставимого качества, размер полученного 32х битного кода меньше, а значит он будет быстрей исполняться. Разумеется, я имею ввиду задачи не требующие 64 битных вычислений или же 64 битной адресации 8).

А где бы этот allmodconfig взять? Выложил бы, а? Я бы на Pentium D 3.6 2x2Mb с гигом DDR2-667 потестил.

А какое ядро собиралось?

В общем-то, ничего удивительного абсолютно.

У 64-х битного Linux длина int'а в 2 раза больше. Поэтому ОЗУ используется менее эффективно как по размеру, так и по скорости передачи данных.
Так как совсем не каждая операция использует работу с оперативкой, отставание и получилось не в 2 раза, а только на 1/3.

RTFM!

$ cat test.c
main()
{
printf("int %d\nlong %d\nlong long %d\n",
sizeof(int),sizeof(long),sizeof(long long)
);
}
$ gcc test.c -o test
test.c: In function ‘main’:
test.c:3: warning: incompatible implicit declaration of built-in function ‘printf’
$ uname -a
Linux router 2.6.15-27-amd64-k8 #1 SMP PREEMPT Sat Sep 16 01:57:42 UTC 2006 x86_64 GNU/Linux
$ ./test
int 4
long 8
long long 8

В сорцах ядра make help набери :)

>У 64-х битного Linux длина int'а в 2 раза больше.

Учим матчасть.

#include <stdio.h>

void main()
{
    int a = 123;
    printf("%d\n", sizeof(a));
}

...

$ ./a.out
4

$ uname -a
Linux bal 2.6.17-gentoo-r4 #4 PREEMPT Thu Aug 3 11:59:23 MSD 2006 x86_64 AMD Athlon(tm) 64 Processor 3200+ GNU/Linux

> Не имеет смысла говорить сколько времени собирается ядро, не приложив .config.

В моём случае имеет, т.к. отличались только железозависимые опции. Остальное - одинаково.

Эм?

r00t@r00t:~$ date -d 9999999999
Thu Jun 7 00:00:00 MSK 141010

> Пионеры уже давно стоят на улицах с транспарантами "Все на 64 бита !!!!"

+1. 64 бита это модно, cool и труЪ. Только беспонтово до ужаса. Лет через цать (вспомним сколько времени прошло между появлением первого 32-битного 386 и реализацией более-менее пристойного конвейера) можно будет с реальной пользой юзать, ну а щас пусть пионэры на граблях танцуют.

Сорри.
LONG на 32 занимает 4 байта, на 64 - 8 байт.

У меня (Slamd64 10.2 (непатченная), Pentium D 960, гиг DDR2-667, SATA 10000rpm):

test make -j 5

real 17m26.736s
user 29m6.646s
sys 3m47.741s

Не правы вы, батенька.

64 - да, модно. НО! Как ни крути - это наше будущее... 32 рано или поздно умрут все-таки. Та же M$ не собирается выпускать 32-битные венды после висты... а это уже приговор.
Кроме того, Intel уже вообще сняло с производства все процессоры без поддержки 64-х битности (кроме Core Duo и процов для микроконтроллеров типа 80186 ;-) ).

Тот же Exchange Server новый не собирались делать 32 битным тоже... аналитики одговорили. И то только потому, что парк серверов 32 битных еще слишком большой. Но следующий точно будет только 64 битным.

Под Linux появляется все больше дистров с поддержкой 64-хбитности, софта без поддержки 64-х бит почти и не осталось.

В общем, тенденция имеется. Широта распространения - вопрос времени.
Кстати, вот еще чтобы вы задумались: качал я для 64-х битной ХРени Daemon Tools (ну в Most Wanted играцца). Так вот, там счетчик скачиваний есть - 1.3 миллиона. То есть, в мире одних только владельцев компов с 64-х битной вендой и использующих Daemon Tools как минимум 1.3 миллиона... а сколько всего таких вендов установлено?

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

>test make -j 5

>real 17m26.736s >user 29m6.646s >sys 3m47.741s

Гы, все ж частота многое решает :) 3.6Ghz против двух у меня. На целых 23% быстрее скомпилилось.

ubuntu 64, A64X2 3800(разгон убрал)

real    13m44.080s
user    23m19.823s
sys     3m23.677s

> Та же M$ не собирается выпускать 32-битные венды после висты... а это уже приговор.

Учитывая, что они всю жизнь выпускали _только_ системы под 32 бита, делаю вывод, что это приговор для MicroSoft.

Хех. У меня 2-й операционкой 64-х битная ХРень стоит.

Странно.

Вон там повыше есть тот же самый A64 3800 с таймингами в 1.5 раза больше.

Господа!

Если кто не понимает того, что суся и рх есть не более чем запускалка оракла- это его проблемы. Так вот, оракля x86-64 работает значительно лучше чем x86 в том же пингвиниксе. Проще говоря- основной линуксовый рынок выигрывает от x86-64. А что там на вашем сраном десктопе никому не интересно ;-)

Какой брутальный анонимус... Мда.

>Если кто не понимает того, что суся и рх есть не более чем запускалка оракла- это его проблемы.

Я не понимаю. Помимо Оракула есть еще много софта, хорошего и разного.

>Так вот, оракля x86-64 работает значительно лучше чем x86 в том же пингвиниксе.

Отнесем это утверждение к разряду спорных. Всегда можно придумать такую модель базы данных, при которой данная конкретная СУБД будет неэффективной.

>Проще говоря- основной линуксовый рынок выигрывает от x86-64.

Казве тут кто-нибудь кроме Кардинала и еще кого-то утверждал обратное?

>А что там на вашем сраном десктопе никому не интересно ;-)

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

может скорость i/o разная ?

У тебя какой стоит по дефолту шедулер? У меня Anticipatory.

cfq, убери Anticipatory!

Бугогагага, несчастные Зюзеры уже официально пытаются найти оправдание тормознутости своего поделия :)) А ежели им нежно намекнуть у стенки о приросте производительности как минимум у криптографии - так невнятные отмазки о средних 30-35% проигрыша =)

> Странно.

> Вон там повыше есть тот же самый A64 3800 с таймингами в 1.5 раза больше.

Еще бы не странно. Давно пора привыкнуть к мысли о том, что p-4D сосет, несмотря на мегачастоты. А те полтора раза разницы - списываются на тормозную память недостаточного размера в одноканальном режиме и такой же винт. + поправка в сторону увеличения, если дистр - Зюзя.

> Я не понимаю. Помимо Оракула есть еще много софта, хорошего и разного.

MS SQL сервер? ;)

> Отнесем это утверждение к разряду спорных. Всегда можно придумать такую модель базы данных, при которой данная конкретная СУБД будет неэффективной.

Бгггг, легионы DBA ночами не спят, пытаясь выжать из базы все что можно, а к кого-то все просто - идем в обратную сторону, ставим Зюзю, придумываем напрочь неэффективную структуру самой базы и т.п. ИМХО у себя в конторе за такой саботаж стоит ставить к стенке и убивать ап нее же? :)

s/о приросте/о ~ 4x приросте/

Сейчас попробую собрать с CFQ. Результат запощу.

Сйечас качну 2.6.18, соберу его, потом с ним же соберу модули. Вот и посмотрим.

Не думаю, что SuSe такой уж тормозной дистр. Есть у него недостатки, конечно: создаваемая по дефолту с ACL файловая система и завязки на SELinux (за вкусности надо платить, прежде всего производительностью).

Если это убрать, то отличий от любого другого дистра практически нет (если не считать отличиями SysV и BSD-like init) - софт-то тот же самый.

>p-4D сосет, несмотря на мегачастоты

Очень спорное утверждение.

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

Там еще двухголовый Оптерон был, который проиграл даже Атлону.
Будем надеяться, что у xinix такого нету.

люди, я не понимаю в чём проблема! самый простой способ сравнить производительность проца это старый добрый Ассемблер: берём FASM, пишем следующее:

;для 64-х разрядных процов start: xor rax,rax add rax,0xFFFFFFFFFFFFFFFF ret

;для 32-у разрядных start: xor eax,eax add eax,0xFFFFFFFF ret

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

что до производительности, она же не от разрядности зависит, а от частоты проца, длины конвеера.

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

при этом не стои забывать, что за частую производительность мамой памяти не изменна, - т.е. если 32 разрядный проц, образно, за 1 сек заберёт 32 бита, то за 2-ю сек + время на смещение он заберёт ещё 32 бита. А 64 проц заберёт 64 бита за один раз, но время это будет равно 32+32 но уже без подготовки смещения.

elevator=deadline :

real 12m34.496s
user 21m15.112s
sys 3m7.596s 

>Там еще двухголовый Оптерон был, который проиграл даже Атлону. >Будем надеяться, что у xinix такого нету.

Двухголовый опторон я привел только для примера того, что он сделает это не меньше такого времени, а так это рабочий сервак и там куча файлов по саммбе расшарено, то при нормальном тесте он это сделает быстрее, интересне5е другое, как у тов. xnix'а так быстро компилится на точно таком же проце ? Какой компилятор и какое ядро и сколько -j ? Сейчас еще раз попробую.

Не годится. нужен кусок кода > 10mb, чтобы корректно оценить производительность.

А я Gentoo поставил и даже русский натроил.

UTF-8 называется!