| 1.1, Nick (??), 16:12, 28/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 да...
вот эти процы бешенные....
4й пых за 35 секунд компилиццо %)
(да... я нашел чем померять ;))
| | |
| 1.4, TTT (?), 19:20, 28/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
какой-то непонятный тест: сравнил бы уже что ли 2-х и 4-х ядерные процессоры, что бы люди могли понять что выгоднее по цена/производительность, или сравнил бы с 4-х ядерными АМД...
кстати когда компилируют то нужно пользовать -j# где # = количество процессоров + 1, т.е. он должен был пользовать не 4 а 5.
| | |
| |
| 2.5, Nick (??), 19:30, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>кстати когда компилируют то нужно пользовать -j# где # = количество процессоров
>+ 1, т.е. он должен был пользовать не 4 а 5.
эх... ;)
древние знания седых админов...
может ты еще предложишь 2*MEM размером свопик делать на 8Гиговой системе? ;)
Времена меняюццо, друк...
для оптимизации использования системы для сборок нужно _каждый_ проц нагрузить
количеством задач _от_двух_. А это минимум -j 8 для таких 4х ядерников.
Физика проста ;) Сборка каждого объекта (предположим пользуя gcc) происходит
грубо в 3 этапа: чтение исходников с винта, компиляция, запись бинаря[ей] на винт.
Можем даже опустить единоразовые затраты на считывание самого gcc и его либ.
Они уже в кеше.
Вот и выходит, что любой процесс сборки бывает в своей жизни как минимум в друх состояниях
процесса: заблокированном в ожидании I/O и runnable. В каждом состоянии проставивает (соответственно) проц и винт. За сим, нужно каждый проц нагрузить минимум двумя задачами,
дабы первая пользовала винт, другая проц - и наоборот: первая - проц, вторая - винт.
Более точное количество нужно подбирать в зависимости от реального простоя процессора.
К сожалению, сей выбор упираеться другой стороной в пропускную носителя ФС :)
Так что именно 2 на проц - оптимально в большинстве случаев.
| | |
| |
| 3.6, exn (??), 19:36, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
брр.. гониво.
Нормальных бенчмарков полно, и не нужно изобретать велик.
| | |
| |
| |
| 5.17, pawnhearts (?), 21:16, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
есть классические наборы тестов, но они всё-таки довольно искуственные. сравнение производительности на реальных задачах куда интереснее.
| | |
| |
| 6.21, Nick (??), 21:48, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
вобщем, да
Жизнь показала, что "-j num = CPU num" - это мало.
Даже +1 - тоже мало.
По 3 процесса на проц - многовато. А вот 2 - в самый раз.
Если некий исскуственный тест выдаст, что оптимально - -j=2,45
то нафига такой тест?? %)
жизнь несколько отличаеться и не все можно отразить на жизнь из тестов...
| | |
|
|
|
| 3.19, pawnhearts (?), 21:43, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Физика проста ;) Сборка каждого объекта (предположим пользуя gcc) происходит
>грубо в 3 этапа: чтение исходников с винта, компиляция, запись бинаря[ей] на
>винт.
это уже не "грубо", а вообще _совсем_ не так:)
| | |
| |
| 4.22, Nick (??), 21:49, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
весь во внимании как будет правильно?
все промежуточные: cpp (не путать с c++) -> c -> asm -> .o вспомним?
Ну и сократим переходы в пайпах между ними - что останеться?
| | |
|
| 3.29, Michael Shigorin (ok), 00:27, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 >>кстати когда компилируют то нужно пользовать -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.
| | |
| |
| 4.34, Nick (??), 01:16, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Нет. До сих пор правило 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 --
>тоже глупости.
стоп-стоп
Мы о сборке, а не о бешенных юзерах-программеро-дезигнерах, которые ни веб, ни крипты,
ни базы писать не умеют. Там я вообще ничего не скажу кто чего и сколько хочет. Ибо _полный_ рандом.
| | |
|
|
| 2.25, pavlinux (??), 22:57, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
 Кто Вам сказал, такую глупость, что make -j x, где x = CPU+1.
