Народ, а где посмотреть тесты 64битных систем Athlon vs Itanium

?

А смысл? Там наверняка выиграет итаниум.

выйграет sparcv9 :-)

гы, вот оно и интересно, где быстрее сработает for i=0; i<1000000; i++ {}

на атлоне или на итаниуме?

а смысл? там наверняка выиграет атлон..

вообще хороший вопрос, ибо все равно денег на itanium нет :)

Макском, а че это за зверь spracv9 кластер какой-то хитро&#8470;опый?

SPARC v9 это вообще-то архитектура, насколько я понимаю. A процессор - например UltraSparcIII 900 MHz. Не думаю что _один_ такой побьет _один_ Intel или AMD, да еще и на типично 'десктопных' задачах. Вот в многопроцессорных конфигурациях на 'серверных' задачах наверняка побьет, например при числе процессоров >= 4. А еще вроде бы IBM Power5 сейчас покруче чем любой SPARC.

Честно говоря, не очень согласен с методикой тестирования. IMHO, там небыли задействованы возможности процессоров даже на 50%.

1. Следовало откомпилировать ядра под каждый процессор. В опциях GCC задействовать опции в стиле "-march=pentium4 -mfpmath=sse -msse2" для пеньков и "-march=athlon-4 -m3dnow" для Атлона (я так понимаю, оптимизация для "athlon-4" - это и есть х86-64?). Закинуть эти опции в /usr/src/linux/Makefile, в /usr/src/linux/arch/i386 (для пеньков), в /usr/src/linux/arch/x86-64 (для Атлонов). Хм... Эти пути применительно к 2.4.х, как под 2.6.х я не знаю.
А вот тесты гонять уже на получившемся ядре... IMHO, тогда бы результат был интереснее и правильней... А так... Судя по всему, все процессоры работали в режиме i686.

2. Аналогичные претензии к тесту насчет скоростной кодировки Ogg... Ну ежели процессоры могли использовать максимум MMX + i686 инструкции, то чему удивляться??? ;-)

3. Тест компиляции ядра у меня вообще вызвал недоумение: системы работают под Linux 2.6.2-rc2 , а ядро собирают для 2.4.22. К тому же, почему было не взять конечный 2.6.2 и уже давно выпущенный 2.4.24???
Про опцию make "-jХ" тоже стоит отметить... Собака вот где зарыта: тот SMP-HOWTO (ну и, наверное, man make), где написано, что Х==($кол-во_процессоров)+1 был написан черт знает когда. И в расчете на многопроцессорные машины класса Pentium, PentiumMMX, Pentium-II, да еще при условии объема ОЗУ (SIMM'ами в случае Pentium и PentiumMMX!!!) менее 128Мб.
В современных же процессорах (да еще с большим объемом быстродействующей оперативки "Corsair TWINX1024-4000PRO
(1GB total memory, PC3200 settings)"), количество тредов в make можно смело ставить более 50. А то и еще больше. Реально же, надо было попробовать позапускать make -jX с различными Х и внимательно последить за загрузкой ОЗУ.

4. Претензии к остальным тестам аналогичные: надо было откомпилировать все под соответствующий процессор, прежде чем делать тесты.

>Самой выгодной покупкой по результатам тестов является процессор AMD Athlon 64 3400+.

по результатам тестов этого в упор не видно. Prescott стоит $300, а Athlon 64 3400+ - $405, при этом Prescott в большинстве тестов всех уделал

кстати под Атлон64 нормальные мамки уже появились?

>1. Следовало откомпилировать ядра под каждый процессор. .....

только не говори, что ты ядра для серваков собираешь с подобными опциями

всмысле со всякими там sse, 3dnow и прочей муйнёй

2Reset (*) (05.02.2004 15:10:11): Скорее, всё-таки, всех уделал Extreme Edition (опять же - только за счет кеша, а не за счет каких-то особенностей архитектуры). А вот 2-е место поделили Prescott и Атлон.

Насчет цены - это да... Стоимость матерей для Athlon 64 почему-то не сообщается. ;-) А для Athlon 64 FX так вообще нужна регистровая память ("This also means that since it's the same memory controller, you will also be required to use registered DDR memory with the Athlon 64 FXs."), которая стоит как говорящий слон...

Так что черт его знает - вполне возможно, что система на Athlon 64 FX получится дороже, чем на Extreme Edition, а система на Athlon 64 - дороже, чем система на Prescott. ;-)

