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

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

$ 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
$ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ядро из убунту дефолтное, -j8

память двухканальная.

$ cat /proc/cpuinfo |grep MH
cpu MHz         : 2009.188
cpu MHz         : 2009.188

"кусок кода > 10mb"

ради Бога:

mov rbx,0xFFFFFFFF\ start:\ xor rax,rax\ add rax,0xFFFFFFFFFFFFFFFF\

dec rbx\ cmp rbx,0\ jb start\ ret

и никаких издержек на обращения к подсистемам типа винта

этот кусок _полностью_ умещается в кэше L1 любого проца. Наиболее быстро выполнит этот тест тот процессор, у которого больше частота.Более того, скорость выполнения этого кода очень сильно зависит от выравнивания его в памяти.

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

Кстати, пробовал перекодировать DVD одним и двумя процессами (просто 2 раза один и тот же фильм перекодируется) - так время перекодирования во втором случае было больше на пару процентов всего, а может и меньше не помню уже.

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

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

и в коде у Вас ошибка. jne start правильно

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

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

Единственное исключение - оптимизированный непосредственно под p4 код + поточные и flops-зависимые (SSE2) алгоритмы. Тут п4 за счет частоты вырывается, да. Но на general purpose задачах (офисы, компиляции, игрушки etc) - п4 пролетает со свистом, сливая атлонам 1.5х меньшей частоты. Т.е. рейтинг АМД именно это и показывает.

По очкам (внешние интерфейсы проца + двухканальная память с крайне низкими задержками + тепловыделение) - п4 сосет 100%, ничего личного и необъективного, это на самом деле так.

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

Оптероны чуток медленнее, хотя бы за счет ecc+reg памяти в чистом счете, но там не это ценится, а 3х гипертранспорт (до фигища высокоскоростной периферии) и надежность.

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

Поверь, даже 32-битная Зюзя после Федоры оставляет ощущение неслабой тормознутости, а когда я пустил 64-битную после LFS-like - это как паравоз и поезд на магнитной подвеске.

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

"Софт" по большому счету роли не играет, есть политика оптимизаций, версии компиляторов (почитай про регрессии в gcc 4.0 и 4.1) и т.п. Также имеет значение соотношение 64-битного native кода и 32-битного legacy, в Зюзе оно весьма таки мало, фактически можно говорить что там 64битные только ядро, основные либки, простые проги и т.п. Весь тяжелый софт - поголовно 32битный (в ОпенЗюзе 10.1).

По старой доброй традиции измерять производительность системы
компиляцией ядра, берём linux-2.6.18 и
$ make ARCH=i386 allmodconfig
$ time make -j6 ARCH=i386
на системе с Pentium D 820 и 1 GB DDR2-533:

Gentoo amd64/2006.1:
real    29m7.229s
user    46m46.503s
sys     5m36.354s

Fedora Core 5 i386 (в chroot'е под 64-битным ядром):
real    32m14.497s
user    54m55.356s
sys     4m8.674s

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

Класс. Ядро 2.6.18 SMP PREEMPT 1000Hz CFQ. Собирается 2.6.18:

real 20m40.039s
user 32m6.313s
sys 4m25.926s

Ща на deadline попробую.

Я с -j 8 собирал.

неа, вроде, основных регистров как было четыре так их и осталось четыре: A, B, C, D просто они удлиннились в 2 раза, как в прочем и служебные, преобрели подобающий вид, это не влияет на производительность процессора, это влияет только на адресацию и на способность оперировать 64 разрядными числами!

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

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

а заголовок у нас про тестирование 64 и 32 разрядных процов..., а слова серверный и десктопный здесь непричём, регистры как были ax,bx,cx, etc так и остались, и сомневаюсь, что их кто-нибуть отменит!

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

Ета ты канечна ананимус атжок так атжок l=)

>1000Hz

сбавь до 250.

>неа, вроде, основных регистров как было четыре так их и осталось четыре: A, B, C, D просто они удлиннились в 2 раза, как в прочем и служебные, преобрели подобающий вид, это не влияет на производительность процессора

Ну на марш учить матчасть.

