Легенды говорят, что интегрированное видео существенно влияет на общую производительность системы, поскольку соревнуется с процессором за доступ к видеопамяти. То есть видеоподсистема постоянно пользуется северным мостом, что замедляет общение процессора с памятью через этот же северный мост. Если провести аналогию с дорожным движением, то встроенное видео — это светофор на магистрали — существенно снижает пропускную способность, даже если по второстепенной дороге трафик незначительный.
Собственно вопрос — эта легенда сегодня имеет под собой реальные основания? Если да, то прошу поделиться ссылками на более-менее авторитетные источники.

С практической точки зрения вопрос можно переформулировать так: если на компьютере планируются интенсивные (в том числе по доступу к памяти) вычисления без использования видеокарты, то стоит ли тратиться на дискретную видюху или встроенная не повлияет на скорость вычислений? Задачи числодробительные. Компьютер может простоять пару недель при 100% нагрузке всех ядер и 90% заполненности памяти.

Это ведь дегко проверить: бенчмарк памяти + переключение видюх с перетыканием кабеля. Но я проверять не буду, мне лень ребутаться...

M>Легенды говорят, что интегрированное видео существенно влияет на общую производительность системы

Именно так.

M>, поскольку соревнуется с процессором за доступ к видеопамяти.

Это не единственная и зачастую не самая главная причина. Куда важнее тепло, выделяемое встроенным видео. Оно идёт в "общий зачет" и греет чип. При перегреве чипа (или при превышении тока потребления) процессор будет сбрасывать частоты -> работать медленнее.

M>С практической точки зрения вопрос можно переформулировать так: если на компьютере планируются интенсивные (в том числе по доступу к памяти) вычисления без использования видеокарты, то стоит ли тратиться на дискретную видюху или встроенная не повлияет на скорость вычислений? Задачи числодробительные. Компьютер может простоять пару недель при 100% нагрузке всех ядер и 90% заполненности памяти.

Задачи работают чисто на CPU? Без GPGPU (openCL)? Тогда видеоядро будет простаивать -> ничего не потреблять и никуда не лезть. Разницы в скорости работы CPU не будет.

PS: не забудьте организовать адекватное охлаждение, а то и без всякого GPU процессор будет перегреваться и сбрасывать частоты.

Здравствуйте, ononim, Вы писали:

O>Это ведь дегко проверить: бенчмарк памяти + переключение видюх с перетыканием кабеля. Но я проверять не буду, мне лень ребутаться...

Нет железа подходящего.

Здравствуйте, SkyDance, Вы писали:

M>>Легенды говорят, что интегрированное видео существенно влияет на общую производительность системы

SD>Именно так.

M>>, поскольку соревнуется с процессором за доступ к видеопамяти.

SD>Это не единственная и зачастую не самая главная причина. Куда важнее тепло, выделяемое встроенным видео. Оно идёт в "общий зачет" и греет чип. При перегреве чипа (или при превышении тока потребления) процессор будет сбрасывать частоты -> работать медленнее.

Есть где-то публикации на эту тему? Подойдёт даже пост в блоге или форуме.

M>>С практической точки зрения вопрос можно переформулировать так: если на компьютере планируются интенсивные (в том числе по доступу к памяти) вычисления без использования видеокарты, то стоит ли тратиться на дискретную видюху или встроенная не повлияет на скорость вычислений? Задачи числодробительные. Компьютер может простоять пару недель при 100% нагрузке всех ядер и 90% заполненности памяти.

SD>Задачи работают чисто на CPU? Без GPGPU (openCL)? Тогда видеоядро будет простаивать -> ничего не потреблять и никуда не лезть. Разницы в скорости работы CPU не будет.

Мигание курсора на экране разве не требует хождения до видео памяти?

SD>PS: не забудьте организовать адекватное охлаждение, а то и без всякого GPU процессор будет перегреваться и сбрасывать частоты.
Это очевидно.

Здравствуйте, SkyDance, Вы писали:

SD>Задачи работают чисто на CPU? Без GPGPU (openCL)? Тогда видеоядро будет простаивать -> ничего не потреблять и никуда не лезть. Разницы в скорости работы CPU не будет.

60 раз в секунду прочитать 8MB статической картинки 1920x1080x24 (4 байта на пиксель) для генерации видеосигнала — 480MB/s — вполне сравнимо с тем, что от памяти хочет процессор при активной работе...

Здравствуйте, netch80, Вы писали:

N>60 раз в секунду прочитать 8MB статической картинки 1920x1080x24 (4 байта на пиксель) для генерации видеосигнала — 480MB/s — вполне сравнимо с тем, что от памяти хочет процессор при активной работе...

во-первых 3 байта на пиксель, зачем четыре для статики? это ~356MB/s, а во-вторых с какой памятью? может c SSD? потому что активная работа с RAM сегодня на пк это порядка 20Gb/s

