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

Нет. Pentium D EE отличается от Pentium D 960 только на 133МГц более высокой частотой проца, на 200МГц более высокой частотой шины и в 3 раза более высокой ценой. Все остальные фичи абсолютно одинаковые.
В Prestler гипертридинг просто не предусмотрен.

Ты с Pentium 4 EE перепутал. :-)

Хотя сорри... действительно есть...

http://www.intel.com/products/processor_number/chart/pentiumxe.htm

Странно... где-то на intel.com я видел сводную таблицу по всем Pentium D, влючая EE. Везде крестик был на HT.

2.6.18

real    21m14.192s
user    32m37.356s
sys     4m32.699s

Во! Больше похоже на правду. :-)

Pentium D рулит. :-)

во, вот это другое дело, а то я уж испугался :)

у мну на 64 битах быстрее. gcc 4.1.1 лучше генрит 64 битный код но доьше та как там сильно услажнён валидатор(и хорошо). Вобщем что то работает быстрее а что то медленнее... вычесления идут быстрее но работа с памятью явно малец по меньше. Но в челом от 64 бит тока выигрываешь особенно если юзать самые свежие проги(юзать gentoo надо).

pentium D собирает ядро на пару процентов быстрее, имя частоту в 1.8 раз больше. Ничего рульного тут нет.

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

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

тссс, если он узнает, что есть другие - его сервер этого не перенесет.

к тому же у тебя SATA 10000rpm,а у меня 7500.

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

Реальные ребята даже /etc хранят в кластерной скуль-базе ;)

Да какая разница, какая частота? :-) Главное, что быстрее.

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

Я это вот к чему: частота не показатель.

Я тоже думаю, что сборка ядра - это на 99% дисковые операции ввода-вывода: большое количество относительно маленьких файлов, которые считывать дольше, чем компилировать.
Время, собственно, компиляции минимально.

Достаточно долго компилируются исходники, которые на C++ написаны. Тот же KDE или libIce.

> Я тоже думаю, что сборка ядра - это на 99% дисковые операции вода-вывода: большое количество относительно маленьких файлов, которые считывать дольше, чем компилировать. Время, собственно, компиляции минимально.

> Достаточно долго компилируются исходники, которые на C++ написаны. Тот же KDE или libIce.

Опять вынужден с вами не согласиться. ;) Наблюдения за системой во время компиляции показывают, что при сборке ядра практически вся нагрузка приходится на процессор, причём user time. А вот KDE при сборке использует fucking libtool, из-за чего почти всё время уходит на выполнение шелловских скриптов и нагрузка на процессор далеко не 100% и в бОльшей степени - system time. Мораль всего вышесказанного: сборка ядра (даже без распараллеливания) нагружает главным образом именно процессор.

P.S. Приплюснутые исходники действительно долго собираются и хорошо грузят проц, но не в случае с KDE - там "побеждает" тормознутость libtool'а.

> Да какая разница, какая частота? :-) Главное, что быстрее.

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

> Кстати, на мембране (кажется) всерьез обсуждалась тема процессора, который мог бы аппаратно только адресовать память и делать сложение и вычитание. Все остальное - вычислять программно. :-) За счет простой архитектуры поднять частоту до десятков гигагерц. :-)

> Я это вот к чему: частота не показатель.

Дык RISCи получились бы, только уж до полного абсурда доведенные. Это никому не нужно, проще делать небольшую урезку и многоядерность, как у Санок или ИБМ.

Можно проще, на один и тот же Amd64 3000+ (1 Гб ОЗУ) поставить Debian Etch i386 и для Amd64 (одной даты разлива) и без 3D ускорителей , думаю даже дети скажут: 64 бита режим быстрее . А один пользователь Amd64 был удивлен ,когда выяснил что можно и драйвер Nvidia установить - видео он и так хорошо смотрел на nv xorg. Все это ближе к эмоциям и наглядности ,но и тем не менее - и компиляция ядер это не ежедневная процедура для большинства людей .

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

А можно по конкретнее, о каком общем случае идет речь? Хочется услышать обоснование возвращения с Socket 939 обратно на интеловские обогреватели.

>А вот KDE при сборке использует fucking libtool, из-за чего почти всё время уходит на выполнение шелловских скриптов и нагрузка на процессор далеко не 100% и в бОльшей степени - system time.

Не вдаваясь в детали механизмов компиляции, как гентушник могу сказать, что компиляция KDE (+kdeenablefinal +kdehiddenvisibility) - единственный процесс, который в фоне иногда подтормаживаем машину на nForce 3 :) Судя по мониторам - тормозит на дисковых операциях.