> неа, вроде, основных регистров как было четыре так их и осталось четыре: A, B, C, D просто они удлиннились в 2 раза, как в прочем и служебные, преобрели подобающий вид, это не влияет на производительность процессора, это влияет только на адресацию и на способность оперировать 64 разрядными числами!

Сынок, ты бы хоть вместо Плейбоя мануал по i386 и x86_64 архитектурам почитал, чтобы не позориться ;) А потом усвоил какие бенефиты получает от 2х регистров (16 штук) 2х длины (64 бит), к примеру, матан с очень длинными целями числами ;)

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

Гы-гы, у Коре-Дуо конвейер как раз укорочен, а АМД всегда отличалась пониженной частотой =)

> а заголовок у нас про тестирование 64 и 32 разрядных процов..., а слова серверный и десктопный здесь непричём, регистры как были ax,bx,cx, etc так и остались, и сомневаюсь, что их кто-нибуть отменит!

Нереальный чел, я чуть не помер со смеху :)

> неа, вроде, основных регистров как было четыре так их и осталось четыре: A, B, C, D просто они удлиннились в 2 раза, как в прочем и служебные, преобрели подобающий вид, это не влияет на производительность процессора, это влияет только на адресацию и на способность оперировать 64 разрядными числами!

Бред, RTFM! В 32-битном режиме регистров 8, из них все за исключением ESP могут использоваться как регистры общего назначения (без ключа -fomit-frame-pointer или последних версий gcc, еще выпадает и EBP). В 64-битном режиме регистров уже 16, за минусом укалателя стека, использовать можно 15 из них.

> неа, вроде, основных регистров как было четыре так их и осталось

Да... Учить матчасть!!! AMD в наследство от IA32 досталось восемь регистров, количество которых они и увеличили в своем AMD64 до ШЕСТНАДЦАТИ. Ну и, логичный шаг, еще и в два раза увеличили количество FPU регистров.

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

Глупости. Более или менее догнать AMD64 у Интела получилось в Core только благодаря откату на прошлое ядро (и сделав его на треть более широким, да добавив кеша выше крыши, что стало возможным только после перехода на более тонкий техпроцесс), которое вообще-то начиналось еще с Pentium Pro. И конвеер там _короче_, чем в Netburst (P4). Да и особых _революционных_ изменений никаких нет.

> AMD - же брало только частотой

Это ты попутал, P4 брал частотой, а AMD64 давал _большую_ производительность при _меньшей_ частоте.

> хотя 64-поддержка уних была раньше доступна простому обывателю

Ты учитываешь, что эту "64-поддержка уних" придумала AMD, и сейчас именно процессоры Интел вынуждены быть совместимыми с AMD? EM64T -- это реализация в Интел расширения AMD64.

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

Назовите этот софт, ради которого покупают RH AS.

>научитесь себя прилично вести в уважаемом обществе.

в уважаемом я веду себя прилично ;-)

>раз уж вам не важно что у меня на десктопе стоит, что же вы на это внимание свое обратили?

потому что тут именно про это рассуждать взялись, утверждая что от 64 бит никакой пользы нет.

2.6.18 SMP PREEMPT 250Hz Deadline "make -j 8":

real 20m52.129s
user 32m2.676s
sys 4m24.257s

Мда... CFQ предпочтительнее.
Но 2.6.18 реально дольше чем 2.6.17 собирается (отчасти - минуты 3 тратится - из-за function reordering в дефолте при линковке ядра).

xnix, можешь у себя из 2.6.18 пособирать его же?

P. S. у меня gcc 3.4.4
P. P. S. сейчас попробую CFQ, 250Hz и nice -n -20... ;-)

>Назовите этот софт, ради которого покупают RH AS.

так торопился, что не дописал ;-) - и SLES

Где _Я_ писал, что от 64 бит никакой пользы нет???
Ладно, не int, а long в 2 раза больше на х86_64. И, соответственно, в 2 раза увеличивается нагрузка на память и шину при оперировании данными типа long.

Но вот ГДЕ вы прочли мое утверждение, что "никакой пользы нет" - ума не приложу. Более того, я этого никогда и не утверждал. :-) Уже больше полугода использую Slamd64 и x64 XP на работе и дома и особых претензий как-то не имею.

