Приветствую!

Прошу помочь понять и осмыслить экспериментальные данные.

Задача:
Понять каков оптимальный конфиг железа при сшивке т.н. гигапиксельных панорам (для меня это важно).

Коллега любезно предоставил для теста такую машинку:
Supermicro X9DRi-F + 2 шт E5-2660 + 128gb

Мы гоняли разные тесты на основании сырья снятой мною в прошлом году панорамы. 684 кадра по 18 или 36мп.

Термины:
Warp — именно работа с геометрией, именно сшивка кадров;
Blending — выравнивание цвета и яркости по всему полю из всех жипегов.

Результаты такие:
0. 36мп исходники пережевываются ровно в 2 раза быстрее, чем 18мп исходники;

1. Включение НТ — дает проседание скорости варпа на 15-20% (для любого количества ядер);

2. И для 18мп и для 36мп исходных кадров скорость варпа на 12 (2х6) или 16 (2х8) ядрах — совершенно одинаковая, +2 ядра на процессор не дают никакого прироста, -2 ядра на процессор не дают никакого проседания;

3. Дальнейшее уменьшение числа активных ядер уже приводит к падению скорости варпа;

4. Загрузка процессора (по условным процентам диспетчера задач) никогда (!) не доходит до 100%, пики на 90%;

5. Оперативная память на стадии варпа полностью не выедается: для 18мп исходников — в пике занято 35-40гб из 128, для 36мп исходников в пике занято 75-90гб из 128;

6. Обращения к накопителю не особо впечатляют. Довольно быстро записывается кэш в 26 или 53гб (для 18 и 36мп сырья, соответственно). Это соразмерно будущему результирующему файлу. Затем, в течение получаса или часа записывается примерно 15гб кэшей, и считывается примерно 10гб. Т.е. упираться в производительность дисковой подсистемы негде. К тому же там чередующийся рейд из 4 дисков;

7. Ну а на стадии блендинга оперативная память выедается моментально и вся сразу. И сотни гигабайт кэшей пишутся\читаются. А загрузка процессора не выше 4-8%.

Вопросы:
1. Логично ли мое предположение о том, что все упирается в кэши процессоров? Или дело может быть в чем-то другом?

2. При отключении двух ядер весь процессорный кэш распределяется между оставшимися шестью? Или часть кэша тоже простаивает?

3. Что логичнее: и дальше собирать систему на 8-ядерниках, но работать только на 6 ядрах или сразу брать 6-ядерные процессоры? Но тут нюанс, L2 кэш «на ядро» у 6 и 8 ядерных процессоров одинаковый.

Добавлено спустя 6 часов 31 минуту 46 секунд:
Что-то я не нашел кнопку редактирования темы.



Ошибка, конечно же

36мп - в 2 раза Медленнее, чем 18м.

Еще данные:

При отключении ядер или уменьшении числа потоков (софтово) частота работы процессора неизменна. она всегда ровно 2200мгц. Странно. Но я хз почему так. Турбобуста нет.

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

Еще попробуем вытащить один процессор. И посмотреть на масштабируемость.

Так и должно быть. Почему в ырешили, что при отключении ядер должна увеличиваться частота?

Добавлено спустя 4 минуты 39 секунд:

Кэш общий. Сколько ядер включено, стольким ядрам он доступен один на всех

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

Это вывод исходя из чего? Есть такие понятия как время отклика, частота обращения и тд ...
Я бы на вашем месте тестил какой-нить файлик в 10МП в рамдиске, чтобы найти ответы относительно ЦП, кэша и рейда

Добавлено спустя 10 минут 2 секунды:

Очень может быть иначе

не может: http://ark.intel.com/ru/products/64584в скорость обращения к оперативной памяти уперлись

На основе чего вывод?

естественно при условии, что дисковая подсистема не является в данной системе тем самым узки местом. в общем кэш процессора не может быть узким местом потому что изначально у всех процессоров кэш быстрее чем скорость обращения к ОЗУ, так что почти во всех современных системах данное место и является ограничивающим фактором. К.О.

Думаешь н хватет скорости копирования 8+ГБ/с, а записи где-нить 5+ГБ/с. Задержка же небось не больше 100нс.

Аффторитет
не понял тебя. скорость обращения к ОЗУ у данного процессора 51 Гб/с, и именно ее не хватает. процессор потому и простаивает - не успевает загрузиться нормально из-за того что из памяти вытаскивает мало данных для обработки. по сути он всего 20 гигабайт в секунду успевает прожевать и обратно в память записать...

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

Это типа мало для его задач?

Аффторитет
типа для конкретно этой задачи - мало, а для варпа который до этого проводится - достаточно, потому что алгоритм сложнее и он обрабатывает данные медленнее, чем может их считать из ОЗУ, хотя и там вон говорят на 100% не грузится, но это может быть какой-то механизм в ОС не дающий все ресурсы процессора занять и оставить для каких-то штатных задач ресурсы.

Как высчитал?

Блендинг упирается в скорость обмена с диском. Т.к. там сотни гигабайт кэшей пишутся и читаются. А любое количество оперативы выедается полностью на 100%.

localhostroot
так о том и писал же, что память полностью забивается, а процессор не загружен.

Завтра попробуем вытащить один процессор и еще раз проверить.
Как будет масштабироваться. Если просядет ровно в 2 раза, и тенденция 6\8 ядер останется прежней, то линка между процессорами хватает значит.

Касательно сырья на рамдиске - в этом мало смысла.
Оно вычитывается всего один раз. Потом исходные жипеги хоть удаляй нафиг.
Софт работает со своими кэшами на накопителе.

Хотелось бы, конечно, ссд. Но ТАКИХ ОБЪЕМОВ (терабайты, при планируемой панораме на 6000 исходных кадров по 36мп) не напасешься.

localhostroot
между процессорами точно хватит, почитайте, в этом поколении уже проблему решили Интел с каналом между процессорами.

Ну тем лучше.
Но для успокоения все равно проверим.

Вопрос:
Какие-то еще тесты вам кажутся логичными?

Пока мой вывод такой:
Для сферической в вакууме системы под сшивку гигапикселей нужно 4 сокета и процессоры без НТ.
Только вот какие процессоры... 8 ядерные с отключенными 2 ядрами, или сразу 6 ядерники без НТ.
Ну и слотов под раму в такой системе 32 может быть, что радует.

localhostroot А чего бы не кинуть рамдиск под кэш софтины?

localhostroot
чем выше обеспечите пропускную способность до памяти - тем быстрее будет идти обработка, конечно, при условии что вы сможете все данные запихнуть в ОЗУ.