Еще вот что надо добавить: тесты-то все, в общем-то, однозадачные. А потому преимущества HT никак себя продемострировать не могли по определению.

2Reset (*) (05.02.2004 15:14:06): В зависимости от того, для чего сервак предназначен. :-) Если он использует SSH или RAID-5, то почему бы ему не включить SSE? ;-)

> Вот в многопроцессорных конфигурациях на 'серверных' задачах наверняка побьет, например при числе процессоров >= 4.

От силы на 5%. А стоить будет точно в 10 раз дороже.

> RAID-5, то почему бы ему не включить SSE?

Это ты в dmesg прочитал? Ну так знай, что рэйдовый драйвер не станет
использовать SSE даже при доступности его в системе.

Слушайте, ребята, а в каком из тестов поделие от АМД выиграло-то ? Что-то либо глазки у меня болят, либо П4 рвёт Атлошу как ссаный матрас. Это почему А-64 - выгодная покупка-то ?

2anonymous (*) (05.02.2004 15:25:16): man gcc и курить насчет опции
"-mfpmath=sse" до полного истощения. Если курить не хочешь, то подскажу: эта опция задает компилятору, для какого модуля генерировать код при вычислениях c плавающей точкой.
Варианты:
"-mfpmath=387" - для сопроцессора.
"-mfpmath=sse -msse" - для обычного SSE
"-mfpmath=sse -msse2" - для SSE2.
Насколько я понимаю, вариант "-mfpmath=sse -m3dnow" заставит использовать 3DNOW на Атлонах.

Так что захочет RAID использовать SSE или НЕ захочет, использовать он будет именно SSE/SSE2/3DNOW.

2lenin (*) (05.02.2004 15:35:37): Ну как же! В POVRay и в OGG Vorbis выиграл (там чем меньше чиселко, тем лучше - потому как секунды).

> Насколько я понимаю, вариант "-mfpmath=sse -m3dnow" заставит использовать 3DNOW на Атлонах.

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

R00T
глупости говоришь :)
к серверам тебя вообще подпускать нельзя :)

2SVpcom (*) (05.02.2004 15:57:11): А конкретный код можешь продемонстрировать???

Ну ок, в ядре и драйверах нельзя, а что мешает в OGG его использовать?

>Насколько я понимаю, вариант "-mfpmath=sse -m3dnow" заставит использовать 3DNOW на Атлонах.

Неправильно помнишь

info gcc и далее ищешь X86 Build-in Functions

Про автоматическое использование float point уже сказали если сохраняешь контекст FPU/SSE/SSE2 ручками и запрещаешь вытеснение на этом участке кода то можно, иначе нельзя а в общем случае не рекомендуется....

Тест говно.

Афлон64 тестился в 32битном моде на 32битных апликухах (т.е. для i686).

И зачем такой тест делать?


Тестить надо было mysql в нативном моде 64 битном.

гы, вот оно и интересно, где быстрее сработает for i=0; i<1000000; i++ {} На хорошем компайлере этот цикл вообще выполняться не будет...

>Тест говно. Согласен ;)

>Афлон64 тестился в 32битном моде на 32битных апликухах (т.е. для i686). >И зачем такой тест делать?

Дык а как тогда сравнивать ? Код должен быть одинаковым..

На самом деле скорость 32 и 64 кода это вещь в себе

большая часть софта в 32 битх бегает с такой же скоростью как и в 64

в некоторых случаях 32 бита оказывается даже более быстрым (из за большего числа регистров -frename-registers начинает рулит вдвое сильнее) выигрыш 64 можно почувствовать только при некоторых целочисленных вычислениях (кстати криптография к ним относится)