>Где _Я_ писал, что от 64 бит никакой пользы нет???

Вы больной человек, Вам лечиться надо. :-( Я нигде не писал, что Вы это писали.

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

>anonymous (*) (24.09.2006 18:59:25)


:-) К счастью, до "белки" мне еще далеко.

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

Милай, это уже со времён Pentium-1 не так. Точнее - не только так. А сейчас на дворе, вообще, уже XXI век.

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

> Ты учитываешь, что эту "64-поддержка уних" придумала AMD, и сейчас именно процессоры Интел вынуждены быть совместимыми с AMD? EM64T -- это реализация в Интел расширения AMD64.

Причем помнится, на Интел наехала известная компания Microsoft, заявив, что она не будет делать две ОС для двух архитектур, и если Intel не желает остаться без ОС, то лучше б ей поддерживать те же инструкции. AMD не сопротивлялась.

> Причем помнится, на Интел наехала известная компания Microsoft, заявив, что она не будет делать две ОС для двух архитектур, и если Intel не желает остаться без ОС, то лучше б ей поддерживать те же инструкции. AMD не сопротивлялась.

У AMD камень _уже_ был, и работал, и продавался, и софт под него уже появлялся. Интел пришлось вскакивать на ходу, чтобы не отстать от поезда. Короче, кто первый встал, того и тапки.

2.6.18 SMP PREEMPT 250Hz CFQ "time nice -n -20 make -j 8":

real 20m44.773s
user 31m48.835s
sys 4m20.644s

xinx, ну как у тебя так быстро компилится ??? Поставил gcc-4.1.1, -j8 частота таймера 100Hz, шедулер Anticipatory,память двухканальная PC3200, правда так миррор софтварный, но не думаю что это сильно влияет, ну и сервак чуток совсем подгружен, ну будет 20минут, если все раздражающие факторы убрать, но до 13 то как догнать ? Мож ты неправильно как-то компилишь ? У меня ж на одноядерном 2400MHz 36 минут было, ну в 3 раза то он не должен ускориться (знаю про то что иногда при распараллеливании программы на N процов скорость увеличивается больше чем в N раз из-за кеша)

2.6.18 - немного дольше собирается

real 23m43.459s

user 36m3.540s

sys 4m39.340s

>-j8

У тя 7 ядер ;) ?

hint: Должно быть make -j n+1 где n - число ядер/потоков HT

> Короче, кто первый встал, того и тапки.

А как же титаник? Выходит жадность фраера сгубила?

может потому что 2.6.15 ?

щас скачаю 2.6.18

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

Не может быть такого. 2xOpteron 265(1.8Ghz) быстрее на глаз(да и по make -jN bzImage) Athlon X2 4600+(2.2 Ghz) AM2

А ты make clean между сборками не забываешь делать ? ;)

make mrproper
make allmodconfig
time make  -j8

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

Ой, да бросьте, лажа это всё. В 80% случаев заявления M$ - это ложь. Уж сколько раз в этом убеждались, а всё равно верите в эти сказочки. Вспомните, сколько времени M$ переползала с 16bit на 32bit? А сколько было вранья про 32-битность той же Win95? Тут то же самое будет, вот увидите.

Знаю я. Более того, "n+1" - величина чисто субъективная, разумная лишь для Pentium-II с 64 метрами. Затык может быть на время сбрасывания бинарников на винт... типа посчитает все потоки быстрее, чем результат записывать (и новую дату считывать) будет - поэтому лучше ставить побольше, чем n+1.

> Милай, это уже со времён Pentium-1 не так. Точнее - не только так. А сейчас на дворе, вообще, уже XXI век.

По-моему максимум 14-15 можно дать ;)

> Производительность приложений в наше время зависит даже от того, в каком состоянии был процессор на момент их запуска :)

То есть ежели проц обсчитывает свисту - то приложениям ресурсами первого ядра воспользоваться не удастся гарантированно, а второго - только если повезет? :)

> hint: Должно быть make -j n+1 где n - число ядер/потоков HT

Hint на то и hint, что надо ещё подумать, прежде чем его использовать. С -j3 make при сборке ядра ничего не параллелит. Параллелить начинает только с -j5.

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