Здравствуйте, antropolog, Вы писали:

N>>60 раз в секунду прочитать 8MB статической картинки 1920x1080x24 (4 байта на пиксель) для генерации видеосигнала — 480MB/s — вполне сравнимо с тем, что от памяти хочет процессор при активной работе...
A>во-первых 3 байта на пиксель, зачем четыре для статики?

Оно обычно таки хранит по 4 (для выравнивания)

A> это ~356MB/s, а во-вторых с какой памятью? может c SSD? потому что активная работа с RAM сегодня на пк это порядка 20Gb/s

Это в сферических в вакууме условиях со всеми оптимизированными до предела алгоритмами для потоковой обработки, или на операциях типа "mov ecx,-1; lodsb". Как только мы выходим на произвольный доступ к разным строкам, скорость падает в сотню раз.

N>60 раз в секунду прочитать 8MB статической картинки 1920x1080x24 (4 байта на пиксель) для генерации видеосигнала — 480MB/s — вполне сравнимо с тем, что от памяти хочет процессор при активной работе...

Даже если предположить, что GPU зачем-то читает весь фреймбуфер, и реально нужно не только прочитать, но и всё это записать, получится меньше 1 гб/с. Минимальная пропускная способность DDR3-800 — примерно 6.5 гб/с. Для более распространенного случая (двухканальная DDR3-1600) будут цифры порядка 26 гб/с.

В реальности этого не происходит просто по той причине, что фреймбуфер в существенном объеме кэшируется в GPU. А для графики Iris Pro и вовсе целиком сидит в eDRAM на GPU.


Понять бы еще, что за вычислительная задача будет гоняться. Мне неизвестна ни одна задача, которая бы упиралась в память, за исключением архивации/разархивации, и то только с условием, что все данные сидят на RAMDrive'е.

Здравствуйте, SkyDance, Вы писали:

SD>Понять бы еще, что за вычислительная задача будет гоняться. Мне неизвестна ни одна задача, которая бы упиралась в память, за исключением архивации/разархивации, и то только с условием, что все данные сидят на RAMDrive'е.

Да много таких задач. Даже так: если цикл можно ускорить, развернув его, то задача упирается в память. Или в случае, когда кеширование ускоряет — тоже память.
В качестве примера — практически любой алгоритм обработки видео. Машинное обучение тоже. Много всего.

N>Да много таких задач. Даже так: если цикл можно ускорить, развернув его, то задача упирается в память. Или в случае, когда кеширование ускоряет — тоже память.
N>В качестве примера — практически любой алгоритм обработки видео. Машинное обучение тоже. Много всего.

Тредстартер написал, что полный расчет задачи займёт пару недель. Это точно не видео — там в дисковое i/o упрется.

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

В общем, моё мнение таково — GPU не повлияет. Куда важнее частоты и правильное использование boost'а (чтобы все ядра бустились, а не как по умолчанию одно).

Здравствуйте, SkyDance, Вы писали:

SD>Тредстартер написал, что полный расчет задачи займёт пару недель. Это точно не видео — там в дисковое i/o упрется.

Ну, видео как раз может: всякий motion estimation по ключевым точкам (тот же SIFT), structure from motion, 3D from stereo, density optical flow. Есть множество задач, которыми можно нагрузить.

Можно взять машинное обучение: тренировка нейросетей, каскады Хаара AdaBoost'ом...
Я для тренировки одного каскада на месяц арендовал сервер на digital ocean. Обучалось недели две: там сначала характеристики из изображений извлекаются, а после (в память они помещаются) обучаются каскады.

SD>В общем, моё мнение таково — GPU не повлияет. Куда важнее частоты и правильное использование boost'а (чтобы все ядра бустились, а не как по умолчанию одно).

С этим полностью согласен.

Здравствуйте, netch80, Вы писали:

N>Оно обычно таки хранит по 4 (для выравнивания)
"оно" это кто? зачем выравнивание для статической картинки, которую нужно просто отобразить как есть?

N>Это в сферических в вакууме условиях со всеми оптимизированными до предела алгоритмами для потоковой обработки, или на операциях типа "mov ecx,-1; lodsb". Как только мы выходим на произвольный доступ к разным строкам, скорость падает в сотню раз.

зачем произвольный доступ для отображения ( напомню, речь идёт о простом отображении 60 кадров в секунду full hd) фреймбуфера? Это простая ( можно даже сказать тупая ) задача для RAMDAC ( или как оно сейчас называется, учитывая что аналогового сигнала нет) и контроллера памяти, CPU как арифметико-логическое устройство здесь не задействуется совсем. Т.е. фактически контроллер задействует порядка 2% пропускной способности памяти, на перформансе это не сказывается практически никак ( условно можно считать, что скажем ddr1600 превращается в ddr1566 ).

