В статье "Intel Core 2 "Penryn" Performance under Linux (http://www.linuxhardware.org/article.pl?sid=07/11/21/152234)" представлены результаты тестирования производительности различных Linux операций на машине с новым четырехядерным процессором Intel Core 2 "Penryn".
Среди тестов: сборка GlibC 2.5, кодирование аудио и видео, рендеринг 3D сцен, производительность игр Quake 3 и Enemy Territory, оценка энергопотребления.
В CPU Intel Core 2 "Penryn" реализовано (http://www.linuxhardware.org/article.pl?sid=07/11/15/2015212...) около 50 новых инструкций SSE4. Новые инструкции можно разделить на две категории - мультимедиа акселерация (для обработки графики и видео, 2-D и 3-D преобразований) и обработка тестовых данных (оптимизация поиска, выделения сигнатур, операций по сжатию данных). Кроме того реализовано два новых энергосберегающих режима: "Deep Power Down Technology" и "Enhanced Intel Dynamic Acceleration Technology"URL: http://www.linuxhardware.org/article.pl?sid=07/11/21/152234
Новость: http://www.opennet.me/opennews/art.shtml?num=12965
да...вот эти процы бешенные....
4й пых за 35 секунд компилиццо %)
(да... я нашел чем померять ;))
А еще желательно писать грамотно
а зачем?
не на диктанте же...
Чтобы новички, вроде меня, могли Вас понять.
а..
пардон за мой французский...
Ну и не среди же обезьян
какой-то непонятный тест: сравнил бы уже что ли 2-х и 4-х ядерные процессоры, что бы люди могли понять что выгоднее по цена/производительность, или сравнил бы с 4-х ядерными АМД...кстати когда компилируют то нужно пользовать -j# где # = количество процессоров + 1, т.е. он должен был пользовать не 4 а 5.
>кстати когда компилируют то нужно пользовать -j# где # = количество процессоров
>+ 1, т.е. он должен был пользовать не 4 а 5.эх... ;)
древние знания седых админов...может ты еще предложишь 2*MEM размером свопик делать на 8Гиговой системе? ;)
Времена меняюццо, друк...
для оптимизации использования системы для сборок нужно _каждый_ проц нагрузить
количеством задач _от_двух_. А это минимум -j 8 для таких 4х ядерников.Физика проста ;) Сборка каждого объекта (предположим пользуя gcc) происходит
грубо в 3 этапа: чтение исходников с винта, компиляция, запись бинаря[ей] на винт.
Можем даже опустить единоразовые затраты на считывание самого gcc и его либ.
Они уже в кеше.
Вот и выходит, что любой процесс сборки бывает в своей жизни как минимум в друх состояниях
процесса: заблокированном в ожидании I/O и runnable. В каждом состоянии проставивает (соответственно) проц и винт. За сим, нужно каждый проц нагрузить минимум двумя задачами,
дабы первая пользовала винт, другая проц - и наоборот: первая - проц, вторая - винт.
Более точное количество нужно подбирать в зависимости от реального простоя процессора.
К сожалению, сей выбор упираеться другой стороной в пропускную носителя ФС :)
Так что именно 2 на проц - оптимально в большинстве случаев.
брр.. гониво.
Нормальных бенчмарков полно, и не нужно изобретать велик.
да, ну и конечно же
"полно" в студию, плз
есть классические наборы тестов, но они всё-таки довольно искуственные. сравнение производительности на реальных задачах куда интереснее.
вобщем, даЖизнь показала, что "-j num = CPU num" - это мало.
Даже +1 - тоже мало.
По 3 процесса на проц - многовато. А вот 2 - в самый раз.Если некий исскуственный тест выдаст, что оптимально - -j=2,45
то нафига такой тест?? %)жизнь несколько отличаеться и не все можно отразить на жизнь из тестов...
>Физика проста ;) Сборка каждого объекта (предположим пользуя gcc) происходит
>грубо в 3 этапа: чтение исходников с винта, компиляция, запись бинаря[ей] на
>винт.это уже не "грубо", а вообще _совсем_ не так:)
весь во внимании как будет правильно?все промежуточные: cpp (не путать с c++) -> c -> asm -> .o вспомним?
Ну и сократим переходы в пайпах между ними - что останеться?
>>кстати когда компилируют то нужно пользовать -j# где # = количество процессоров
>>+ 1, т.е. он должен был пользовать не 4 а 5.
>эх... ;) древние знания седых админов...И вовсе не удавщиков при этом.
>может ты еще предложишь 2*MEM размером свопик делать на 8Гиговой системе? ;)
>Времена меняюццо, друк...
>для оптимизации использования системы для сборок нужно _каждый_ проц нагрузить
>количеством задач _от_двух_. А это минимум -j 8 для таких 4х
>ядерников.Нет. До сих пор правило N+1 работает хорошо, потому как запасной процесс именно на I/O и подскакивает своё отработать. Вы предлагаете то, что склонно приводить к scheduler thrashing -- оверхед на переключение начинает быть заметен.
>Они уже в кеше.
И тут их оттудова выпинывают, потому как слайс закончился... (я про CPU cache)
>За сим, нужно каждый проц нагрузить минимум двумя задачами,
>дабы первая пользовала винт, другая проц - и наоборот: первая - проц,
>вторая - винт.Это если на каждый проц -- свой винт, и сидят они в камере строгого режима. В реальной жизни так не бывает.
>Так что именно 2 на проц - оптимально в большинстве случаев.
Глупости.
PS: и для связок навроде apache+mysql, которые зачастую более i/o bound -- тоже глупости.
PPS: проверял на 1..8-way.
>Нет. До сих пор правило N+1 работает хорошо, потому как запасной
>процесс именно на I/O и подскакивает своё отработать.Даже если речь идет о каком-нить Dual Xeon'е, где, собсно 2 чесных проца,
а два так, поржать (HT) - то даже в таком случае CPUs+2 будет более оптимальной формулой,
чем CPUs+1. 2*CPUs - это именно на честных сабжах.
>Вы предлагаете
>то, что склонно приводить к scheduler thrashing -- оверхед на переключение
>начинает быть заметен.Потери переключений/потери кеша ничто в сравнении с простоем проца и (уж тем более!)
винта.
>>Они уже в кеше.
>И тут их оттудова выпинывают, потому как слайс закончился... (я про CPU
>cache)Я вообще-то был об FS cache. Ну а если про CPU cache - то и тут все не так мрачно.
Когда в конкурентной работе (на одном проце) два (или n+1) процесса с одинаковыми
страницами кода, то даже при переключении контекста, кеш не будет потерят,
т.к. оба процесса использовали одни и те же страницы. Нет большой необходимости
перезагружать одно и то же в кеш. И шедулер об этом знает... ;)
>>За сим, нужно каждый проц нагрузить минимум двумя задачами,
>>дабы первая пользовала винт, другая проц - и наоборот: первая - проц,
>>вторая - винт.
>
>Это если на каждый проц -- свой винт, и сидят они в
>камере строгого режима. В реальной жизни так не бывает.Время, затраченное на чтение исходника и запись бинаря, много меньше чем на процесс компиляции. Вывод: если хоть один проц простаивает или в состоянии iowait - то вы недогрузили сборочную машину. Это намного страшнее по временным затратам, чем
напряги шедулера.
Практически всегда при сборке процы загрузить намного проще, чем винт.
>PS: и для связок навроде apache+mysql, которые зачастую более i/o bound --
>тоже глупости.стоп-стоп
Мы о сборке, а не о бешенных юзерах-программеро-дезигнерах, которые ни веб, ни крипты,
ни базы писать не умеют. Там я вообще ничего не скажу кто чего и сколько хочет. Ибо _полный_ рандом.
>>Нет. До сих пор правило N+1 работает хорошо, потому как запасной
>>процесс именно на I/O и подскакивает своё отработать.
>Даже если речь идет о каком-нить Dual Xeon'е, где, собсно 2 чесных
>проца,Это в смысле Katmai какие? Ну вот стоит Quad на площадке, один из тех, о ком речь. В т.ч. занимается сборкой (точнее, года полтора назад ещё активно занимался, сейчас скорее изредка).
>а два так, поржать (HT)
Это в P4-based... и именно что поржать, учесть их толком не получается -- где чуточку лучше, где на треть хуже.
>то даже в таком случае CPUs+2 будет более оптимальной формулой,
>чем CPUs+1. 2*CPUs - это именно на честных сабжах.Простите, но на нечестных можно только гадать.
>>Вы предлагаете то, что склонно приводить к scheduler thrashing -- оверхед
>>на переключение начинает быть заметен.
>Потери переключений/потери кеша ничто в сравнении с простоем проца и (уж тем
>более!) винта.Да, но если затыков в I/O особенных нет (при той же сборке это типично -- надо чем-то выжрать всю полосу пропускания типичного для заданной системы стораджа, чтоб сборка начала голодать именно по диску) -- то оверхед начинает быть заметен.
>>>Они уже в кеше.
>>И тут их оттудова выпинывают, потому как слайс закончился... (я про CPU
>>cache)
>Я вообще-то был об FS cache.Да понятно ;)
>Ну а если про CPU cache - то и тут все не так мрачно.
>Когда в конкурентной работе (на одном проце) два (или n+1) процесса с
>одинаковыми страницами кода, то даже при переключении контекста, кеш не будет потерят,
>т.к. оба процесса использовали одни и те же страницы.Это "когда". Посмотрите на working set типичного cc1 и размер кэшей того, что под рукой...
>Время, затраченное на чтение исходника и запись бинаря, много меньше чем на
>процесс компиляции. Вывод: если хоть один проц простаивает или в состоянии
>iowait - то вы недогрузили сборочную машину.Именно.
>Это намного страшнее по временным затратам, чем напряги шедулера.
>Практически всегда при сборке процы загрузить намного проще, чем винт.Сдуру перегрузить можно и то, и другое.
>>PS: и для связок навроде apache+mysql, которые зачастую более i/o bound --
>>тоже глупости.
>стоп-стоп
>Мы о сборке, а не о бешенных юзерах-программеро-дезигнерах, которые ни веб, ни
>крипты, ни базы писать не умеют. Там я вообще ничего не скажу кто
>чего и сколько хочет. Ибо _полный_ рандом.Я просто добавил, что даже для _более_ i/o bound tasks, когда действительно на каждое ядро можно и нужно наваливать больше -- при полной прогрузке "это не так".
Собственно, для случая мелкого хостинга без больших затыков это оббенчивалось и разбиралось здесь: http://lists.altlinux.org/pipermail/sysadmins/2007-August/01...
Для сборки -- практическое правило остаётся вида Ncpu+M, а не Ncpu*M. При этом либо M всё равно мало по сравнению с Ncpu, либо фиксить надо не коэффициенты, а дисковую (возможно, переездом в память).
Кто Вам сказал, такую глупость, что make -j x, где x = CPU+1.
и кто вам сказал, что make -j не от рута, разрешит разруливать задачи
по процессорам равномерно.
>Кто Вам сказал, такую глупость, что make -j x, где x =
>CPU+1.
>и кто вам сказал, что make -j не от рута, разрешит разруливать
>задачи
>по процессорам равномерно.учи матчасть. make ничего разруливать не будет, шедулер сам всё раскидает.
>Кто Вам сказал, такую глупость, что make -j x, где x = CPU+1.А Вам кто сказал, что это глупость? Вполне живое до сих пор эмпирическое правило. Вот когда ядер во средней вшивости тазике будет что блох на дворняге, тогда оно, разумеется, будет каши просить в коэффициент... правда, вовсе не факт, что тогда ещё будут мотать головами при сборке. Сейчас вон в tmpfs практичней получается.
О, обкуренный Павлинух приполз %)
превед :))>Кто Вам сказал, такую глупость, что make -j x, где x =
>CPU+1.начал с пазитиффа :)
>и кто вам сказал, что make -j не от рута, разрешит разруливать
>задачи по процессорам равномерно.закончил не то шобы за упокой, но пыталсо связывать несвязуемое...
make -j N просто будет пытаццо держать RUNNABLE N паралельных потоков сборки.
И все. А куда они там эти процессы пойдут отрабатывать - это make В ПРИНЦИПЕ не волнует :)В дефолтной M-процессорной системе - равномерно будет разбрасывацо по процам.
Если cpuset'ом зажато какое место юзеру - ну, ниче не поделаешь: будет крутицо тока там где можно.
:)
а где ты такие маны берешь?? про рута... make разруливает по процессорам шо-то...
%)) какие чудные у тебя цветные сны!
%)) какие чудные у тебя цветные сны!Вот и я о том же, make -j 4 - это ещё не зачит, что все майки разбегутся на все четыре ЦП.
P.S.
А я Висту поставил :)
>%)) какие чудные у тебя цветные сны!
>
>Вот и я о том же, make -j 4 - это ещё
>не зачит, что все майки разбегутся на все четыре ЦП.еще и как значит ;)
ну, ессьно, на всех 4-х должна быть тишина %)>P.S.
>
> А я Висту поставил :)а....
то-то я смарю ты такую пургу несешь...
сто пудов негросовта нюхнул...
> А я Висту поставил :)Ты... ты.... ты гнусный проприетарщик!А ну немедленно переименовывайся, предатель :)))))
> А я Висту поставил :)в wine'е ? :)
>> А я Висту поставил :)
>
>в wine'е ? :)АААА
порвал! %))))5!
В рамках объективности я проверил, на моем двуядерном pentium D 2.8GHz по 1Mb кеша разница во времени при компиляции glibc-2.6.1 при опциях -j(2-4) менее 0.25%, причем не в чью конкретно пользу. запускал тесты по 2 раза на каждую цифру. Данную разницу можно отнести к погрешности.
точные замеры:-j1 32:07.473
-j2 21:41.745, 21:40.368
-j3 21:40.793, 21:34.205
-j4 21:25.758, 21:35.959сразу говорю что в ручну не собирал, а пользовался командой
emerge glibc
так что часть времени тратилась ра распаковку сорсов, конфигурацию и установку скомпилиного продукта. перед тестом все программы по возможности выключил, даже иксы.конечно интереснее было бы проверить на большем количестве процессоров, но это у меня наверное только через пару месяцев появиться...
откуда уверенность, что порт glibc допускает сборку с кастомными -j флагами?
вон gcc ложит на это дело и немало портов еще.Лучьше на примере ядра с дефолтным конфигом. Там точно -j работает как сам задашь
>откуда уверенность, что порт glibc допускает сборку с кастомными -j флагами?
>вон gcc ложит на это дело и немало портов еще.
>
>Лучьше на примере ядра с дефолтным конфигом. Там точно -j работает как
>сам задашьсудя по тому что -j1 работает в полтора раза дольше оптимизация есть
косвенно, но верно
Ну пока толк от sse4 будет - пару лет пройдет. в gcc поддержка появится только в 4.3.. а там пока его мантейнеры в дистры включат...
никто не мешает хоть сейчас самому делать вставки бинарного кода на асме... ;)
"бинарный код на асме" это сильно)) хехех
ну а шону можно взять вон ICC если в нем уже есть это новые инструкции ;)
>ну а шоЕсли вдуматься -- то бред, а так "ничо".
>ну можно взять вон ICC если в нем уже есть это новые
>инструкции ;)If. (берут тут рядом...)
>никто не мешает хоть сейчас самому делать вставки бинарного кода на асме...
>;)Осталось найти тех кто резко подорвется SSE4 учить.В лучшем случае через годик появится как оптимизация в mplayer и т.п..Тем не менее, не понимаю нахрен плодить дюжину наборов инструкций.Опять мелкие пакости в лагерь AMD?Лучше бы свой огрызок EM64T сделали полноценно, а то кастрат какой-то.Вместо этого еще SSE наплодили.Одно слово - интел.
на gcc свет не сошёлся, некоторые пользуют icc ;-)
Я конечно могу сильно ошибаться... но на сколько я себе представляю, компилятроы даже mmx не вставляют. И если в вашей программе вы сами их через асемблер не вставите, то никаких mmx у вас не будет, слишком специфические эти инструкции... про все остально sse я вообще молчу.а оптимизации под проц не означают вставление дополнительных специфичных инструкций а подстройку по скорости работы общих инструкци к примеру если приравнивание нуля регистру в core вдруг станет быстрей чем xor сам с собой, то компилятор будет при оптимизации на core выдавание приравнивание нуля а не xor
>Я конечно могу сильно ошибаться...ошибаешься и сильно.
Смотри ман того же gcc...
Объясните плиз тупому. Зачем центральному процессору заниматься акселерацией 2д и 3д графики? разве это не задача видеокарты?
с некоторых пор проц начал уж очень много проставивать....память и тем паче винты осталены несколько позади по производительности.
ЗА сим, не грех некоторые задачи перекладывать на мощные плечи титанов
>ЗА сим, не грех некоторые задачи перекладывать на мощные плечи титановБезусловно, гвоздь можно забить и микроскопом и даже HDD.Но молоток специально создан для этого.Видеокарта сделает то же самое быстрее, лучше и сожрав меньше энергии.Лучше б програминг видях развивали.Равно как и юзание оных для акселерации разных специфичных тяжелых рассчетов.А то и правда часто просто греют воздух не по делу(не все же геймеры, а?).
А ты не ставь NVIDIA Quadro FX 5500 на Gentoo :)
>А ты не ставь NVIDIA Quadro FX 5500 на Gentoo :)А я и не ставлю, просто сейчас хилую видяху при всем желании не купишь.Разве что Б\У или негарантийный лежак на складах.
>А я и не ставлю, просто сейчас хилую видяху при всем желании
>не купишь.Разве что Б\У или негарантийный лежак на складах.а вот еслипросто взять... и забыть (чучуть ;) о видухе...
и просто юзать встроенную.
Вот тебе разумное соотношение цены/кагчества для Gentoo и SSE4 :)))
> и просто юзать встроенную.Опять же, мамки с встроенной видяхой обычно или нацелены на каких-то недоносков типа HTPC с формфактором навроде microATX и кастрированной периферией или же это серверные мамки нацеленные на весьма серьезные сервера.Получается что есть сегмент PC где 1 хрен придется купить какую-никакую видяху.Скажем мне вот на десктоп как ни крути, серверная мамка оверкилл и вообще неудобна.Недоноски микроATXные на убогих чипсетах мне тоже как-то не нужны.Вот и получается что приличную видяху по любому купишь.Других 1 фиг не продают :)
А так да, вбить гвоздь микроскопом и с помпой объявить функцию "молоток" новой фичой микроскопа - это истинно по интеловски, не отнять ;).Осталось теперь всех убедить что им надо выкинуть молотки и использовать для забивания гвоздей эти новые микроскопы которые "только сегодня по суперцене".Я еще могу понять когда 3D лезут обсчитывать на Cell - он в этом плане реально может чем-то козырнуть.Но вот интельское чудо создано для 3D как топор для плавания по рекам.
>Объясните плиз тупому. Зачем центральному процессору заниматься акселерацией 2д и 3д графики?
>разве это не задача видеокарты?ну хотя бы при просмотре видео его декодирует проц, а не видюха, хотя есть кодек от нвидии и ещё от кого то который умеет при этом грузить видюху, но эти кодеки платные.
Новые инструкции позволят в будущем легче декодировать хдтв.
>ну хотя бы при просмотре видео его декодирует проц, а не видюха,
>хотя есть кодек от нвидии и ещё от кого то который
>умеет при этом грузить видюху, но эти кодеки платные.
>Новые инструкции позволят в будущем легче декодировать хдтв.Угу, поэтому чтобы довести до ума молоток, используем попавшийся под руку микроскоп?По мне так лучше б для таких вычислений отдельные (со)процессоры припахивать а не пытаться прикрутить костыли к x86 как это вечно делает интель.Впрочем чего еще от компании сделавшей такое угробище как х86 ожидать? oO
>Новые инструкции позволят в будущем легче декодировать хдтв.Пока жертвы Intel ждут этого будущего, домашние пользователи AMD уже смотрят 1080p :)
http://lists.altlinux.org/pipermail/devel/2007-November/0663...
http://lists.altlinux.org/pipermail/hardware/2007-November/0...
угу особенно если встроенная не интел, не ати, и не нвидиа, сильно бует...
помогать в обработке, особенно видео... хех
о....
ну это уж совсем если забыть что такое видуха и ставить сервак на такое железо
по remote boot, с преконфигуренным инсталлером %)так чтоб и монитор не включать
Не знаю, как у красноглазых, но софт при любых ключах make собирается значительно быстрее если пить пиво и при этом бренчать в мегашаманский бубен. =)
http://www.anandtech.com/IT/showdoc.aspx?i=3162&p=1