Комментарии 64
Но ведь команды вычислений тоже должны передаваться по шине. В каких ситуациях вообще будет прирост скорости?
В ситуации когда код редко меняется. Залил туда небольшую функцию, а потом как simd, запросил кучу операций, и получил кучу результатов.
вычисление каких-то больших матриц, например. процессор залил в модуль подпрограмму, пнул, и пошел заниматься своими делами дальше, когда досчитало, ему прилетело прерывание, забираем результат. меня другое волнует: вот сейчас ошибки в процессорах уже стоили нам уязвимостей(Meltdown, Spectre). если память станет что-то вычислять - не получится ли так, что мы откроем дорогу еще более интересным глюкам?
Команды вычислений и не надо передавать, в логическом слое находится ALU + мультиплексоры. В адресе выборки пару-тройку бит отводишь на то, с какого выхода ALU мультиплексор будет отбирать данные на шину данных. Предположим, на ALU на 2 входа приходят данные разрезанные на 2 части (либо режем линию пополам, либо используя адресацию данных по восходящему и нисходящему фронтам импульса синхронизации (+ опционально на один из входов можно подать с шины данных), на выходе из ALU имеем результат операции: суммирование, вычитание и т.п., дальше через мультиплексоры забираем тот результат, который нужен. Т.е. кодируя в адресной шине адрес линии + код операции, можно чтением забирать из такого блока памяти не только значение из RAM, но и уже примененную операцию к этим данным.
В ситуациях, когда вычисления упираются в шину памяти. Основной боттлнек сегодняшних систем это память. PIM на самом деле несколько разных есть. Самый тупой вариант - поставить на сам модуль самый обычный CPU/ASIC/FPGA. Чуть хитрее - логику можно засунуть в сами банки памяти отдельным слоем. Тут можно гонять сложные программы вроде машинного обучения. Самый хитрый - реализовать логику посредством самих аналоговых ячеек. Можно реализовать простые гейты и делать что-то очень простое вроде обнуления памяти.
Следующий шаг - добавление небольших ПЛИСин в модули памяти?
Становятся мейнстримом — слишком громко сказано. Под это уже можно программировать и можно где-то купить?
Например Alveo с HBM уже пару лет доступны простым смертным, так что можно.
А что простые смертные с ними могут делать? Где-то есть примеры кода для людей?
А что простые смертные с ними могут делать?
Акселераторы для датацентров и свои приложения для акселераторов.
Насчёт примеров прям кода не найду, но там обычный VHDL/Verilog можно юзать. Юзкейсы можно глянуть тут и тут. По сути с точки зрения программиста там жирная плисина с 32 внутрикристалльными AXI-интерфейсами на HBM.
Правильно ли я понимаю, что это память со встроенным вычеслительным процессором?
При вызове функции (подпрограммы, смене потока, прерывании) все эти регистры нужно сохранять в стек.
А стек выталкивается в память.
И вот, например, для рекурсивного вызова простейшей функции тратится количество памяти, кратное не только глубине рекрсии, но и количеству регистров.
А современный софт это же вызовы на потоках и прерываниями погоняют.
Но я работаю только с маленькими контроллерами, поэтому могу заблуждаться. Больно смотреть в листинге отладчика, как процессор тратит по 3...4 машцикла на загрузку-сохранение каждого очередного операнда…
Слишком частые вызовы подпрограмм… Ну что же, у разработчиков компиляторов будет стимул поправить алгоритмы компиляции, а у программистов — использовать итеративные циклы вместо рекурсивных.
А как их подправить? inline уже давно используется, и компиляторам и так приходится находить баланс между кучей call'ов или раздуванием кода inline'ом. С точки зрения прикладных программистов, остерегаться call'ов глупо - это базовая инструкция лет 50 уже, которая должна просто работать.
использовать итеративные циклы вместо рекурсивных
Кому нужен процессор, криво поддерживающий рекурсию? Она не так уж часто нужна, но тем не менее.
И сколько вы собрались их добавить? Память в гигабайтах и терабайтах исчисляется. Самая банальная задача, на которую уходит дофига энергии и времени в датацентрах - занулить или скопировать страницу памяти. Увеличение числа регистров никак это не решит, даже если их там под 4КБ будет.
Забавная ситуация: если раньше процессор имел свою память (кэш), то теперь и память будет иметь свой процессор. Так почему бы на очередном витке развития железа не интегрировать пооцессор с памятью в одну структуру? При достаточной ширине шины можно совсем обойтись без кэша?
Потому что памяти надо много и разного объема, хочется иметь возможность ее менять. Часть может быть даже не по DDR шине подключена. Память сейчас потихоньку уже суют в процессор, но скорее как еще один элемент иерархии кэшей. Sapphire rapids от интела может HBM на борту. Амд смогли сделать огромный кэш под гигабайт примерно для тех же целей.
А смысл кэшей не только в шине. Задержки у памяти намного выше в любом случае.
если раньше процессор имел свою память (кэш), то теперь и память будет иметь свой процессор
"... и так продолжается это вращение,
пока не поглотит всё вязкое трение"
Уже.
M1 -:)
Хотя реально следующий этап скорее:
- процессор с кучей кешей,
- память с кучей слабых in-order процессоров и без кешей.
- сетевая карта со своими процессорами и линуксом
…
и статьи на хабре "как добится ускорения в x375 если купить память от <название_фирмы_в_чьем_корпблоге_это_опубликовано>", с комментариями что устанешь это программировать и вообще из Electron'а до этого не достучатся, а доступ из натива поддерживается только бинарным блобом под который работает только под Windows 15 и вообще проще поставить GPU помощнее где примерно тоже самое — уже стандартизовано.
M1 ничего не интегрировал. Это самый обыкновенный процессор, в котором сохранена обычная иерархия кэшей и память находится отдельно сбоку на обычной DDR шине. Единственное отличие это общее адресное пространство у всех ядер процессора, что тоже в общем-то не инновация - такие процессоры давно выпускают и по сей день применяют в тех же игровых консолях.
Засунули на одну сборку. Увеличив скорость. Да, не на один кристалл но пока хоть так.
Увеличив количество каналов. Для APU выглядит интересно (хотя игровые консоли давно такими цифрами могут похвастать в рамках того же самого унифицированного по памяти дизайна), но в глобальном масштабе ничего принципиально нового. Эпл здесь проще, потому что все эти каналы не надо вести через материнку со всеми этими сопутствующими проблемами. Это всегда было преимуществом дизайна без возможности переконфигурации.
Т.е. теперь ещё и на памяти вентилятор будет?
:)
Не совсем понятно, какие операции сможет производить эта память (сложение, перемножение, умножение на константу?), и между какими операндами.
Зависит от реализации. Если PIM построена на процессорах общего назначения, то что угодно. Как вот это например https://www.upmem.com/technology/ RISC процессор в каждом чипе памяти, СДК, си, раст.
Если все нормально (сильно сомневаюсь), то давайте просто перенесем динамическую память в процессор.
Думаю оптимальнее будет HBM с большой шириной данных и вот такой DSM контроллер ( habr.com/ru/post/577810 ) с интерфейсом от 100Тбит в секунду.
Не такой уж большой недостаток, вск-таки память редко когда добавляют/меняют.
Это если речь о ноутбуках может быть, а статья касается серверов. Там это просто невозможно представить. Мало того, что объем везде разный, скорость. Так еще появляются новые интерфейсы помимо DDR и персистентная память.
Эти решения уже работают, так что нормально себя чувствует, видимо. Переносить память в процессор смысла нет. Много там не разместишь и память все равно должна быть чем-то, что можно заменить в любой момент, а не привязывать к модели конкретного процессора. И все равно это станет просто еще одним уровнем кэшей. HBM для этих целей уже скоро начнут ставить на CPU.
Ваш DSM выглядит как то, что сейчас уже сделали в CXL/GenZ - когерентный доступ к памяти между разными процессорами в масштабах датацентра. Это не решает глобальной проблемы, для которой придумывали PIM - постоянном хождении данных по шинами, что жрет больше энергии, чем сами вычисления. Никакие контроллеры это не решают. Толстая шина ничего не даст - она будет жрать сотни ватт и задержками угробит весь перформанс.
Это не решает глобальной проблемы, для которой придумывали PIM — постоянном хождении данных по шинами
Решить эту проблему полностью, PIM не сможет. Если данные не будут ходить между процессором и памятью, то и процессор не будет ничего вычислять.
Более правильный подход выглядит так:
— память команд хранится в процессоре или очень близко, они постоянно и гарантированно читаются процессором — кэш хоть и снижает проблему, но ее не решает.
— оставить в пределах процессора все промежуточные данные, если данные будут участвовать в «ближайших» вычислениях и отсутствуют в итоговом результате в чистом виде, то и передавать их в память нет смысла, таких данных немного.
— в память имеет смысл поместить логику преобразования последовательности данных в памяти, что бы процессор всегда читал данные в той последовательности как выполняет обработку. Гарантировать последовательные операции чтения, а не рандомные обращения.
Толстая шина ничего не даст — она будет жрать сотни ватт и задержками угробит весь перформанс
Шина не эффективна, а вот последовательный канал из нескольких 100G+ пар и временем доставки до соседнего процессора в районе единиц наносекунд (или до 100 нс в масштабах датацентра) очень даже эффективно, особенно при конвейерной обработке. Особенно если данные лежат ровно в той последовательности, как будут обработаны процессором.
Вот именно про это предлагаемая мной DSM
Решить эту проблему полностью, PIM не сможет.
Об этом не было и речи. Речь о том, что PIM ее хотя бы частично решает, а ваше решение не решает ничего. Оно может решить другие проблемы, с которым борются прочие технологии дисагрегированного датацентра и гетерогенных вычислений.
На остальное даже отвечать не хочется. Какие-то наивные выдумки и просто глупости, уж простите. Мне понятно, что хочется везде свое сочинение воткнуть, но заканчивайте. В тех двух абзацах нет ничего особо интересного.
Строго последовательное чтение — это уменьшение потребления (по электричества) в 3-4 раза.
Вычисления это нагрев — теплоотвод в DDR никакой (пару ватт) и этим все сказано.
На остальное даже отвечать не хочется.
Напоминаю гордыня смертный грех, а необоснованная в двойне )))
Синхронные схемы с синхронными интерфейсами (строго последовательными данными) гарантированно быстрее и производительнеее любых асинхронных схем. Строго говоря современный процессор это тоже полностью синхронная схема. Все что очень быстрое синхронного (ну кроме единичного импульса).
Такая память есть HBM X, только у нее есть минус время чтения страницы (50-70нс). Данный минус можно нивелировать знанием того что понадобится через 250-350 тактов процессора.
Такое знание можно получить двумя способами:
— программист сам пишет что и в какой последовательности и насколько заранее нужно приготовить для обработки (вот эту логику и можно внедрить в память или контроллер).
— программа строго последовательна и можно заранее (на этапе компиляции учесть и подготовить данные)
При созданиии вычислительной системы пятого поколения, я учел и внедрил оба варианта.
Если процессор имеет пиковую производительность 10Е15 (именно такую архитектуру я и разработал), то он не может работать только с заранее подготовленными данными. Во всех остальных случаях его производительность будет ограничена временем доступа в память, понятно что даже локальный кэш первого уровня в такой ситуации не «рулит».
Хотите испытать себя, прочитайте и расскажите что вы смогли понять:
habr.com/ru/post/512652
По поводу инвесторов, идет процесс включения в план исследовательских работ компании, оборудование которой есть если не в каждом офисе то через раз.
заряд делится пополам
Это из разряда аналоговых вычислений (аналоговый компьютер) изучал в на лабораторных в НЭТИ. Тут есть проблема, большие шумы и различие в утечках в разных ячейках. Думаю не «выстрелит». Единственное что имеет смысл поместить в память, это логику гарантирующую что процессор будет подучать данные строго в порядке их обработки. Иными словами, логика гарантирующая что прочессор всегда будет осуществлять последовательное чтение (сейчас эту проблему решает кэш)
сейчас эту проблему решает кэш
Эту проблему кэш не решает никаким образом. Он может читает байтики последовательно в рамках кэш линии, но сами кэш линии абсолютно случайны и решить это скорее всего даже теоретически невозможно. Софт так не работает. Кэш решает абсолютно другую проблему - чрезвычайно высокое время доступа к памяти и низкую пропускную способность. PIM это решение той же проблемы, но кардинально другим подходом.
Давно этого ждал (вычисления в памяти). Кто знает, может даже видеокарты не будут нужны, все будет в памяти рендерится.
Память с калькулятором. Вычисления внутри DRAM становятся мейнстримом