Efficient Computer — стартап из Питтсбурга, основанный в 2022 году командой исследователей из Университета Карнеги-Меллона. Между прочим, именно Университет Карнеги-Меллона является основным поставщиком кадров в MicrosoftResearch.
Efficient Computer разрабатывает принципиально новую не Фон-Неймановскую архитектуру процессоров и программную экосистему.
Их флагманская технология, известная как архитектура Fabric, представляет собой перенастраиваемый процессор с потоковой обработкой данных, минимизирующий внутренние перемещения данных и управляющие издержки — основные источники энергопотерь в классических решениях. Fabric размещает инструкции пространственно на чипе. Это позволяет данным перемещаться по заранее определённому маршруту между вычислительными узлами — так называемыми Tiles. Поскольку tile переводится как плитка, я бы и название архитектуры перевел как Кафель. Каждая плитка — это упрощённый вычислительный блок, лишённый избыточных механизмов, таких как предсказание ветвлений или выборка инструкций, что значительно снижает энергопотребление.
Недавно вышедший процессор Electron E1, реализующий архитектуру Fabric, обеспечивает до 100-кратного повышения энергоэффективности по сравнению с традиционными CPU. Он поддерживает параллелизм, а также способен обрабатывать произвольные управляющие конструкции, включая циклы и ветвления, благодаря специальным инструкциям и маршрутам обратной связи. Встроенная память и энергонезависимая память интегрированы в вычислительный конвейер, обеспечивая низкую задержку при выполнении задач ИИ и обработки сигналов. Fabric подходит для встраиваемых систем, носимых устройств, IoT и даже космических приложений, где критичны параметры SWaPC (размер, вес, мощность, стоимость). Благодаря своей гибкости и энергоэффективности, Efficient Computer открывает новые горизонты для вычислений на периферии (edge computing).
Другой ключевой компонент экосистемы — Компилятор effcc, предназначенный для преобразования обычного кода (на C, C++, TensorFlow и других языках) в оптимизированное представление для архитектуры Fabric. Вместо традиционного пошагового выполнения, effcc трансформирует код в граф потоков данных, определяя наиболее эффективное пространственное размещение операций на чипе. Это позволяет значительно сократить энергопотребление, устраняя избыточные перемещения данных и управляющие инструкции. Компилятор автоматически анализирует и оптимизирует код, обеспечивая максимальную производительность и длительное время работы от батареи.
Efficient Computer также предлагает Compiler Playground — веб-инструмент, визуализирующий выполнение программы на Fabric, позволяя разработчикам увидеть, как операции распределяются по архитектуре.
Мне посчасливилось поиграть в песочнице Efficient Computer и проверить, насколько хорош компилятор в автоматическом режиме.
Я попробовал три программки, каждая из которых имеет одинарный цикл одной и той же длины, но демонстрирует разные варианты параллелизма: чрезвычайную параллельность, примитив Reduce, и примитив Scan.
Первая задачка – векторная операция AXPY.
Для компиляции функции в код для Кафеля, необходимо указать атрибут __effcc_rip:
Запускаем программу и наблюдаем за ее выполнением в визуализаторе.
Действительно похоже на кафельный пол:
Программа выполняется за 27 тактов. Запомним эту цифру для сравнения.
Вторая программа – сумма всех элементов массива.
Поскольку отсутствуют промежуточные операции записи в память, плитки используются более эффективно. Активных плиток на кафеле гораздо больше. И время выполнения программы меньше – всего 18 тактов.
Интересно взглянуть на прогноз энергоэффективности:
Время работы процессора E1 от батарейки при выполнении данной программы выводится в годах(!), а время работы сопоставимых маломощных процессоров – в днях.
Наконец, программа накопительной суммы элементов массива.
Кафель набит плотненько, но тем не менее время выполнения программы целых 117 тактов. Видимо, компилятор не сумел распознать параллелизм накопительной суммы. Это действительно непростая задача и область активных исследований в теории компиляторов.
Как бы ни был хорош компилятор, в процессе всегда найдется место для программиста в машинном (или кафельном) коде.
Сейчас замечательное время, когда как грибы появляются новые вычислительные архитектуры, отвечающие на новые запросы к вычислительной мощности и энергопотреблению в задачах искусственного интеллекта. И отрадно видеть нестандартные подходы к проблеме, например, Efficient Computer.
Комментарии (22)
old_bear
28.07.2025 00:13На Transport triggered architecture похоже.
Как уже заметили комрады выше, всё отлично за вычетом необходимости написать мега-компилятор. Который вероятнее всего будет выполняться на Фон-Неймановской архитектуре. :)
Panzerschrek
28.07.2025 00:13Простой цикл сложения элементов массива их компилятор таки осиливает развернуть и нагенерирофать этих плиток. Но как с обстоит дело с произвольным кодом? C++, как и другие языки, создавались в расчёте на совершенно другую архитектуру, удастся ли их эффективно адаптировать к этому кафельному подходу?
iShrimp
28.07.2025 00:13Здесь подход примерно как для ПЛИС. Для низкоуровневого программирования нужен какой-нибудь HDL язык типа SystemC. В качестве ЯВУ может выступать любой язык. Но каким бы умным ни был компилятор, всегда найдётся код, который будет ему не по зубам.
ValeriyPus
28.07.2025 00:13Компилятор - не очень сложно.
Топологическая сортировка потоков данных (от команды к команде).
И Linear/Integer programming. С эвристиками и без.
Циклы - то же самое, пишем
(Код до цикла)
(Итерация 1)
(Итерация 2)
...
И запускаем топологическую сортировку.
Есть кучи публикаций
unreal_undead2
28.07.2025 00:13Выглядит очень похоже на интеловский CSA (который, правда, не пошёл в массовое производство). Интересно, покупали права на патент или обошли.
ValeriyPus
28.07.2025 00:13Вы не можете запатентовать такое.
Это https://en.wikipedia.org/wiki/Transport_triggered_architecture
Это тот же RISC, только графы испольнения посложнее и побольше.
И вместо миллиарда команд - простая конфигурация исполнительного блока через маленькие команды.
Ну и таких разработок любой, знакомый с абстракцией индукцией и дедукцией выдает по 100 штук.
Карнеги-меллон - не MiT и не KAIST.
И публикаций о подобных процессорах - очень много.
https://github.com/ValeriyAndreevichPushkarev/STA_ring_buffer
Найди 3 отлиция в прорыв процессор великий гений Microsoft империя!
Технология!
Кэш из ячейка фабрика вынесен!
НЕ DPA!
Не СИМИДИ НЕ СИМИДИ!
А представляют процессор как-то вот так:
unreal_undead2
28.07.2025 00:13Патент по ссылке читали?
ValeriyPus
28.07.2025 00:13Википедию читали?
unreal_undead2
28.07.2025 00:13Да, глянул - общие идеи близкие (и они явно публичные), но есть всё таки много конкретики при реализации в железе, и на мой взгляд интеловский патент сильно коррелирует с железякой из статьи.
ValeriyPus
28.07.2025 00:13Вкраце - уже 3 подобных процессора выпустили в кремнии (один в один, переферия другая конечно). Еще в 2000-х.
А в общем - функциональные блоки и связи между ними.
Есть даже OpenSource реализация архитектуры.
В те времена с эвристиками и компиляторами были проблемы (нет нейросетей и эвристик, дай бог 500 MOPS а не 100 TOPS при компилировании нельзя проверить нормальное количество вариантов).
Теперь это преподают как прорыв (но, увы, уже плохо с компилятором).
domix32
28.07.2025 00:13Хоть бы ссылку на демо дали. Вообще интересно сколько оно там условных флопсов выдаёт в такой архитектуре.
rPman
28.07.2025 00:13Помятуя, как планетарный полицейский ограничивает развитие в мире высокоэффективных вычислений, да просто на примере блокирования FPGA в стандарте (и железо есть но цены заградительные, никому не нужно, никто не покупает), революции еще долго не увидим.
Кстати FPGA уже готовая параллельная энергоэффективная платформа, и компиляторы есть, и сообщество, и опыт многолетний... только железа массового не завезли.
unreal_undead2
28.07.2025 00:13FPGA это крайность - с одной стороны, можно нарисовать любую схему на индивидуальных гейтах, с другой стороны - из за этой гибкости не получается разместить эти гейты так же плотно и гонять с той же частотой, как на обычно микросхеме. Тут предлагается компромисс - мы кастомизируем связи не между гейтами, а между достаточно большими вычислительными юнитами, каждый из которых может быть напечатан по традиционной технологии.
Основной затык в программной модели - программировать на чём то типа Верилога массы не хотят, а эффективно компилировать в граф на железке код на традиционных языках не особо получается.
leshabirukov
28.07.2025 00:13"Любую схему"... я тоже так думал, пока свой проект с насыщенной не 2d структурой (вот этот, - Не-фон неймановский компьютер на базе комбинаторной логики / Хабр ) не запустил на сборку в Quartus-е. Компиляция прошла на ура а вот фиттер (который нетлист на структуру FPGA проецирует) показал шиш. FPGA как раз больше всего любит именно плоскую структуру, чип-то плоский!
А тут работу фиттера можно сказать кожаный мешок делает, в идеале минуя verilog и нетлист.
Yami-no-Ryuu
28.07.2025 00:13Люди всё переизобретают транспьютеры в разных вариантах. Видимо, к чему-то такому придёт, да. Скорее из-за проблемы локального тепла.
И оптические (или другие) тоже не окончательное решение, есть квантовые ограничения на энергию и скорость. В итоге всё равно будет вычислительная материя с организацией похожей на мозг.
checkpoint
Недавно посмотрел видео про этот Electron E1, из чего сделал вывод, что парни из Питтсбурга пытаются
выкопать стюардессувозродить VLIW на новой базе - реконфигурируемый конвейер из огромного числа блоков обработки (ALU, LOAD/STORE и прочее). Как и во VLIW, у них за всё отвечает компилятор, в том числе за оптимальную конфигурацию конвейера на стадии компиляции. Видимо опыт предыдущих поколений их ни чему не научил. Либо я прослушал как они собиратся решать типовые проблемы VLIW (в частности, где брать оптимизирующий компилятор).Zhuikoff
VLIW сам по себе как технология крут, но он совсем другой. Чтобы писать под него, нужно мыслить иначе, а у человека память держит от 3х до 7 объектов одновременно, мы слишком слабые и ленивые, нам вайб кодинг подавай и желательно с голосовым вводом. Поэтому страх и отторжение. И это глубокий-глубокий минус.
ruomserg
VLIW упирается в предсказание свойств произвольной программы, которое упирается в проблему остановки, которая упирается в P?=NP, и все это кажется упирается в то, что любая достаточно сложная логическая система либо неполна, либо противоречива.
Обратите внимание, что суперскалярные архитектуры (а равно JIT) ориентируются на прошлые события, чтобы оптимизировать свою работу в относительно недалеком будущем (десятки-сотни-тысячи тактов).
А гипотетический компилятор WLIV должен "прямщас" вам оптимизировать весь путь исполнения программы с неизвестными входными данными глядя только на листинг исходного кода. В природе такого не бывает, а напоминает это сказку о мышах, которые нашли идеальное решение своей проблемы: "если бы кошке подвесили колокольчик..." (C). Как бы и да - но как бы сначала подвесьте!..
rPman
ну и сейчас классические компиляторы умеют собирать статистику Profile-guided optimization, ее можно собирать, прогнав специально собранное приложение (с помощью gcc/llvm) на типовом наборе данных, а затем пересобрать с использованием собранных данных.
ruomserg
Ну, технически, конечно можно предположить двух- (и более!) стадийную компиляцию в кафель. Сначала компилируем как-то (не в сторону быстродействия, а в сторону более представительной статистики), потом гоняем на нагрузке, потом грузим статистику и переделываем кафель. Насколько это имеет смысл, и насколько удастся эту статистику собирать не вызывая погрешности в ходе исполнения - вопросы... Я помню уже несколько попыток создания таких систем. Было такое слово "транспьютеры" - и умерло. Я в своей магистерской лет 20 назал считал надежность нейроноподобных вычислительных комплексов - и тоже "в железе" так ни один и не увидел! Похоже, распределенные вычисления - это что-то вроде термоядерного синтеза: да, теоретически возможно - но нет, в ближайшие 20 лет не заработает (и каждый год так!)...
old_bear
Может нейросеть натренируют чтобы она магию делала.