N>Ну, видео как раз может: всякий motion estimation по ключевым точкам (тот же SIFT), structure from motion, 3D from stereo, density optical flow.

Эти задачи очень хорошо локализованы по памяти — большинство данных будет браться из процессорного кэша. Пропускная способность неподсредственно памяти будет играть небольшую роль (и то скорее по latency, чем по throughput).

N>Можно взять машинное обучение: тренировка нейросетей, каскады Хаара AdaBoost'ом...

И даже тут локальность данных позволит не сильно заморачиваться пропускной способностью памяти.
Хотя, согласен, это одна из самых ярких memory-intensive задач. Допускаю, что на такой разница в 10% пропускной способности памяти уже можно будет обнаружить. В любом случае, такие задачи намного больше выиграют от высокочастотной памяти с низкими задержками.

А, вот еще что вспомнил. Для таких высокоинтенсивных задач применять обычную память попросту стрёмно. Я бы сказал, что без ECC допустимо применять лишь только в том случае, если полученные на предыдущей итерации данные не идут в следующую. Вот тут полезная статья

Здравствуйте, SkyDance, Вы писали:

SD>А, вот еще что вспомнил. Для таких высокоинтенсивных задач применять обычную память попросту стрёмно. Я бы сказал, что без ECC допустимо применять лишь только в том случае, если полученные на предыдущей итерации данные не идут в следующую. Вот тут полезная статья

Ну, для таких обычно сервера или рабочие станции с ECC и используют. В принципе, можно запускать расчёты в двух экземплярах, а после ожидать побитовую идентичность результатов.

Здравствуйте, antropolog, Вы писали:

A>"оно" это кто? зачем выравнивание для статической картинки, которую нужно просто отобразить как есть?
Так видяхи устроены. 24-битные поверхности на самом деле 32-битные. Выравнивание — это сила.

A>зачем произвольный доступ для отображения ( напомню, речь идёт о простом отображении 60 кадров в секунду full hd) фреймбуфера? Это простая ( можно даже сказать тупая ) задача для RAMDAC ( или как оно сейчас называется, учитывая что аналогового сигнала нет) и контроллера памяти, CPU как арифметико-логическое устройство здесь не задействуется совсем. Т.е. фактически контроллер задействует порядка 2% пропускной способности памяти, на перформансе это не сказывается практически никак ( условно можно считать, что скажем ddr1600 превращается в ddr1566 ).
Любая задача, будучи "посажена" на память, станет аццки медленной, ибо скорость CPU НАМНОГО больше скорости самой быстрой памяти, и разработчиков, придумавших такой алгоритм, нужно выгнать за профнепригодность. Грамотно реализованные алгоритмы редко упираются в скорость памяти — по крайней мере я таких не встречал (если не считать графики — там запросто можно упереться в скорость контроллера видеопамяти, ибо его уж очень любят резать для "производства" более дешёвых модификаций видеочипов).
А "ddr1600" — это вообще что?

Здравствуйте, koandrew, Вы писали:

K>Так видяхи устроены. 24-битные поверхности на самом деле 32-битные. Выравнивание — это сила.
я ещё раз повторю, речь идёт об отображении фреймбуфера. Никаких поверхностей там нет и в помине. Это просто растр который надо отобразить 60 раз в секунду.

K>Любая задача, будучи "посажена" на память, станет аццки медленной, ибо скорость CPU НАМНОГО больше скорости самой быстрой памяти, и разработчиков, придумавших такой алгоритм, нужно выгнать за профнепригодность. Грамотно реализованные алгоритмы редко упираются в скорость памяти — по крайней мере я таких не встречал (если не считать графики — там запросто можно упереться в скорость контроллера видеопамяти, ибо его уж очень любят резать для "производства" более дешёвых модификаций видеочипов).

сказано очень много правильных слов, только абсолютно не относящихся к обсуждаемой теме. речь идёт об отображении фреймбуфера. Здесь CPU не задействовано совсем.

K>А "ddr1600" — это вообще что?
это тип памяти

Здравствуйте, Mazay, Вы писали:

M>Собственно вопрос — эта легенда сегодня имеет под собой реальные основания? Если да, то прошу поделиться ссылками на более-менее авторитетные источники.

На ixbt несколько раз были такие тесты. Конкретные ссылки ищи сам.

А зачем на вычислительном сервере какая-либо графика? Поставьте туда линукс и по ssh заходите.

Здравствуйте, AndrewVK, Вы писали:

M>>Собственно вопрос — эта легенда сегодня имеет под собой реальные основания? Если да, то прошу поделиться ссылками на более-менее авторитетные источники.

AVK>На ixbt несколько раз были такие тесты. Конкретные ссылки ищи сам.

Не получается составить релевантный запрос. Всякий шлак в поисковой выдаче.