И как она, стабильна? Всё ль работает? Какой софт есть? А то в нашем форуме многие эти вопросы задают, но счастливые обладатели этого чуда почему-то предпочитают отмалчиваться.

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

Оракел - это единственная программа, которую смог осилить анонимус?

> xinx, ну как у тебя так быстро компилится ??? Поставил gcc-4.1.1, -j8 частота таймера 100Hz, шедулер Anticipatory,память двухканальная PC3200

Из-за gcc-4.1.1 тормоза, очевидно. Настоящие джедаи сидят на 3.4.6, а не сие полутестовом регрессировавшем чудище.

Шедулер - cfq, для памяти засадить T1 command rate, разгон убрать, дисковая - отдельный винт на своем канале или raid1, таймер понятное дело 100, нафиг дестопными извращениями заниматься.

Еще крайне спорен параметр -j, ИМХО для гладкости нужно давать 2x/3x/4x на каждое физическое ядро, а извращения типа гипертридинга - вырубать, либо не учитывать (т.е. для p4-d + ht = -j4/-j8).

> У тя 7 ядер ;) ?

Cell, 8 ядер, одно запасное для XMMS, главное - всем рулит =)

> hint: Должно быть make -j n+1 где n - число ядер/потоков HT

Древний бойан, все зависит от ПСП от памяти и винта, проц и без того все посчитать успеет.

>И как она, стабильна?

Не более (да и, пожалуй, не менее) нестабильна, чем обычная ХРень.
К сожалению, пропатчить ее нет возможности. Работает с SP1 (это то же самое, что SP2 для 32-х битной версии).

>Всё ль работает

Не работают дрова от 32-х бит. Дрова обязательно должны быть 64-х битными. Соответственно, не будет работать железо под которое нет 64-х битных дров.
Качаные дрова для SB Live!, NVidia, Intel, руля Logitech MOMO Racing работают без претензий.

>Какой софт есть?

Office 2k3, Nero, WinDVD, Far, WinRAR, Daemon Tools. Игрушечки Underground 2, MostWanted. Все 32-х битные, ессно. Работают, не возмущаются.

>Не может быть такого. 2xOpteron 265(1.8Ghz) быстрее на глаз(да и по make -jN bzImage) Athlon X2 4600+(2.2 Ghz) AM2

У меня Opteron 242 были, да и по самбе файло качалось немного, винт с системой там вообще древний какой-то, говорю же привел долько для того, чтобы показать, что он не медленнее сделает.

> Hint на то и hint, что надо ещё подумать, прежде чем его использовать. >С -j3 make при сборке ядра ничего не параллелит. Параллелить начинает >только с -j5.

у меня и при -j 2 параллелит, собственно в исходном тесте так оно и стояло

> Из-за gcc-4.1.1 тормоза, очевидно. Настоящие джедаи сидят на 3.4.6, а не сие полутестовом регрессировавшем чудище.

Опять же вначале был gcc-3.4.5 вроде, решил немного подогнать под параметры xinx'а. Но скорее всего это из-за того что ядро 2.6.15 у него, у меня то вначале 2.6.17.8 было, потом 2.6.18 ванильные

>для p4-d + ht = -j4/-j8).

Муйяк. _НЕТ_ на Pentium D гипертридинга. И никогда небыло.
Гипертридинг закончился на Prescott'ах, а Pentium D - это Prestler.

> MS SQL сервер? ;)

А что, кроме серверов баз данных, в вашем населённом пункте других не бывает?

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

А ты не думай, ты попробуй. Потом сообщи нам, что получилось. У них же патчей своих к ядру докуа. С собранным в нём же, его же gcc, generic-ядром оно вообще не стартует.

Я пробовал, ты мне поверь. :-) Плююсь до сих пор, хотя тот сервак уже 10 месяцев как переформатировали. :-)

Основные патчи - на FS. Именно из-за патчей на FS (тот же ACL) и не стартует с generic ядром.

> _НЕТ_ на Pentium D гипертридинга.

Учи матчасть... На экстримах есть. Только вот понта от этого HT нет, но это другой разговор.