LINUX.ORG.RU
ФорумTalks

Из-за чего (в теории) такое может быть?

 белкины извращения


0

2

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

Конфиг: 2 проца по 8 ядер с НТ (зионы из последних), 128 ецц рамы, 0-й рейд из 4 дисков на крутом железном адаптеке.

Софтинка шьет 684 кадра по 36мп.

Одна из целей тестов - понять на скольки ядрах лучше всего шить.

Выяснилось, что:

1. Включение НТ конкретно в этом случае дает проседание на 10-15% (при этом при сшивке мелких панорам НТ дает прирост 30%);

2. На стадии сшивки (т.е. где работа с гометрией, еще до блендинга) память не выжирается полностью. Даже за вычетом «кэшированной» памяти (дисковый кэш?) остается еще 20-30гб свободной; (но на стадии блендинга память выжирается моментально, свободной - не более 100мб)

3. Загрузка процессора ни в одном конфиге (речь о количестве активных ядер) не превышает 80-90%.

Казалось бы - включи все 16 ядер (оперативка все равно полностью не выжирается, т.е. оверхеда на запись кэшей на диск не будет) - и радуйся. Так нет же! Если оставить только 12 ядер, то шьется быстрее примерно на 20%.

Из-за чего такое может быть?! Ну в теории. Ясень пень это вилами по воде.

Добавлено:

Еще гоняли тесты на конфигурации с жипегами не по 36, а по 200мб. Там оптимально было 8 ядер. Но... ввиду полного выжирания оперативки. На большем числе потоков свопилось слишком сильно.

Кэши пишутся в любом случае, но тут ситуация следующая:

а) в любом случае записывается 53гб кэша - на одной из первых стадий сшивки;

б) во время самой сшивки, дляшейся около часа записывается еще порядка 15гб, и считывается порядка 10гб. т.е. нет упирания в и\о дисков. Пишется\читается на 99% блоками по 64к.



Последнее исправление: dk- (всего исправлений: 1)

Может ширины линка между процессорами не хватает тупо?

dk-
() автор топика
Ответ на: комментарий от xtraeft

Короче, рассказываю в первый и последний раз. Тезисно:

1. Что из моих тредов тереть - решать модераторам. Трут - молчу.

2. Я прекрасно понимаю, что есть ряд людей, которых я могу даже раздражать. И что? И ничего. Всем не угодишь (ну если не «не писать вообще ничего»).

3. В _каждой_ моей теме находятся не один и не два комментатора, дающих нормальные ответы по теме. Приносящих пользу. А нередко поднимаемые мною темы расползаются на дискуссии на несколько страниц.

4. Если кому-то надоело или не нравится - он может: не читать \ заигнорить.

5. Иногда и от меня на форуме бывает польза. Но редко, как ни крути у меня линкус только в виде андроида, а юникс только в виде иоси.

dk-
() автор топика

остается еще 20-30гб свободной;

Думаю ошибка здесь. Очевидно, что тебе не хватает памяти.

ziemin ★★
()
Ответ на: комментарий от xtraeft

бла-бла-бла

ты так же реагируешь на мои вообще не софтовые (железные) темы.

ты так же реагируешь на темы, которые народ обсуждает на несколько страниц.

а софт кросс-платформенный.

dk-
() автор топика
Ответ на: комментарий от ziemin

Почему? Она же _совсем_ свободная. Т.е. это то, что осталось после «память процесса» и «кэшировано».

dk-
() автор топика
Ответ на: комментарий от dk-

ты так же реагируешь на мои вообще не софтовые (железные) темы.

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

xtraeft ★★☆☆
()
Ответ на: комментарий от xtraeft

Перечитай ту тему.

В нее же никто не отписался и ничего не обсуждал, правда?

dk-
() автор топика
Ответ на: комментарий от ziemin

