Ядерная математика

[vlkamov.livejournal.com]

538 последняя китайская новость:

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

Еще в прошлом тысячелетии суперкомпьютеры состояли из десятков тысяч процессоров. в этом наверняка больше ста тысяч будет.

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

Вместе с тем, будучи пользователем однопроцессорной машины, я не вижу у себя задач, которые без всяких конвейеров нельзя было бы разложить по тысяче менее сложных ядер. Более того, графический процессор так и сделан. И это работает. Да так, что для особо тяжелых задач охотно используют именно GPU. Наверное, при желании можно программными средствами заставить тысячу ядер всеми этими спекуляциями заниматься. Но, повторяю, не вижу в этом необходимости.

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

Вот объясните нам, блондинам, какие вообще задачи (кроме маркетинговых, конечно) требуют непременно очень сложных процессоров. И отдельно: какие задачи для персонального компьютера реально требуют сложных процессоров, а не массива простых ядер.

Comments

[dibr.livejournal.com]

Не очень понятен вопрос.

Q1) "Какие есть задачи у простого пользователя простой персоналки, которые нельзя было бы распараллелить на тысячу ядер?"
A1) Да буквально каждая первая задача у "простого пользователя" и не параллелится. Не потому что это невозможно, а потому что программисту за это никто не заплатил (такой код мало того что писать сложно, так его ведь ещё потом поддерживать придётся), проще заставить пользователя купить процессор с большей single-core производительностью.
Проверка очень простая: запускаем какую-нибудь вычислительно-ёмкую операцию (не абстрактное "перемножение матриц", а конкретное действие в конкретном фотошопе-кореле-ворде-экселе-что-там-ещё-у-пользователей-бывает), и смотрим на загрузку ядер. Если загружены все (что редко) - задача распараллелена. Если одно на 100%, остальные курят - нет.
И да, это не значит что это нельзя распараллелить. Это значит, что распараллеливанием никто не озаботился. И поэтому при апгрейде лично я по прежнему предпочту процессор с более быстрыми ядрами, а не с большим их количеством, при близкой суммарной производительности.

Q2) "Почему в суперкомпьютеры ставят тысячу сложных ядер, а не десять тысяч простых, неужели проблемы с параллелизмом?"
A2) Скорее всего нет - если задачу уже распараллелили на тысячу ядер (а другие нет смысла засовывать в суперкомпьютер), для распараллеливания на десять тысяч достаточно будет изменить одну константу (и даже перекомпилировать скорее всего не придётся). Вероятно, причина в том, что процессоры где есть "немного но сложных ядер" выпускаются настолько массово (при причинам из А1 - слишком много программ слыхом не слыхивали про параллелизм), что "флопс-на-бакс" у них оптимальнее чем у тех, где ядер больше, но они проще. Исключения - те же видеокарты (и майнинг-фермы на них: чем не суперкомпьютер?), но там сами ядра ограничены и заточены под определенные задачи, были бы они универсальными - делали бы кластеры на видеокартах, себестоимость считать все умеют.

> Наверное, при желании можно программными средствами заставить тысячу ядер всеми этими спекуляциями заниматься.

Автоматически разложить однопоточную задачу на несколько ядер, боюсь, нельзя принципиально - если бы это было можно, это бы давно сделали производители компиляторов.

"Спекуляции" либо тесно связаны с мгновенным состоянием железа ("давайте запустим эту команду на выполнение на полтакта раньше, чтобы второй операнд пришёл из кеша ровно когда он будет нужен... ой, у нас cache miss, выбрасываем результат операции и повторяем ещё разок, уже аккуратнее"), и тут программная эмуляция ну совсем не катит. Либо "давайте выполним вот эти три команды одновременно, потому что они не зависят друг от друга" - и тут теоретически спасает EPIC (явный параллелизм), например VLIW (привет Эльбрус!), но на практике с этим поигрались (в том числе Intel, в своём Itanium), и забросили: непредсказуемые задержки в железе (тот же cache miss) теперь тормозили выполнение не одной инструкции, а всего пакета, распараллеливание "на ходу" оказалось эффективнее, потому что оно видит актуальное, а не "теоретическое", состояние процессора.

[vlkamov.livejournal.com]

> конкретное действие в конкретном фотошопе-кореле-ворде-экселе

1) Это потому, что разработчиков непрямо но существенно подталкивали сделать именно такой код.
Изначально это были простые программки, которые приемлемо шевелились на простодыром процессоре с одним ядром.
И далеко ходить не надо - сам пописываю на Perl'e.

2) Запустить "действие в экселе" - это не пользовательская задача, а маркетинговая. Пользователю надо что-то посчитать, а не купить Эксель+Intel.

3) Как я уже писал, если очень хочется, можно эмулировать суперскалярный пройцессор.

4) Многоядерности увернуться не удалось, теперь все равно придется с нею считаться. И супрерскалярный забег в ширину - теперь очевидно - был не нужен пользователю.

(frozen)

[vlkamov.livejournal.com]

> Автоматически разложить однопоточную задачу на несколько ядер, боюсь, нельзя принципиально - если бы это было можно, это бы давно сделали производители компиляторов.

Достаточно сэмулировать суперскалярный процессор.

(frozen)

[vlkamov.livejournal.com]

Пошел флуд.