Re[8]: палко-часы и цп или поджарить попугаев
От: Evgeny.Panasyuk Россия  
Дата: 22.05.15 07:31
Оценка:
Здравствуйте, SkyDance, Вы писали:

EP>>Видеокарты (и GPGPU в частности) выигрывают в том числе за счёт того что у их памяти throughput на порядок больше чем у памяти CPU.

SD>Так у видеокарт тысячи потоковых процессоров. А не единицы.

У видеокарт два больших преимущества: много FLOP/s (да и вообще OP/s) и много memory throughput. Необходимость программировать тысячи вычислительных единиц в виде десятков тысяч потоков (причём частично зависимых друг от друга — warps и blocks) — это минус, а не плюс.
Так вот, с CPU на GPGPU переносят в том числе и алгоритмы которые упираются в throughput (а не в OP/s), как раз потому что этого throughput и не хватает.

EP>>Например памяти столько, что в неё всё-всё помещается — и её добавление уже ничем не поможет

SD>Вот именно это условие никогда не удовлетворяется при запуске "много виртуальных машин". Я много лет работаю с виртуализацией серверов, и уж поверьте, самое важное в этом деле — объем памяти (и IOPS/sec дисковой подсистемы — суть обязательное наличие SSD).

Охотно верю. Я не говорил что объём не важен.

EP>>Разница в memory read (тот самый throughput) между DDR3-2933 и DDR3-1600 — 30%. На фоне того что там есть(?) какие-никакие вещественные вычисления, которых нет во многих задачах — 9% как раз и показывают что скорость памяти влияет существенно.

SD>Так а я что написал? Что в лучшем случае можно получить 9% выигрыш на задачах без I/O. Это попросту не заметить в домашнем применении.

9% (а в некоторых тестах по той ссылке до 25%) при 30% увеличении throughput, и это только при увеличении частоты. Ты же изначально говорил ещё и про каналы памяти.

SD>А вот тормоза от 3-4 виртуалок, которые свопятся, видны будут самым что ни на есть невооруженным глазом.

EP>>А я не говорил что нужно ставить меньше памяти до такой степени что начнётся I/O.
SD>Виртуалки ведут постоянный I/O.

У меня есть VM в которой практически никакого I/O кроме линейного начального — на ramdisk распаковывается всё что нужно, и прям там же выполняется сборка.

SD>И я не говорил про нехватку памяти до свопа. Даже без этого — дисковое кэширование куда эффективнее при наличии большого количества свободной памяти.


А я специально говорил про любое I/O, а не только swap, в том числе и то I/O которое от нехватки памяти под дисковый кэш. Даже сборку больших проектов нетрудно полностью уместить в современные объёмы RAM.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.