> Поэтому ОЗУ используется менее эффективно как по размеру, так и по скорости передачи данных.

Кеши L1&L2 процессора также используются менее эффективно.

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

Вопрос адресован не мне, но могу ответить. В 64-бит ХР не работает ДОСовский софт, так же не работают некоторые программы, написанные для win9x. Меню настроек совместимости есть, но не работает (наверное оставили для совместимости :-)). Сама 64-бит ХР основана на базе 2003 сервера, о чем предупреждают некоторые инсталяторы. В реестре добавились ветки для 32-бит приложений (так называемый WoW - Winodows on Windows). Два осла 32 и 64-бит. Есть проблемы с дравами и системными костылями типа алкоголя и VCD, которые на ней не работают (это собственно единственное, чего не хватает после дума и первокваки :-)). Утечек памяти меньше, чем в обычной ХР. В целом, обычная венда 2003 сервер с GUI от ХР. Для игрушек пойдет.

З.Ы: За оффтоп не пинать :-)

> А ежели им нежно намекнуть у стенки о приросте производительности как минимум у криптографии

Для криптографии на 32-битных процах с 64-битной шиной есть 64-битный набор команд SSE2 и его поддержка в openssl.

> Можно проще, на один и тот же Amd64 3000+ (1 Гб ОЗУ) поставить Debian Etch i386 и для Amd64 (одной даты разлива) и без 3D ускорителей , думаю даже дети скажут: 64 бита режим быстрее . А один пользователь Amd64 был удивлен ,когда выяснил что можно и драйвер Nvidia установить - видео он и так хорошо смотрел на nv xorg. Все это ближе к эмоциям и наглядности ,но и тем не менее - и компиляция ядер это не ежедневная процедура для большинства людей .

TRUE.

AMD64 3000+ (1,5 Гб ОЗУ) смотрим ArchLinux 0.7.2 (i686) на 2.6.17 и аналогичный Arch64 0.7.2 (x86_64) на том же ядре. Arch64 грузится почти в два раза быстрее и работает заметно быстрее (дистр бинарный, т.ч. весь софт дистрибутивной сборки). Точные цифры привести не могу, т.к 32-бит версию уже снес, а замерять пингвинов интереса не было, но на слово думаю поверить можно.

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

>Office 2k3, Nero, WinDVD, Far, WinRAR, Daemon Tools.

WinRAR, Daemon Tools под XP-64 уже есть.

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

Не правда. Заменяли на 9 слесе ядро на (2.6.14) ванильное (слишком новое железо было) - работала долго, пока машину на другую не заменили.

> 64 - да, модно. НО! Как ни крути - это наше будущее... 32 рано или поздно умрут все-таки.

Ключевое слово - _будущее_. Но пионЭры пытаются воспринимать это как давно наступившее настоящее... А где-то мне попадалась статья аналитиков из Gartner Group, которые писали что реальное использование Vista стоит планировать не раньше 2008 года. Так что посматривать в сторону 64бит - можно уже сейчас, пытаться использовать - можно уже сейчас, но делать из этого "серебряную пулю" и "большую красную кнопку" нельзя. Что касается Exchange Server - прикинь временные интервалы между выходами новых версий, и приближенно оцени, в каком году он будет только 64 битным. Ко времени реально широкого промышленного использования 64-битных систем процессоры не раз поменяются. Теперешние 64 системы будут отличаться от систем _будущего_, думаю, не меньше чем 386 проц отличался от пня.

>long в 2 раза больше на х86_64. И, соответственно, в 2 раза увеличивается нагрузка на память и шину при оперировании данными типа long.

Еще и указатели в два раза больше! А указатели во всех программах широко применяются...

Ссылку на WinRAR под x64 дайте? :)

>давно наступившее настоящее

http://ru.wikipedia.org/wiki/DEC_Alpha

http://ru.wikipedia.org/wiki/SPARC

>Ключевое слово - _будущее_.

такие как вы тормозят прогресс.

>использование Vista

>Что касается Exchange Server

Плевать когда M$ сделает сови глюкавые поделки для 64 бит.

>широкого промышленного использования 64-битных систем

Оно уже давно на 64 битах. и саны и ibm-ы и т.п.

вообще неплохо было-бы убрать из amd64 поддержку 32-битного режима.

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


Я себе тоже скачал 64-битный Daemon Tools, но виндов 64-битных у меня не т. Так что насчет 1.3 миллиона - фигня все это !

> Для криптографии на 32-битных процах с 64-битной шиной есть 64-битный набор команд SSE2 и его поддержка в openssl.

