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

[vlkamov.livejournal.com]

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

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

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

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

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

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

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

Comments

[golosptic.livejournal.com]

Привожу пример задачи (из переписки с одним из коллег)

"... - это такой большой проект в рамках European Bioinformatics Institute - мы занимались созданием европейского геномного браузера и порождением данных для него. А данных там очень много, и они обновлялись примерно 5 раз в год (быстрее мы на всех своих кластерах обсчитать не успевали)
....
короче говоря, у нас есть кубики, из которых можно составлять распараллеленные пайплайны

есть язык, при помощи которого мы описываем взаимодействие этих кубиков

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

В приложении, для которого изначально создавался ...., поток управления может очень широко разветвляться (после одной “нити” может потребоваться несколько миллионов не зависящих друг от друга ниточек), которые могут потом снова утоньшаться несколько раз (независимо - каждая ниточка сама локально принимает это решение), а потом собираться обратно, и наконец мы в конце снова получаем single control thread.

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

Ну то есть вышеприведённое описание - это про некие информационно-поисковые и исследовательские операции над очень большой геномной базой. Параллельное вычисление есть, а массово-параллельное (на тех же GPU) получается сделать очень не всегда, т.к. логика каждой нити вычисления своя. Вот тут процессор общего назначения начинает выигрывать у GPU.