и кто вам сказал, что make -j не от рута, разрешит разруливать задачи
по процессорам равномерно.
| | |
| |
| 3.28, Аноним (-), 00:02, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Кто Вам сказал, такую глупость, что make -j x, где x =
>CPU+1.
>и кто вам сказал, что make -j не от рута, разрешит разруливать
>задачи
>по процессорам равномерно.
учи матчасть. make ничего разруливать не будет, шедулер сам всё раскидает.
| | |
| 3.30, Michael Shigorin (ok), 00:30, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Кто Вам сказал, такую глупость, что make -j x, где x = CPU+1.
А Вам кто сказал, что это глупость? Вполне живое до сих пор эмпирическое правило. Вот когда ядер во средней вшивости тазике будет что блох на дворняге, тогда оно, разумеется, будет каши просить в коэффициент... правда, вовсе не факт, что тогда ещё будут мотать головами при сборке. Сейчас вон в tmpfs практичней получается.
| | |
| 3.32, Nick (??), 00:57, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
О, обкуренный Павлинух приполз %)
превед :))
>Кто Вам сказал, такую глупость, что make -j x, где x =
>CPU+1.
начал с пазитиффа :)
>и кто вам сказал, что make -j не от рута, разрешит разруливать
>задачи по процессорам равномерно.
закончил не то шобы за упокой, но пыталсо связывать несвязуемое...
make -j N просто будет пытаццо держать RUNNABLE N паралельных потоков сборки.
И все. А куда они там эти процессы пойдут отрабатывать - это make В ПРИНЦИПЕ не волнует :)
В дефолтной M-процессорной системе - равномерно будет разбрасывацо по процам.
Если cpuset'ом зажато какое место юзеру - ну, ниче не поделаешь: будет крутицо тока там где можно.
:)
а где ты такие маны берешь?? про рута... make разруливает по процессорам шо-то...
%)) какие чудные у тебя цветные сны!
| | |
| |
| 4.35, pavlinux (??), 01:21, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
%)) какие чудные у тебя цветные сны!
Вот и я о том же, make -j 4 - это ещё не зачит, что все майки разбегутся на все четыре ЦП.
P.S.
А я Висту поставил :)
| | |
| |
| 5.37, Nick (??), 02:57, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>%)) какие чудные у тебя цветные сны!
>
>Вот и я о том же, make -j 4 - это ещё
>не зачит, что все майки разбегутся на все четыре ЦП.
еще и как значит ;)
ну, ессьно, на всех 4-х должна быть тишина %)
>P.S.
>
> А я Висту поставил :)
а....
то-то я смарю ты такую пургу несешь...
сто пудов негросовта нюхнул...
| | |
| 5.43, R007 (?), 12:00, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> А я Висту поставил :)
Ты... ты.... ты гнусный проприетарщик!А ну немедленно переименовывайся, предатель :)))))
| | |
| |
| 6.53, Nick (??), 01:23, 01/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>> А я Висту поставил :)
>
>в wine'е ? :)
АААА
порвал! %))))
5!
| | |
|
|
|
|
| 2.49, TTT (?), 17:10, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
В рамках объективности я проверил, на моем двуядерном 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
так что часть времени тратилась ра распаковку сорсов, конфигурацию и установку скомпилиного продукта. перед тестом все программы по возможности выключил, даже иксы.
конечно интереснее было бы проверить на большем количестве процессоров, но это у меня наверное только через пару месяцев появиться...
| | |
| |
| 3.51, Nick (??), 21:06, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
откуда уверенность, что порт glibc допускает сборку с кастомными -j флагами?
вон gcc ложит на это дело и немало портов еще.
Лучьше на примере ядра с дефолтным конфигом. Там точно -j работает как сам задашь
| | |
| |
| 4.54, TTT (?), 14:51, 03/12/2007 [^] [^^] [^^^] [ответить]
| +/– |
>откуда уверенность, что порт glibc допускает сборку с кастомными -j флагами?
>вон gcc ложит на это дело и немало портов еще.
>
>Лучьше на примере ядра с дефолтным конфигом. Там точно -j работает как
>сам задашь
судя по тому что -j1 работает в полтора раза дольше оптимизация есть
| | |
|
|
|
| 1.9, Painbringer (?), 19:40, 28/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ну пока толк от sse4 будет - пару лет пройдет. в gcc поддержка появится только в 4.3.. а там пока его мантейнеры в дистры включат...
| | |
| |
| 2.14, Nick (??), 20:46, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
никто не мешает хоть сейчас самому делать вставки бинарного кода на асме... ;)
| | |
| |
| |
| 4.20, Nick (??), 21:45, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
ну а шо
ну можно взять вон ICC если в нем уже есть это новые инструкции ;)
| | |
| |
| 5.31, Michael Shigorin (ok), 00:31, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>ну а шо
Если вдуматься -- то бред, а так "ничо".
>ну можно взять вон ICC если в нем уже есть это новые
>инструкции ;)
If. (берут тут рядом...)
| | |
|
|
| 3.23, R007 (?), 21:50, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>никто не мешает хоть сейчас самому делать вставки бинарного кода на асме...
>;)
Осталось найти тех кто резко подорвется SSE4 учить.В лучшем случае через годик появится как оптимизация в mplayer и т.п..Тем не менее, не понимаю нахрен плодить дюжину наборов инструкций.Опять мелкие пакости в лагерь AMD?Лучше бы свой огрызок EM64T сделали полноценно, а то кастрат какой-то.Вместо этого еще SSE наплодили.Одно слово - интел.
| | |
|
| 2.45, TTT (?), 14:55, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
Я конечно могу сильно ошибаться... но на сколько я себе представляю, компилятроы даже mmx не вставляют. И если в вашей программе вы сами их через асемблер не вставите, то никаких mmx у вас не будет, слишком специфические эти инструкции... про все остально sse я вообще молчу.
а оптимизации под проц не означают вставление дополнительных специфичных инструкций а подстройку по скорости работы общих инструкци к примеру если приравнивание нуля регистру в core вдруг станет быстрей чем xor сам с собой, то компилятор будет при оптимизации на core выдавание приравнивание нуля а не xor
| | |
| |
| 3.50, Nick (??), 21:01, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>Я конечно могу сильно ошибаться...
ошибаешься и сильно.
Смотри ман того же gcc...
| | |
|
|
| 1.11, Аноним (11), 20:13, 28/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Объясните плиз тупому. Зачем центральному процессору заниматься акселерацией 2д и 3д графики? разве это не задача видеокарты?
| | |
| |
| 2.15, Nick (??), 20:47, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
с некоторых пор проц начал уж очень много проставивать....
память и тем паче винты осталены несколько позади по производительности.
ЗА сим, не грех некоторые задачи перекладывать на мощные плечи титанов
| | |
| |
| 3.24, R007 (?), 22:45, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>ЗА сим, не грех некоторые задачи перекладывать на мощные плечи титанов
Безусловно, гвоздь можно забить и микроскопом и даже HDD.Но молоток специально создан для этого.Видеокарта сделает то же самое быстрее, лучше и сожрав меньше энергии.Лучше б програминг видях развивали.Равно как и юзание оных для акселерации разных специфичных тяжелых рассчетов.А то и правда часто просто греют воздух не по делу(не все же геймеры, а?).
| | |
| |
| |
| 5.27, R007 (?), 23:34, 28/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
>А ты не ставь NVIDIA Quadro FX 5500 на Gentoo :)
А я и не ставлю, просто сейчас хилую видяху при всем желании не купишь.Разве что Б\У или негарантийный лежак на складах.
| | |
| |
| 6.33, Nick (??), 01:01, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>А я и не ставлю, просто сейчас хилую видяху при всем желании
>не купишь.Разве что Б\У или негарантийный лежак на складах.
а вот еслипросто взять... и забыть (чучуть ;) о видухе...
и просто юзать встроенную.
Вот тебе разумное соотношение цены/кагчества для Gentoo и SSE4 :)))
| | |
| |
| 7.42, R007 (?), 11:45, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– | |
> и просто юзать встроенную.
Опять же, мамки с встроенной видяхой обычно или нацелены на каких-то недоносков типа HTPC с формфактором навроде microATX и кастрированной периферией или же это серверные мамки нацеленные на весьма серьезные сервера.Получается что есть сегмент PC где 1 хрен придется купить какую-никакую видяху.Скажем мне вот на десктоп как ни крути, серверная мамка оверкилл и вообще неудобна.Недоноски микроATXные на убогих чипсетах мне тоже как-то не нужны.Вот и получается что приличную видяху по любому купишь.Других 1 фиг не продают :)
А так да, вбить гвоздь микроскопом и с помпой объявить функцию "молоток" новой фичой микроскопа - это истинно по интеловски, не отнять ;).Осталось теперь всех убедить что им надо выкинуть молотки и использовать для забивания гвоздей эти новые микроскопы которые "только сегодня по суперцене".Я еще могу понять когда 3D лезут обсчитывать на Cell - он в этом плане реально может чем-то козырнуть.Но вот интельское чудо создано для 3D как топор для плавания по рекам.
| | |
|
|
|
|
|
| 2.40, otaku (ok), 06:31, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>Объясните плиз тупому. Зачем центральному процессору заниматься акселерацией 2д и 3д графики?
>разве это не задача видеокарты?
ну хотя бы при просмотре видео его декодирует проц, а не видюха, хотя есть кодек от нвидии и ещё от кого то который умеет при этом грузить видюху, но эти кодеки платные.
Новые инструкции позволят в будущем легче декодировать хдтв.
| | |
| |
| 3.44, R007 (?), 12:03, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
>ну хотя бы при просмотре видео его декодирует проц, а не видюха,
>хотя есть кодек от нвидии и ещё от кого то который
>умеет при этом грузить видюху, но эти кодеки платные.
>Новые инструкции позволят в будущем легче декодировать хдтв.
Угу, поэтому чтобы довести до ума молоток, используем попавшийся под руку микроскоп?По мне так лучше б для таких вычислений отдельные (со)процессоры припахивать а не пытаться прикрутить костыли к x86 как это вечно делает интель.Впрочем чего еще от компании сделавшей такое угробище как х86 ожидать? oO
| | |
|
|
| 1.36, nam (??), 02:55, 29/11/2007 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
угу особенно если встроенная не интел, не ати, и не нвидиа, сильно бует...
| | |
| |
| |
| 3.39, Nick (??), 03:17, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
о....
ну это уж совсем если забыть что такое видуха и ставить сервак на такое железо
по remote boot, с преконфигуренным инсталлером %)
так чтоб и монитор не включать
| | |
| |
| 4.41, Ne01eX (??), 08:10, 29/11/2007 [^] [^^] [^^^] [ответить]
| +/– |
Не знаю, как у красноглазых, но софт при любых ключах make собирается значительно быстрее если пить пиво и при этом бренчать в мегашаманский бубен. =)
| | |
|
|
|
|