Бггггг! Еще один отщепенец от 32 бит :) Почитай, сынок, какого типа числа юзаются криптографами ;)

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

А ты попускай с разными n и увидишь разницу. Ну разве что сейчас дисковая подсистема стала пошустрее поэтому возможны варианты не n+1 а скажем n+2 чтобы успевать грузить очередь задач. Просто сборка ядра это не чистый тест производительности проца. Вот PovRay NewMark действительно чистый тест на параллелизм. Там лучший результать где то между n и n+1.

PS: У Cell (по крайней мере у анонсированных версий) _ОДНО_ GP ядро.

ничё на _внутренних_ SPE ядрах ты запустить не сможешь хотя бы потому что они не видят внешнюю память. Там надо код векторизовать.

>ничё на _внутренних_ SPE ядрах ты запустить не сможешь хотя бы потому что они не видят внешнюю память.

И что? Вот, x86 ничего не видит на HDD. Однако это не мешает им исполнять код, который хранится на HDD.

>И что? Вот, x86 ничего не видит на HDD. Однако это не мешает им исполнять код, который хранится на HDD.

Еще как видит еще со времён 386 камней ;)

Ну и потом сколько размер локальной памяти в SPE в курсе ? ;)

Еще раз SPE != GP !

SPE неполноценные ядра. На них можно сбросить исполнение _части_ кода но не процесса целиком. Иначе нафиг вообще CPU исполняли бы код на GPU на видяшке ;)

>Еще как видит еще со времён 386 камней ;)

Драсьти, я ваша тётя. И давно у нас memory mapping'ом занимается непосредственно процессор?

>SPE неполноценные ядра. На них можно сбросить исполнение _части_ кода но не процесса целиком.

А теперь поясни свою потрясающую мысль.

Если "неполноценное ядро" способное самостоятельно считать блок кода, как из внешней памяти, так и с внешнего устройства или памяти других SPE и самостоятельно исполнить его - чем оно отличается от "полноценного"? Только тем, что его рабочая зона ОЗУ только 256кБ? Ну так может быть расширено до 4Гб в следующих версиях. Что, "полноценность" ядра стара объясняться только размером памяти? Расположением памяти? Тогда записывай в "неполноценные" целые семейства процессоров, в том числе и современных... и удивляйся, как же так они вообще автономно работают.

Откуда, вообще, пошла гулять эта дикая мысль, что ядрам SPE недоступно ничего, кроме локальной памяти? Они могут читать свою память, память других SPE (по внутренней скоростной шине!), читать внешнюю память и память внешних устройств. Да, всё, кроме локальной памяти - только запрограммировав процесс DMA-обмена, но протекать он будет автоматически, без их участия.

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

Вообще, RTFM: http://www.linux.org.ru/jump-message.jsp?msgid=1453117#1455028

>Иначе нафиг вообще CPU исполняли бы код на GPU на видяшке ;)

А вот у GPU, в отличие от SPE, нет возможности самостоятельно обратиться к внешним данным. Со всеми вытекающими.

>Ну и потом сколько размер локальной памяти в SPE в курсе ? ;)

Если мне не изменяет склероз, то 32 мегабайта сверхбыстрой Rambus в каждом SPE.

Много это или мало, решать вам, но у меня ядро Linux'а 2.6.18 со всеми вкомпилированными драйверами (за исключением NVidia) занимает в bzImage чуть больше 3-х мегабайт.
32 метра памяти, работающей на частоте процессора - это ДОФИГА. Это так много, что непонятно, зачем же ее столько сделали... А там ведь не 32, а 8*32М==256М - разные SPE могут друг другу дату перекидывать, если это предусмотрено софтом.
Далее, SPE могут обмениваться датой с Power-ядром и получать данные из "нормальной" оперативки.

Дальше: CISCO в свои маршрутизаторы ставит MIPS'ы или 486-е. И те же 32М памяти для хранения настроек/файрволла. Считается вполне достаточно.

>На них можно сбросить исполнение _части_ кода но не процесса целиком.

Почему нет? Процесс: декодирование видео. Вполне SPE справится. Собственно, изначально именно для таких процессов и предназначался.

>Иначе нафиг вообще CPU исполняли бы код на GPU на видяшке ;)

Эм. Я, кажется понял! Гы. Вы под выражением "процесс" понимаете нечто оконно-кнопочное, да? Вы, конечно, никогда не задумывались над тем, что окошки-кнопочки - это всего-лишь оболочка для процесса?

> Если мне не изменяет склероз, то 32 мегабайта сверхбыстрой Rambus в каждом SPE.

С кем вам изменила ваша память? ;) 256кб в локал-сторе каждого СПЕ всего, а не RDRAM, а XDR, Хотя в принципе Рамбус...