Меня удивило другое - почему они тестили полуоптерон у которого явный боттлнек в районе памяти (в тесте с UT2003 это отлично видно)

уж если сравнивать то EE с FX-ом >Тестить надо было mysql в нативном моде 64 битном.

Угу 848 Оптерон в полной конфигурации с 8xИтаником

Разница была бы раза в 2 минимум в пользу первого ;)

>гы, вот оно и интересно, где быстрее сработает for i=0; i<1000000; i++ {} На хорошем компайлере этот цикл вообще выполняться не будет...

ну gcc так умеет ;)

Сомневаюсь. Зайдите на IBM и посмотрите на е325. Там бенчмаркм есть. 2х2ггц оптерон в кластере 48 штук справляются с 32 штуками 2х1.4 итаниумов. Правда в цене безспорно выигрывают.

>Сомневаюсь. Зайдите на IBM и посмотрите на е325. Там бенчмаркм есть. 2х2ггц оптерон в кластере 48 штук справляются с 32 штуками 2х1.4 итаниумов. Правда в цене безспорно выигрывают.

А более точной ссылки нету ?

BTW: Кластер это все-же немножко не то.

В общем, бреда я начитался в этом треде уже достаточно. Достало...
И ведь не зря предложил привести конкретный код о том, что SSE/SSE2/3DNOW использовать нельзя!!! Не привели... (и правильно, такого кода попросту нет). А онанимусы радостно заорали - как же, Рута в ошибке уличили!!! Угу.

А теперь давайте-ка разберемся: любая операция с FPU является вызовом соответствующей Си-функции. Под словом "любая" подразумевается именно ЛЮБАЯ. То есть - вычисление, сохранение содержимого регистров в стеке, занесение в регистр и т. д.

Теперь вопрос: ЧТО произойдет, если компилятору задать "-mfpmath=sse -msse2"? Ответ: _ЛЮБЫЕ_ обращения к FPU будут соответствующим образом (посредством компилятора GCC) на этапе компиляции переконвертированы в обращения к модулю SSE2. То бишь (грубо говоря) команды занесения в регистры, сохранения регистров и прочее FPU будут переконвертированы в SSE2. "-mfpmath=sse -msse2" не означает, что будет использован специальный набор команд для расчета матриц, но означает, что в качестве FPU будет использоваться SSE2. _НИКАКОГО_ противоречия нет. Более того, могу отметить, что даже двухпроцессорные PIII-1200 с "-mfpmath -msse" работают так же стабильно, как и без оного.

Т.е. если я пишу на С

float a = 3.2 * 4.5;

то у меня вызывается какая-то С-функция? Вот чудеса ;)

>Афлон64 тестился в 32битном моде на 32битных апликухах (т.е. для i686). Дык а как тогда сравнивать ? Код должен быть одинаковым..

большая часть софта в 32 битх бегает с такой же скоростью как и в 64

в некоторых случаях 32 бита оказывается даже более быстрым (из за большего числа регистров -frename-registers начинает рулит вдвое сильнее) выигрыш 64 можно почувствовать только при некоторых целочисленных вычислениях (кстати криптография к ним относится)

sS (*) (05.02.2004 17:47:41)

не могут 32битовые бегать быстрее,заточенных под 64бита. наприме у тебя есть число double оно занимает 64 бита, если апликация 32 битовая то чтобы обработать процесору это число ему надо 2 циклаб а если апликация оптимизированна под 64 бита то процессор решает это число за один цикл. т.е. прибавление скорости в 2 раза. Очень это заметно на 3D графике там очень много больших чисел. А если тест проводился на 32 битовых апликациях то это опять же показывает что Атлон рвет Пенька,

dvl13

Другое дело, что double используется в относительно небольшом количестве кода. Другое дело, что в 64-битном режиме AMD64 программе доступно значительно большее число регистров, что не может не сказаться на улучшении производительности (при соответствующей оптимизации кода компилятором).

