Comments 25
Недавно посмотрел видео про этот Electron E1, из чего сделал вывод, что парни из Питтсбурга пытаются выкопать стюардессу возродить VLIW на новой базе - реконфигурируемый конвейер из огромного числа блоков обработки (ALU, LOAD/STORE и прочее). Как и во VLIW, у них за всё отвечает компилятор, в том числе за оптимальную конфигурацию конвейера на стадии компиляции. Видимо опыт предыдущих поколений их ни чему не научил. Либо я прослушал как они собиратся решать типовые проблемы VLIW (в частности, где брать оптимизирующий компилятор).
VLIW сам по себе как технология крут, но он совсем другой. Чтобы писать под него, нужно мыслить иначе, а у человека память держит от 3х до 7 объектов одновременно, мы слишком слабые и ленивые, нам вайб кодинг подавай и желательно с голосовым вводом. Поэтому страх и отторжение. И это глубокий-глубокий минус.
VLIW упирается в предсказание свойств произвольной программы, которое упирается в проблему остановки, которая упирается в P?=NP, и все это кажется упирается в то, что любая достаточно сложная логическая система либо неполна, либо противоречива.
Обратите внимание, что суперскалярные архитектуры (а равно JIT) ориентируются на прошлые события, чтобы оптимизировать свою работу в относительно недалеком будущем (десятки-сотни-тысячи тактов).
А гипотетический компилятор WLIV должен "прямщас" вам оптимизировать весь путь исполнения программы с неизвестными входными данными глядя только на листинг исходного кода. В природе такого не бывает, а напоминает это сказку о мышах, которые нашли идеальное решение своей проблемы: "если бы кошке подвесили колокольчик..." (C). Как бы и да - но как бы сначала подвесьте!..
ну и сейчас классические компиляторы умеют собирать статистику Profile-guided optimization, ее можно собирать, прогнав специально собранное приложение (с помощью gcc/llvm) на типовом наборе данных, а затем пересобрать с использованием собранных данных.
Ну, технически, конечно можно предположить двух- (и более!) стадийную компиляцию в кафель. Сначала компилируем как-то (не в сторону быстродействия, а в сторону более представительной статистики), потом гоняем на нагрузке, потом грузим статистику и переделываем кафель. Насколько это имеет смысл, и насколько удастся эту статистику собирать не вызывая погрешности в ходе исполнения - вопросы... Я помню уже несколько попыток создания таких систем. Было такое слово "транспьютеры" - и умерло. Я в своей магистерской лет 20 назал считал надежность нейроноподобных вычислительных комплексов - и тоже "в железе" так ни один и не увидел! Похоже, распределенные вычисления - это что-то вроде термоядерного синтеза: да, теоретически возможно - но нет, в ближайшие 20 лет не заработает (и каждый год так!)...
интересно что именно движет их на подвиги, довольно давно есть потребность в интеграции разработки hw, и sw, начиная с FPGA в 80х, наиболее радикальное решение это вероятно общий язык описания hw+sw, типа описание контроллера одновременно с логикой обработки прерываний и т.д., imho продолжаются эксперименты - что именно может быть hw кластером, как transputer, т.е. методом проб и ошибок выбирается уровень абстракции новых HDL (выше уровня портов и сигналов), цикл разработки IC включая тестирование сокращается, если в дальней перспективе получится лучше интегрировать разработку hw и sw, новые системы тоже можно будет делать существенно быстрее, что супер важно
в частности, где брать оптимизирующий компилятор
Может нейросеть натренируют чтобы она магию делала.
На Transport triggered architecture похоже.
Как уже заметили комрады выше, всё отлично за вычетом необходимости написать мега-компилятор. Который вероятнее всего будет выполняться на Фон-Неймановской архитектуре. :)
Простой цикл сложения элементов массива их компилятор таки осиливает развернуть и нагенерирофать этих плиток. Но как с обстоит дело с произвольным кодом? C++, как и другие языки, создавались в расчёте на совершенно другую архитектуру, удастся ли их эффективно адаптировать к этому кафельному подходу?
Компилятор - не очень сложно.
Топологическая сортировка потоков данных (от команды к команде).
И Linear/Integer programming. С эвристиками и без.
Циклы - то же самое, пишем
(Код до цикла)
(Итерация 1)
(Итерация 2)
...
И запускаем топологическую сортировку.
Есть кучи публикаций
Вы не можете запатентовать такое.
Это https://en.wikipedia.org/wiki/Transport_triggered_architecture
Это тот же RISC, только графы испольнения посложнее и побольше.
И вместо миллиарда команд - простая конфигурация исполнительного блока через маленькие команды.
Ну и таких разработок любой, знакомый с абстракцией индукцией и дедукцией выдает по 100 штук.
Карнеги-меллон - не MiT и не KAIST.
И публикаций о подобных процессорах - очень много.
https://github.com/ValeriyAndreevichPushkarev/STA_ring_buffer
Найди 3 отлиция в прорыв процессор великий гений Microsoft империя!
Технология!
Кэш из ячейка фабрика вынесен!
НЕ DPA!
Не СИМИДИ НЕ СИМИДИ!
А представляют процессор как-то вот так:
Патент по ссылке читали?
Википедию читали?
Да, глянул - общие идеи близкие (и они явно публичные), но есть всё таки много конкретики при реализации в железе, и на мой взгляд интеловский патент сильно коррелирует с железякой из статьи.
Вкраце - уже 3 подобных процессора выпустили в кремнии (один в один, переферия другая конечно). Еще в 2000-х.
А в общем - функциональные блоки и связи между ними.
Есть даже OpenSource реализация архитектуры.
В те времена с эвристиками и компиляторами были проблемы (нет нейросетей и эвристик, дай бог 500 MOPS а не 100 TOPS при компилировании нельзя проверить нормальное количество вариантов).
Теперь это преподают как прорыв (но, увы, уже плохо с компилятором).
Хоть бы ссылку на демо дали. Вообще интересно сколько оно там условных флопсов выдаёт в такой архитектуре.
А нельзя ли программу на этом языке в прошивку FPGA откомпилировать?
Помятуя, как планетарный полицейский ограничивает развитие в мире высокоэффективных вычислений, да просто на примере блокирования FPGA в стандарте (и железо есть но цены заградительные, никому не нужно, никто не покупает), революции еще долго не увидим.
Кстати FPGA уже готовая параллельная энергоэффективная платформа, и компиляторы есть, и сообщество, и опыт многолетний... только железа массового не завезли.
FPGA это крайность - с одной стороны, можно нарисовать любую схему на индивидуальных гейтах, с другой стороны - из за этой гибкости не получается разместить эти гейты так же плотно и гонять с той же частотой, как на обычно микросхеме. Тут предлагается компромисс - мы кастомизируем связи не между гейтами, а между достаточно большими вычислительными юнитами, каждый из которых может быть напечатан по традиционной технологии.
Основной затык в программной модели - программировать на чём то типа Верилога массы не хотят, а эффективно компилировать в граф на железке код на традиционных языках не особо получается.
"Любую схему"... я тоже так думал, пока свой проект с насыщенной не 2d структурой (вот этот, - Не-фон неймановский компьютер на базе комбинаторной логики / Хабр ) не запустил на сборку в Quartus-е. Компиляция прошла на ура а вот фиттер (который нетлист на структуру FPGA проецирует) показал шиш. FPGA как раз больше всего любит именно плоскую структуру, чип-то плоский!
А тут работу фиттера можно сказать кожаный мешок делает, в идеале минуя verilog и нетлист.
программировать на чём то типа Верилога массы не хотят
есть же opencl компиляторы в fpga, конечно это не так эффективно как на verilog, но если проводить аналогию, verilog - это ассемблер/c, а opencl - это cpp.
Да, Интел продвигал эту тему (сейчас, соотвественно, есть бэкенд для sycl) - но там надо достаточно специфически программировать (скажем, есть паттерн для описания сдвиговых регистров, чтобы реализовать пайплайн - для CPU/GPU программиста это очень странно) и при этом эффективность всё равно так себе.
Люди всё переизобретают транспьютеры в разных вариантах. Видимо, к чему-то такому придёт, да. Скорее из-за проблемы локального тепла.
И оптические (или другие) тоже не окончательное решение, есть квантовые ограничения на энергию и скорость. В итоге всё равно будет вычислительная материя с организацией похожей на мозг.
Efficient Computer: программируем по кафелю