Нет такой команды :(

Кроссплатформенность только для мака, под линкус нет бинарника.

В чем суть этого параметра? По беглому гуглу - не понял.

Может и смогу узнать.

dk-
() автор топика
Ответ на: комментарий от dk-

iotop - display top disk I/O events by process.

2013 Jul 22 04:23:20,  load: 0.81,  disk_r:      0 KB,  disk_w:     12 KB

  UID    PID   PPID CMD              DEVICE  MAJ MIN D            BYTES
  501  70303  82140 php              ??        1   5 W             4096
  501  70309  82140 php              ??        1   5 W             4096
  501  70315  82140 php              ??        1   5 W             4096
xtraeft ★★☆☆
()

Что меряет iotop?

Всяко есть чем это считать.

количество и\о в сек для процесса? или что?

если тупо в гигабайтах, то записываются файлы по 512мб общим размером в 53гб, и потом еще 15гб. и это в течение часа, равномерно по времени.

dk-
() автор топика
Ответ на: комментарий от ziemin

мне очень сложно по IPMI поставить макось :)

dk-
() автор топика
Ответ на: комментарий от dk-

1. Включение НТ конкретно в этом случае дает проседание на 10-15% (при этом при сшивке мелких панорам НТ дает прирост 30%);

А это о чем? Другое HT, не hyper threading ?

gh0stwizard ★★★★★
()
Ответ на: комментарий от gh0stwizard

Ок, признаю, я двусмысленно сформулировал.

Уточню:

Речь не о НТ.

Речь о том, что если вместо 16 реальных ядер считать на 12 реальных ядрах - получается быстрее. При этом ресурсы типа оперативки и ширины канала записи на диск - не выедаются.

dk-
() автор топика
Ответ на: комментарий от dk-

Конфиг: 2 проца по 8 ядер с НТ
Речь о том, что если вместо 16 реальных ядер считать на 12 реальных ядрах - получается быстрее.

Если у тебя 8-ядерные процы, например, E5-4650L, то у тебя получается 16 реальных ядер и 16 дополнительных от HT (в сумме 32). А если у тебя 4 ядерные (+4 HT), то тогда получается, что работает 8 реальных ядер (4+4) и 4+4 из HT (в сумме 16). В последнем случае у тебя HT работает наполовину и дает какой-то «мистический» прирост производительности. Вобщем, все вопросы к поставщику программы.

Речь не о НТ.

Ну если не об HT, то о кривых оптимизациях в ПО :) Масштабируемость по процессорам/ядрам должна быть линейной, а не с «провалами». Статью же не просто так дал.

gh0stwizard ★★★★★
()
Ответ на: комментарий от gh0stwizard

НТ отключен нафиг в биосе. Количестно активных ядер меняю там же. Выставив по 6 на процессор.

Ну мне тоже кажется, что линейно должно быть.

dk-
() автор топика
Ответ на: комментарий от xtraeft

Смотри:

Вот я - поганый вендузятник и офтоповод.

А тут - «Акции Microsoft упали на 10%» - на 9 страниц обсуждают венду и ее акции. Причем я (поганый вендузятник) тот сабж даже на скриншотах не видел.

Чудно, да?)

dk-
() автор топика
Ответ на: комментарий от dk-

Видимо об этом он не писал, только рассказывал. В общем, выясняется, что из-за особенностей строения шины, которая связывает ядра, на некоторых задачах (он угорает обработкой равов) отключение некоторых ядер приводит к значительному росту общей производительности. Это есть и в AMD, и в Intel. Этот эффект ты наблюдаешь.

Shaman007 ★★★★★
()

Включение НТ конкретно в этом случае дает проседание на 10-15% (при этом при сшивке мелких панорам НТ дает прирост 30%);

HT даёт прирост к скорости числодробления, но шину памяти и кэш уполовинивает. Поэтому если задача упирается в вычисления, HT даёт прирост, а если в пропускную способность памяти — замедление.

