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

[vlkamov.livejournal.com]

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

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

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

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

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

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

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

Comments

[swizard.livejournal.com]

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

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

[vlkamov.livejournal.com]

Мы, блондины, можем допустить, что можно выдумать такую задачу, что непременно один процессор.
Но.
1) где это монте-карло находится применяется ?
2) почему без нет распараллеливаемых альтернатив ?
3) почему эти расчеты надо вести непременно на персональном компьютере ?
4) в суперкомпьютере все равно сто тысяч процессоров - там как ?

[ex0_planet]

Не все задачи тупо параллелятся.

[vlkamov.livejournal.com]

https://engineering-ru.livejournal.com/531791.html?thread=38804559#t38804559

[ex0_planet]

А еще — это я между строк у вас читаю — если посмотреть глобально с точки зрения... я не знаю, как макроэкономика только инженерия. Макроинженерии? Короче, надо учитывать, что в какой-то момент реальность вас ставит перед фактом, что сколько бы у вас не было инженеров и сколько бы у них пядей во лбу не было, они всё равно упираются в предел сложности разрабатываемых систем. Например, никто не в состоянии (пока?) спроектировать экзафлопный компьютер с параллелизмом на микроуровне. Поэтому приходится идти по проверенному десятилетиями способу пакования сложности в блоки с известными характеристиками и далее объединяя этими блоки в большее целое. Абстрагируясь то есть. И закрывая глаза на неидеальность этих блоков.

[golosptic.livejournal.com]

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

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

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

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

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

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

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

[pyka-npu3paka.livejournal.com]

криптология например, задачи с перебором

[vlkamov.livejournal.com]

В смысле криптозадачи с перебором ?

[jakobz.livejournal.com]

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

И это не говоря уже про всякие "отпарсить html и понять координаты картинок и буковок на странице".

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

[Иван Петров (from livejournal.com)]

Однако, например, задачи оптимизации вполне-себе.
Вместо всяких градиентных спусков и половинных делений - посчитать целевую функцию сразу в тысяче-другой точек и привет.

[andry-cosmos.livejournal.com]

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

[vlkamov.livejournal.com]

Это-то как раз распараллеливается не просто, а очень просто. И за примером далеко ходить не надо ;-)

[pusets.livejournal.com]

Криптография.

[viktorpetrov.livejournal.com]

Скорее, мимо. Там нужны большие вычислительные мощности, но собирать их в кластер совсем необязательно.

[once-again-abc.livejournal.com]

для решения обратных задач. например.

[iv-an-ru.livejournal.com]

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

[alj868.livejournal.com]

Программисты давно вообще ничего не стоят, они просто негодны для чего либо кроме веб аппс по доставки пиццы

Придумать параллельный алгоритм это задача для ученого

[droone.livejournal.com]

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

[vlkamov.livejournal.com]

То есть по существу вы ничего сказать не можете.

[viktorpetrov.livejournal.com]

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

[flat-area.livejournal.com]

Я вам больше скажу, сложение и умножение со времён архимеда не поменялось.
Но, это не имеет отношения к сути вопроса. Очень редко, когда в современных программах надо выполнить одно единственное вычисление. Обычно, после клика (а то и без клика вообще) нужно ПОСЛЕДОВАТЕЛЬНО выполнить расчёт, состоящий из десятков разных алгоритмов. Объекты все до единого хитрые и с отложенными вычислениями и выделением памяти. Матрицы везде хитро организованные, чтобы 99.9% нулей в них не хранить в памяти и не считать, чтобы дубликаты матриц не выделять в памяти, чтобы дублирующиеся расчёты не считать. И т. д. и т. п.

[viktorpetrov.livejournal.com]

Чтобы майнить, суперкомпьютеры не нужны вообще. И там как раз GPU (и даже более специализированные вещи) рулят.

[aso.livejournal.com]

Вообще-то ускорение работы процессоров где-то с середины 90-х обеспечивается ростом их сложности - поскольку пропускная способность памяти растёт достаточно медленно.
Усложнение: структуры процессоров - рост объёма кэша, введение кэша L3 позволяет сократить количество обращений к памяти.

[vlkamov.livejournal.com]

Вы не слышали про многоядерные процессоры ?

[agordian.livejournal.com]

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

Задач, которые нельзя ОПТИМАЛЬНО разложить на матрицу простеньких вычислительных ядер, масса. Это все задачи, завязанные на время. Если результат следующего шага вычислений зависит от предыдущего, на матрицу такой алгоритм ляжет только в виде конвейера. К слову, конвейер - вполне себе способ параллельных вычислений, условно говоря, "параллелизм по времени", а не по пространству. Матричный вычислитель однозначно хорош только там, где можно разбить задачу на кусочки, независимые друг от друга по данным. Например, тупой пересчет единичного кадра. Но вот от кадра к кадру - опять тот самый конвейер.

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

[vlkamov.livejournal.com]

> Массив простых ядер как раз технологически более сложная сущность.

100 тысяч "сложных" процессоров точно так же.

[flat-area.livejournal.com]

