В последние пару недель на многих сайтах были заметки о начале производства (на азиатских заводах) отечественных процессоров Multiclet с «прорывной архитектурой и фантастической производительностью», в том числе и на Хабре: Первая опытно-промышленная партия отечественных мультиклеточных процессоров MCp. Все эти заметки в целом рассматривали разработку с позитивной стороны, основываясь на преимуществах в изложении разработчиков. Я всегда интересовался отечественными разработками, и попробую рассказать об этом процессоре чуть более критически, и описать в меру своих возможностей суть этой новой архитектуры.
Источники информации — ограниченная документация доступная на сайте разработчика, и ответы сотрудников компании на вопросы.
Архитектура
Если отбросить всю словесную шелуху — мультиклет — это в первом приближении любимый в России EPIC: архитектура с явным параллелизмом. В отличии от VLIW, где компилятор указывает какой блок что должен делать, тут указываются только зависимости инструкций, а по ядрам они растаскиваются уже в процессе выполнения (таких ядер в MCp0411100101 — 4 штуки).
Преимуществ по сравнения с VLIW тут 2: гипотетическая возможность запускать код на процессоре c другим количеством «ядер» и возможность продолжить работу при выходе из строя одного из ядер. Оба преимущества, на мой взгляд, весьма сомнительны:
1) Запуск без перекомпиляции на процессоре бóльшего размера — для embedded применений обычно нет проблемы в перекомпиляции. Помимо этого, оптимальный код для 4 и 16 ядер разный — и запуск без перекомпиляции снижает эффективность (конечно если мы делаем что-то сложнее чем перемножение массивов).
2) Устойчивость к сбою любого ядра — эта «фишка» появилась недавно. И нет никакой информации о том, как это работает — я думаю что это не работает вообще, в том виде как это нам представляется.
Как в самом деле можно определить сбой ядра «на лету»? Если это космос — то будут случайные, не предсказуемые и не фатальные для процессора ошибки. Если это «защелкивание» от прохождения тяжелой заряженной частицы — то сгорит весь кристалл. Ну и наконец, что толку отключать ядра, если основная часть сложности — в общем коммутаторе и регистровом файле (о них ниже), и при любой ошибке в них — все заботы о надежности оказываются напрасными? Так что я думаю, это классический русский маркетинг, нужный чтобы оправдать использование в военных разработках.
Теперь посмотрим на картинку из описания процессора (ПП — память программ, ПД — память данных, ПБ — процессорный блок):
Сразу бросается в глаза — общий регистровый файл и коммутатор. Именно они не дадут радикально наращивать количество ядер в рамках текущей архитектуры: сложность коммутатора все-ко-всем растет пропорционально квадрату количества ядер. Регистровый файл с 16-32 портами — это тоже на грани фантастики с точки зрения реализации в кремнии. Проблема тут не только в том, что эти элементы занимают много места на кристалле — они еще и относительно медленно работают. Помимо этого, в процессоре нет конвейера и соответственно предсказания ветвлений — это безусловно упрощает разработку, но и существенно снижает возможную тактовую частоту.
Далее, тут память программ нарисована отдельно для каждого ядра — надеюсь это просто упрощение рисунка, иначе все разговоры о возможности отключения ядра становятся совсем уж далеки от реальности.
Производительность
Казалось бы, 2.4GFLOP декларируемые производителем — весьма существенная производительность. Однако, в компании-разработчике процессора отказались пояснить, каким образом была получена эта цифра, и не подтвердили, что madd (multiply+add) выполняется за 1 такт. Тем не менее, похоже, мне удалось понять откуда взялась такая цифра.
Мультиклет работает с числами сниженной точности — «single» (24-бит) и «double» (48-бит) вместо стандартных 32 / 64бит и есть возможность упаковать комплексное число single-точности в 48 бит (т.е. действительная и мнимая часть по 24 бит). Тогда и получается, что если умножение двух комплексных чисел выполняется за 1 такт, то это дает 6 FLOP за такт: (a + bi)(c + di) = (aс + bd) + (ad + bc)i., и соответственно, 6*4*100Mhz = 2.4GLOP.
Тогда в операциях с 48-битными числами мы получаем в лучшем случае 0.4-0.8 GFLOP (чистое умножение / MADD), если эти операции выполняются за 1 такт.
Таким образом, сравнивать эту производительность с Pentium-ами всякими конечно нельзя: в настольных процессорах принято производительность измерять на 64-х битных вещественных числах, а тут озвученные цифры производительности получаются только на 24-бит и только в специфических условиях.
Периферия и прочий фарш
Во первых, обращаем внимание на количество памяти — по 16кб памяти программ и данных.
Контроллера внешней памяти нет, соответственно все разговоры о портировании Linux — это дело далекого и туманного будущего, перед которым нужно еще сделать бакенд к GNUC для этого процессора.
Флеш-памяти для хранения программы нет, и загрузка производится с внешней флешки (в данный момент это Xilinx XCF04S). Естественно это вызвало подозрения, что процессор — перемаркированная FPGA, но на прямой мой вопрос об этом мне ответили:
Вместо Xilinx можно было бы поставить любую флэшку, а кристалл есть кристалл (внимательно посмотрите сайт), на FPGA мы сейчас ничего не делаем. Делали на этапе ОКР, для подтверждения расчётных параметров.
Периферия — более-менее понятная для тех, кто работал с микроконтроллерами, за исключением Ethernet и USB — на кристалле нет «физической» части интерфейса, и их нужно ставить на плате отдельными (импортными) микросхемами.
Софт для разработки — на данный момент только ассемблер. Компилятор С находится на стадии «пузырьковая сортировка работает». Подробное описание архитектуры, необходимое для разработчиков — не доступно на данный момент.
Резюме
Я не склонен думать, что Мультиклет — это прорыв в архитектуре процессоров с коммерческой точки зрения (с академической — безусловно интересный проект) из-за уже видимых ограничений: текущая производительность в 400млн операций в секунду уступает даже существующим серийным Российским разработкам, и рост этой производительности (как по частоте так и количеству ядер) в будущем ограничен этой же архитектурой: «тяжелыми» регистровыми файлами, коммутаторами все-ко-всем и отсутствием конвейеризации.
Ниша для практического применения достаточно ограничена — фактически, это DSP-приложения которым хватает 24-бит точности и еще лучше если требуется комплексная арифметика, обычный код выполнять на этом процессоре трудно из-за малого объема памяти и производительности (400млн инструкций в секунду + достаточно простые инструкции).
Но в целом, остается порадоваться появлению работающей уникальной архитектуры, разработанной в России, даже если она и не найдет широкого применения вне оборонных применений.
Буду рад услышать ваши дополнения и корректировки — доступная информация по Мультиклету весьма ограничена, и я вполне могу где-то ошибаться.
Автор: BarsMonster