2 Eugeny_Balakhonov (*) (05.02.2004 23:09:48):

> float a = 3.2 * 4.5;

В данном случае оптимизирующий компилятор ещё на этапе компиляции заменит этот код на

float a = 14.4;

так что пример не очень удачный. :)

ну 1,2 sparcIII точно интел раздрет как обезьяна банан, а повер 5 дествительно оч хорошый проц судя по тестам на западе

хе 1,5 с 6 мегами кеша двухпроцовый итаниум, 8 гигов памяти если брать по уличной цене в москве обходится примерно от 18 до 19,5 тысяч убитых енотов причем серверный вариант с гнилым видео, blade 2500 c 2х1,2 2гига памяти нормальное видео и пр прибамбасы, в ту же цену ну не много дороже если памяти догнать до 8, так что о ценах еще можно поспорить :))

>>так что пример не очень удачный. :)

Согласен, но я саму идею хотел передать. Пускай так

float a = 3.2;
float b = 1.2;
float c = 6.3;

float d = a * b * c;

>(1GB total memory, PC3200 settings)"), количество тредов в make можно >смело ставить более 50. А то и еще больше. Реально же, надо было >попробовать позапускать make -jX с различными Х и внимательно последить >за загрузкой ОЗУ.

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

кол-во джобов надо ставить так, чтобы процессоры всегда были загружены на 100% и при этом -j надо выбирать как можно меньше обычно это NCPU + 1. При 50 у вас будет жуткий оверхед.

http://www.pc.ibm.com/ww/eserver/opteron/benchmarks/

Я даже соврал 32 ноды оптерона бьют 24 ноды 1.5 итаниума.

ftp://ftp.pc.ibm.com/pub/special/serverperformance/news/newsblurb_e325_spec_h...

Потому что на тот момент не смогли достать соответствующий проц и отправили на ссылку, где тесты лежат.

>Согласен, но я саму идею хотел передать. Пускай так >float a = 3.2; >float b = 1.2; >float c = 6.3; >float d = a * b * c;

Опять промах :) - практически любой компилятор в релизе (при включённом оптимизаторе) сделает float d = 24,192 :)))

Ну-ну, считайте-считайте процентики. Настоящая сила - это HT. АМД отдыхает.

> Опять промах :) - практически любой компилятор в релизе (при
> включённом оптимизаторе) сделает float d = 24,192 :)))

люблю Си:

float a = 3.2;
float b = 1.2;
float c = 6.3;

float d = *(float volatile *)&a * *(float volatile *)&b * *(float volatile *)&c;

какие исходники XFree86 правильные?

Народ :)) А вот вопрос: Почему вас вообще е*... волнует эта тема? AMD vs. Intel?

Эир не глас вопиющего в пустыне это попытка составить статистику, после того как увидел 250 листов простыней по этой теме на конфе на www.ixbt.com :)) Но там регистрация сложная... можно начать отсюда.

Итак соц. опрос: Почему вас беспокоит тема AMD vs. Intel?

мой ответ: 1. Из спортивного интереса.

2. Не люблю когда хорошее ругают.

>Ну-ну, считайте-считайте процентики. Настоящая сила - это HT. АМД отдыхает.

HT это костыль для загрузки длинного интелёвого конвеера

Рулит NUMA/SMP и 8-way процы на соответствующем железе (которого ждем-с)

На сколько я помню то нам собственные конвееры для каждого виртульного процессора. Я воспринимаю HT как маленький шаг к 2-х ядровым процам. Потихоньку кол-во общий блоков будут сокращать, и в итоге мы получим два отдельных ядра на одном кристале.

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

Дык данные то к процу идут через одну шину это только внутри их как бы 2

Уже получили 4 - G5.

>Итак соц. опрос: Почему вас беспокоит тема AMD vs. Intel?

не люблю доминирования на века пусть уж АМД будет постоянно наступать интелу на любимые мозоли если в пару с АМД кто-то другой то это вообще бьютифул