> 32 метра памяти, работающей на частоте процессора - это ДОФИГА.

Даже 512 - это дохренища, давался бы к ней нормальный доступ... ;)

> Эм. Я, кажется понял! Гы. Вы под выражением "процесс" понимаете нечто оконно-кнопочное, да? Вы, конечно, никогда не задумывались над тем, что окошки-кнопочки - это всего-лишь оболочка для процесса?

ЖжжошЪ, сцуко, в фортунки! ;)

>Вообще, RTFM

Вот именно. Начиная вот отсюда http://en.wikipedia.org/wiki/Cell_(microprocessor) а потом по ссылкам в конце страницы. Заодно разобратся что есть PPE и что что есть SPE

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

>Эм. Я, кажется понял! Гы. Вы под выражением "процесс" понимаете нечто оконно-кнопочное, да? Вы, конечно, никогда не задумывались над тем, что окошки-кнопочки - это всего-лишь оболочка для процесса?

Возьмите любой учебник по *NIX и прочитайте определение _процесса_ ;)

> Я себе тоже скачал 64-битный Daemon Tools, но виндов 64-битных у меня нет.

А зачем он тогда вам?

> А зачем он тогда вам?

Да все просто - вендузятнеги народ законопослушный, все покупают и лицензии свято чтят. Ну а когда недремлющий взор БиллиБалмера отвращается - из загашников извлекаются мегатонны вареза и начинаются дикарские пляски с дулей в кармане.

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

В моем понимании "процесс" в применении к IT - это конвертация информации из исходной к целевой по какому-либо принципу.

Готов спорить, что формулировка в мудрых книжках может отличаться, но суть останется прежней: пользовательский интерфейс является лишь одним из множества источников информации. А потому рассматривать пользовательский интерфейс как нечто особенное бессмысленно - M$ увлеклась именно этим и свернула себе шею на UI.

>Ссылку на WinRAR под x64 дайте? :) >Dimez (*) (25.09.2006 11:37:40)

Обшибка вышла, есть только UnRar x64 под винду: http://www.rarlab.com/rar/unrar-x64.zip

> http://ru.wikipedia.org/wiki/DEC_Alpha
> http://ru.wikipedia.org/wiki/SPARC

В сравнении с парком интела и амд - капля в море.

> такие как вы тормозят прогресс.

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

> Плевать когда M$ сделает сови глюкавые поделки для 64 бит.

Покажите мне плиз более-менее пристойный аналог ExchangeWFD. Сам по себе эксченж - байда, а вот WFD евонному пока опенсорсной замены я не нашел.

>Пожалуйста, просветите меня, темного. Ну не читал я мудрых книжек.

Это вы здря ;)

Вот начните вот с этого букваря

http://www.all-win.ru/2006/06/10/operacionnaja_sistema_unix.html

>более-менее пристойный аналог ExchangeWFD

The Workflow Designer for Exchange is a component of Microsoft Office XP Developer.

Нахрен оно вообще надо ?

> я просто жду

14 лет уже прошло (а то и более) с выхода первого 64-битного проца.

Ждите дальше.

>по всем разложенным граблям.

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

> The Workflow Designer for Exchange is a component of Microsoft Office XP Developer.

Это билли так говорит. На самом деле Workflow Designer бесплатно скачивается с мелкософта, для всех имеющих в своём хозяйстве Exchange.

> Нахрен оно вообще надо ?

Как ясно из названия - чтоб воркфлоу дизайнить :) В сочетании с эксченжевскими формами - довольно толковая вещь для организации корпоративного документооборота.

> 14 лет уже прошло (а то и более) с выхода первого 64-битного проца.

"Те вчера по пять были очень большие. А сегодня маленькие, но по три. А тут один на днях за рубль жабу предлагал, но очень зелёную" (с)
Если мы говорим про сравнение 32 и 64 бит на интел/амд, то процессора SPARC/DEC/прочее сюда никаким боком не относятся. А винтелоподобные поделки появились явно не 14 лет назад.
Появится у меня 64битная машинка от SPARC/DEC/... - с удовольствием буду юзать на ней 64битный линух. А интел/амд на 64 бита - пока не вижу особого смысла покупать.

>чтоб воркфлоу дизайнить :)

а можно по-русски ?

>для организации корпоративного документооборота.

А чем samba не годится ?

>А винтелоподобные поделки

А это еще што ?

>SPARC/DEC/прочее сюда никаким боком не относятся

http://www.ixbt.com/cpu/amd_roadmap.html

В самом низу. там как раз про alpha.