Более-менее сложные программы очень тяжёло распараллелить.
Всё, что в 100 строк параллелится легко.
Хрен вы сделаете то же самое с программой в 1000000 строк, где сотни задач взаимосвязаны друг с другом и выполняются последовательно, где используются тысячи классов, которые нельзя обвесить мьютексами на каждый метод, которые в ходе вычислений создаются, разрушаются и взаимодействуют в миллиардах комбинаций.

Это то же самое, что думать, что большую ракету для отправки космонавтов на МКС можно сделать такой же простой и дешёвой, как фейерверк.

[swizard.livejournal.com]

> Всё, что в 100 строк параллелится легко.

Довольно смелое утверждение :)

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

[lx-photos.livejournal.com]

Что такое 538?

[vlkamov.livejournal.com]

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B5_%D0%BA%D0%B8%D1%82%D0%B0%D0%B9%D1%81%D0%BA%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%83%D0%BF%D1%80%D0%B5%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5

[kote-iosif.livejournal.com]

а правда что его строят на самой большой в мире микросхеме Эльбрус ?
8-ядерный серверный процессор с архитектурой «Эльбрус» производства российской компании МЦСТ[1]. Опытный образец был разработан в 2014 году. В 2016 году планировалось серийное производство.[2][3] Дизайн процессора расчитывался для решения высокопроизводительных задач. Заявленная производительность процессора равна 250 гигафлопс операций с числами с плавающей точкой.

[0x8.livejournal.com]

Принципы работы GPU сильно отличаются от работы CPU. В GPU все ядра выполняют одну и ту-же операцию, но над разными данными. Т.е. все делают A*B, только значения A и B у всех ядер свои.
В CPU каждое ядро выполняет свои команды. Одно что-то умножает, другое в это время переход по адресу делает и т.п. Соответственно, если у вас в алгоритме нет синхронных повторяющихся блоков, то CPU сильно быстрее.

Второе цена ветвления. Когда у вас алгоритм:
Если (A < 10)
То
B = A * 5
Иначе
B = A - 3

То у вас есть ветвление. Иногда исполнение идет по одной ветке, иногда по другой. CPU намного лучше выполняют ветвление. GPU вынужден обсчитать ОБЕ ветки и потом хитрым образом объединить результат. CPU может выполнить только одну ветку, и еще пытается предсказать по какой ветке пойдет исполнение.

Переход по адресу CPU обрабатывает лучше (обычно). Т.к. у него меньше потери скорости на перезаполнение конвеера. У GPU конвеер обычно длиннее.

[vlkamov.livejournal.com]

К сожалению пример с GPU не позволил понять суть дихотомии. Отвлекает.

Попробуйте все же абстрагироваться от набора команд.

[redneck-prm.livejournal.com]

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

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

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

да большинство, за исключением обработки видео/3д да всякой экзотики типа майнинга и обучения нейросеток.
закон амдаля никто не отменял, и даже задачи с 75% параллельного кода скукоживаются на 8 ядрах.

[vlkamov.livejournal.com]

> большинство

Я спрашивал не "сколько", а "какие".

[terleev.livejournal.com]

Пример огромных расчетов: каждый крупный банк в Лондоне считает риск всю ночь и если серверная встанет, то утром банк откроется лишь номинально: ни один кредит не одобрят, ни крупные платежи не проведут — потому что они влияют на модель. Если еще были overnight intrabank займы, то вообще пипец. 8 часов это минимальный расчет. Почему? Потому что обычно считают порядка 10000 повторений Монте-Карло, навешивают на это кучу всего. Моя дипломна работа состояла из подбора одной из 8 моделей, подбора по 3-4 коэфициента к каждой, подбор портфолио из FTSE 100 и потом проверки не навернется ли это всё на диапазоне пять лет назад. Каждый пересчет диплома занимал 8 часов на одном ядре. Если опечатка в коде, то сидишь дальше ковыряешься в сети на оставшихся трех ядрах, смотришь Олимпиаду (2012). Я так в лаборатории по 50 часов за раз сидел. Ох как хотелось чтобы универ купил многоядерный модуль для матлаба.

[vlkamov.livejournal.com]

> хотелось чтобы универ купил многоядерный модуль

То есть задача распараллеливаема ?

[woodenfriend.livejournal.com]

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

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

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

[vlkamov.livejournal.com]

У всех так рассуждающих общая ошибка. Две:
1) Такие задачи немассовые, специальные.
2) Когда в машине 10 тысяч процессоров, какими бы они ни было, все указанные все равно придется решать.

[teewoon.livejournal.com]

Например рендеринг страниц хреново параллелится =)

[vlkamov.livejournal.com]

:-)

[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) Многоядерности увернуться не удалось, теперь все равно придется с нею считаться. И супрерскалярный забег в ширину - теперь очевидно - был не нужен пользователю.

[belousov-ilia.livejournal.com]

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

Рекомендую ознакомиться:
https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0 (https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%90%D0%BC%D0%B4%D0%B0%D0%BB%D0%B0)

Так наглядно чем один мощный процессор лучше пучка простых параллельных?

[vlkamov.livejournal.com]

> Правильный ответ - любые.

- это ложь.

> параллелить стали, потому, что производительность одноядерных процессоров упёрлась в потолок.
> один мощный процессор лучше пучка простых параллельных

Потому что до потолка достает.