но на стадии блендинга память выжирается моментально

Возможно, для блендинга выделяются дополнительные буферы. Некоторым алгоритмам нужно рабочее пространство, некоторые могут работать in-place.

Загрузка процессора ни в одном конфиге (речь о количестве активных ядер) не превышает 80-90%.

Время теряется на синхронизации. Если поток ждёт освобождения mutex'а, он спит и полезной работы не выполняет.

Казалось бы - включи все 16 ядер (оперативка все равно полностью не выжирается, т.е. оверхеда на запись кэшей на диск не будет) - и радуйся. Так нет же! Если оставить только 12 ядер, то шьется быстрее примерно на 20%.

http://ru.wikipedia.org/wiki/Закон_Амдала

Есть ещё эффекты из реальности, которые накладывают отпечаток на идеальные кривые из закона Амдала. При увеличении потоков накладные расходы на синхронизацию и коммуникацию растут квадратично, и начиная с некоторого количества потоков итоговая скорость падает. И есть ещё суперлинейное ускорение, когда вместо двух процессоров начинаешь использовать четыре, а расчёт ускоряется больше чем в два раза. Такое происходит, если задача на двух CPU не влазит в кэш, а на четырёх начинает влазить.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Во!

Довольно интересно. Я, по логике, догадывался, что «тупо наращивать вычислители не всегда обязано приводить к росту», но ничего не знал какие там механизмы.

cast xtraeft, правда прикольно?

dk-
() автор топика
Ответ на: комментарий от dk-

Начиная с некоторых объёмов задач, стоит двигаться в сторону MapReduce. Масштабируемость там почти идеальная, правда интерактивности никакой.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Я не программист и код софта закрыт :)

dk-
() автор топика
Ответ на: комментарий от ekzotech

Нету, под макось есть.

Еще есть другой софт - он под все три платформы, но я им не пользуюсь из-за его тормознутости.

dk-
() автор топика
Ответ на: комментарий от mm3

Может и так.

Сейчас проверяю как влияет размер исходных файлов.

Пока все очень линейно. Для в 2 раза меньших исходников - в два раза быстрее, и в 2 раза меньше кэшей.

Скоро узнаю как по количеству ядер.

dk-
() автор топика
Ответ на: комментарий от mm3

Но разве «не влазит в кэш» дает такой дикий оверхед, что с наращиванием количества ядер не происходит роста скорости?

Т.е. может ли одно это к такому привести?

dk-
() автор топика
Ответ на: комментарий от dk-

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

mm3 ★★★
()
Ответ на: комментарий от mm3

Это понятно. L1 - совсем общий, L2 - по ядрам, L3 - общий.

Но масштаб оверхеда просто шокирует.

dk-
() автор топика
Ответ на: комментарий от dk-

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

mm3 ★★★
()
Ответ на: комментарий от mm3

Проверил на сырье меньшего размера (18мп кадры против 36мп).

Геометрия считается ровно в 2 раза быстрее (26 кадров в минуту, против 13), оперативы выедает в 2 раза меньше (40гб против 80гб).

От «дополнительных 4 реальных ядер» (итого 16 реальных) толку нет. Можно считать на 12.

Выходит, что теоретически, если уж вдруг покупать систему под сборку этого, то нужно смотреть не на крутые 8 ядерники с НТ, а на 4х сокетную систему с 6ядерными процами без НТ (у них вроде кэши проца не обрезанные).

dk-
() автор топика
Ответ на: комментарий от dk-

Ну раз уж тут пошла содомия оффтопа - можно чем-то нормально фотки править по мелочи в линуксе? Ну, кроме гимпа, разумеется.

ekzotech ★★★★
()
Ответ на: комментарий от dk-

Оверхэд же.

Апертура понравилась - если прыщики убрать, контраст/цвет/бб поправить - очень даже.

А вайны и фотошопы - надоело уже.

ekzotech ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.