Комментарии 36
Мультиклеточная архитектура процессора, на мой взгляд, очень близка к ныне модной реактивной и data-driven программным архитектурам. Возможно, эффективный компилятор для такого процессора должен работать не только на уровне инструкций компилируемого языка, но и на уровне семантики каких-нибудь библиотек для реактивного и data-driven программирования (например, повторяя API http://reactivex.io/ или https://facebook.github.io/relay/). Можно представить себе это как код на «классическом» языке программирования, в котором программист ссылается на потоки данных, которые (вместе со всеми преобразованиями) декларативно описаны в виде какой-нибудь XML/JSON-схемы (или декларативный язык сразу встроен в «классический» язык в стиле LINQ).
Почему сразу C/C++? На LLVM сделано много более полезных языков — например Rust (особенно для встраиваемых систем).
Так сделали же бэкэнд LLVM, фронтэнд может быть хоть Rust, если я правильно понимаю. И как бы не был Rust хорош, кому нужен процессор (на позицию аналога, а не революции, как квантовые вычисления), для которого нужно переписывать весь софт на новом ЯП? К тому же Rust скорее конкурент C++, а не C.
Для встраиваемых систем повторно использовать софт не всегда получается, значительная часть пишется заново.
Переход C++ -> Rust сложнее, чем C -> Rust. На Rust можно программировать как на C, только безопасно, а плюсовикам придется сильно менять свои привычки.
Переход C++ -> Rust сложнее, чем C -> Rust. На Rust можно программировать как на C, только безопасно, а плюсовикам придется сильно менять свои привычки.
Как понимаю, они хотят создать процессор общего назначения, а при наличие компилятора Си можно портировать NetBSD, Linux и любую другую ОС.
Ага. И кучу другого, уже написанного, софта.
Всё-таки Rust и прочие Haskell — пока больше экзотика «для ценителей». Да, и как у него с эффективностью использования ресурсов? А с низкоуровневым доступом к аппаратуре? Как бы не получилось так, что, чтобы общаться с железом, нужна спец.библиотека, написанная на… Си.
Ну, и, кроме того, имея нормально работающий бэкенд, мы (почти) автоматически получаем поддержку всего зоопарка языков, знакомых LLVM.
Всё-таки Rust и прочие Haskell — пока больше экзотика «для ценителей». Да, и как у него с эффективностью использования ресурсов? А с низкоуровневым доступом к аппаратуре? Как бы не получилось так, что, чтобы общаться с железом, нужна спец.библиотека, написанная на… Си.
Ну, и, кроме того, имея нормально работающий бэкенд, мы (почти) автоматически получаем поддержку всего зоопарка языков, знакомых LLVM.
Для квантовых — переписывают и не ворчат.
Rust более полезен, чем С++? Хмм…
потому что там, где есть C/C++, есть как минимум линукс и половина других яп. А там, где есть Rust, есть амбиции и, собственно, Rust
Вот сейчас пришёл коллега, и говорит, что скомпилировал и запустил на отладочной плате Rust-пример, мигающий лампочками.
Так что не всё так плохо.
Так что не всё так плохо.
Скомпилируйте на этом проце майнер биткоина или етериума и с финансированием разработок все проблемы разом отпадут )
Не знаю, за что вас минусанули (наверное за отпавшие проблемы). На самом деле я предлагал реализовать майнер, это же хороший тест, куча платформ имеет рейтиг в майнинге биткоинов и по сути это аналог рейтингу в шифровании. Только биткоины привлекают гораздо больше внимания чем само шифрование. Популяризация необычным архитекутрам всегда нужна.
Прекрасная статья, хорошо представленый материал. Надесюь, что годовой провал в работе с общественностью закончился, и Мультиклет мы регулряно будем видеть на Хабре.
Пара замечаний: не надо напирать на задачу подсчёта битов, Интел делает это одной коммандой, используйте везде конкретное название алгоритма и одного раза (в скобочках) достаточно, — его суть.
По таблице БПФ не понял логики: про SIMD пнятно, типа слишком тяжёлые и узкоспециализированные комаманды — нечего на них смотреть.
Про c66x… Мультиклет 10 000 операций сделал за 2 000 тактов (грубо), c66x 15 000 распараллелил так, что выполнялись всего за 1 500 тактов. Как, по мне, так вывод, что c66x параллелит гораздо лучше, но набор комманд хуже, поскольку ассемблерный листинг больше.
Говорят, lazarus можно подключить к LLVM, неужели на Дельфи под Мультиклет получится? :-)
Пара замечаний: не надо напирать на задачу подсчёта битов, Интел делает это одной коммандой, используйте везде конкретное название алгоритма и одного раза (в скобочках) достаточно, — его суть.
По таблице БПФ не понял логики: про SIMD пнятно, типа слишком тяжёлые и узкоспециализированные комаманды — нечего на них смотреть.
Про c66x… Мультиклет 10 000 операций сделал за 2 000 тактов (грубо), c66x 15 000 распараллелил так, что выполнялись всего за 1 500 тактов. Как, по мне, так вывод, что c66x параллелит гораздо лучше, но набор комманд хуже, поскольку ассемблерный листинг больше.
Говорят, lazarus можно подключить к LLVM, неужели на Дельфи под Мультиклет получится? :-)
Говорят, lazarus можно подключить к LLVM, неужели на Дельфи под Мультиклет получится? :-)Если FPC умеет генерировать IR код, и его call convention не является каким-то экзотическим (скорее всего pascal, либо же stdcall) то да, думаю можно.
C66х для решения той же задачи потребовалось в полтора раза больше операций (читай: «электричества»); при этом, имея в два раза больше исполнительный устройств, справился с задачей он всего на 30% быстрее.
А, поскольку это — VLIW, то получается, что «параллелит лучше» не процессор, а компилятор, с его неограниченными ресурсами и вИдением всей программы.
А, поскольку это — VLIW, то получается, что «параллелит лучше» не процессор, а компилятор, с его неограниченными ресурсами и вИдением всей программы.
Наиболее отчетливо это видноПо таблице — не видно, поскольку там нет упоминаний про исполнителные устройства.
Количество операций ровнять с эелектричеством — не стоит, есть архитектуры CISC и RISC, что как бы уже само намекает о бесполезности такого сравнения.
А говоря об эффективности, именно в этом месте статьи, вообще говорится не о вычислительных ресурсах на Вт, а о
эффективно реализует параллелизм. Пока что останусь при своём мнении, по цифрам изделие от TI выглядит более выгодно.
Что же касается количества инструкций, то, например z80 не имеет инструкции умножения и в сравнении, количество инструкций на алгоритм будет больше, но понятно, что здесь речь скорее не о архитектуре, а о развитости набора комманд. Поэтому, если цифрой 15 000 операций хотели сказать что-то конкретное об архитектуре процессора, то надо изложить это более подробно, самой цифры не достаточно, нужен анализ.
По таблице — не видно, поскольку там нет упоминаний про исполнителные устройства.Молчаливо предполагается, что оно
В таком контексте — есть смысл, но всё же стоит это добавить к статье. Однако, есть такая вещь как конвеер, который позволяет «накладывать» инструкции друг на друга и, хотя, по идее быстрее чем за такт на каждую на нём не получится, суперскаляры имеют несколько конвееров, а для эмулирующих CISC, так называемых decoupled RISC архитектур (те же x86), над одной инструкцией вполне себе работают несколько конвееров и пол такта на инструкцию это у них норма. Я уже не говорю о том, что конвееры могут быть специализированными и работать на разных частотах (могу гнать), например для FP (совсем недавно это вообще был сопроцессор) и для целочисленных операций.
Речь идёт о конкретной аппаратной реализации совершенно новой архитектуры, причём о второй реализации, и тот факт, что мы уже сравниваемся с монстрами, имеющими 30+ лет опыта в разработке DSP и десятки (сотни?) реализаций в кремнии, вселяет оптимизм. Более того, уже сейчас видны пути повышения производительности следующего процессора в разы.
Тогда ответьте мне на вашем форуме (или здесь) на эту тему:
http://multiclet.com/community/boards/3/topics/1633
Я уже созрел что бы вложить тысяч 20 на хобби, а Мультиклет обещает много интереснейшего и перспективного опыта.
Кстати, я уже упоминал о краудрафтинге, но вы упорно не хотите им заниматься, я думаю, что не одинок в том. что с удовольствием дал бы деньги вперёд под ещё не выпущенный процессор, если, к примеру. там появился бы MMU и подождал месяцев 6.
http://multiclet.com/community/boards/3/topics/1633
Я уже созрел что бы вложить тысяч 20 на хобби, а Мультиклет обещает много интереснейшего и перспективного опыта.
Кстати, я уже упоминал о краудрафтинге, но вы упорно не хотите им заниматься, я думаю, что не одинок в том. что с удовольствием дал бы деньги вперёд под ещё не выпущенный процессор, если, к примеру. там появился бы MMU и подождал месяцев 6.
Наш опыт краудфандинга на kickstarter с проектом устройства криптозащиты Key_P1 на процессоре Multiclet P1 (которое не есть теория, а реально продается) показал, что технически сложные устройства массово средств не собирают, а ресурсы уходят в раскрутку сайта kickstarter. Тем более, такие комплектующие, как новый микропроцессор:). Шансы собрать тысячу энтузиастов по 20 тр для его выпуска равны нулю. Более реальным сегодня мы видим путь IPO (initial public offer) под проект настольного суперкомпьютера.
Блин, это же так круто — писать бекэнд под новую архитектуру…
А исходников нет?
Из тестов можно еще ГПСЧ погонять например.
А откуда взяты данные для FFT256 для ADSP-TS201S
Сам разработчик заявляет что порядка 2000 тактов нужно
http://www.analog.com/media/en/technical-documentation/application-notes/EE-218.pdf
Так же хотелось бы поподробней причины провала.
Где именно простои, как планируете их исправлять (в железе, в компиляторе)?
Приведенные в сравнении конкуренты это одно-алушные (в большинстве) процессоры, а у вас как минимум 4 клетки.
Какая производительность на одной клетке?
Сам разработчик заявляет что порядка 2000 тактов нужно
http://www.analog.com/media/en/technical-documentation/application-notes/EE-218.pdf
Так же хотелось бы поподробней причины провала.
Во-первых, это связано с отсутствием хороших архитектурно-зависимых оптимизаций в представленной версии компилятора
Где именно простои, как планируете их исправлять (в железе, в компиляторе)?
во-вторых, с неоптимальностью некоторых
аппаратных блоков данной конкретной реализации процессора Multiclet R1, которые плохо адаптированы для выполнения последовательных
Приведенные в сравнении конкуренты это одно-алушные (в большинстве) процессоры, а у вас как минимум 4 клетки.
Какая производительность на одной клетке?
Сам разработчик заявляет что порядка 2000 тактов нужноДа, вы правы: в исходную таблицу вкралась опечатка, и тысячу тактов потеряли. Должно быть 1928.
Так же хотелось бы поподробней причины провала.Поясните, пожалуйста, о чём речь в вопросе?
Где именно простои, как планируете их исправлять (в железе, в компиляторе)?По нашим очень грубым оценкам, в задачах типа CoreMark ожидать от компилятора улучшения в 1,5...2 раза не стоит, речь, скорее, может идти о 20...30%. Пример с popcnt в этом смысле, скорее, исключение, показывающее, что всякие «низкоуровневые» критичные к производительности вещи, типа FFT и FIR/IIR, на Си писать не стоит; поэтому основной прирост производительности мы планируем получить доработкой аппаратной части. Тем более, сейчас отчётливо видны недостатки данной конкретной аппаратной реализации, устранив которые, мы рассчитываем в следующей ревизии процессора ускориться в 4,5...5 раз.
Приведенные в сравнении конкуренты это одно-алушные (в большинстве) процессоры, а у вас как минимум 4 клетки.Здесь нас подстерегает один очень коварный момент: да, у конкурентов АЛУ одно, но оно содержит несколько исполнительных устройств, каждое из которых может за такт исполнять несколько инструкций. Более того, умножитель у них не входит а АЛУ, а стоит рядышком, и в «количество АЛУ» вклад не вносит. У нас же каждая клетка устроена более примитивно, а необходимый параллелизм достигается числом клеток.
Поэтому более корректно сравнивать не число АЛУ, а количество операций, которое процессор может выполнить за такт.
Какая производительность на одной клетке?Если наш FFT задумает исполняться на одной клетке, у него на это уйдёт 6008 тактов. При этом он освободит три другие клетки, которые, используя свойство динамической реконфигурации, мы прямо «на ходу» сможем параллельно направить на решение ещё трёх разных задач. Более того, так же, «на ходу» можем, при необходимости, решать задачу и на двух, и на трёх клетках.
Здесь нас подстерегает один очень коварный момент: да, у конкурентов АЛУ одно, но оно содержит несколько исполнительных устройств, каждое из которых может за такт исполнять несколько инструкций. Более того, умножитель у них не входит а АЛУ, а стоит рядышком, и в «количество АЛУ» вклад не вносит. У нас же каждая клетка устроена более примитивно, а необходимый параллелизм достигается числом клеток.
Поэтому более корректно сравнивать не число АЛУ, а количество операций, которое процессор может выполнить за такт.
Вам надо более аргументированно высказывать эту позицию, особенно рисуя таблицы сравнений, возможно это даже тянет на статью.
Вообще говоря, иногда просто тянет стукнуть кулаком по столу — врут что компилятор оптимизирует код под конкретный процессор, пусть «перекомпилирует сразу в микрокод», не насилуйте компилятор. Но тут же вспоминаешь про VLIW, который именно это и решает и понимаешь, что это совсем не то, что тебе нужно, потому что делает супер быстрыми твои собственные программы и очень неэффективными уже в следующей ревизии процессора, те что нельзя перекомпильнуть (то есть, все остальные, если мы не о OpenSource).
Поэтому мне импонирует, что в Мультиклет нет ещё одной прокладки между ISA и исполнением программы, то есть компилятору доступны «сами конвееры» и вроде как даже это особенность архитектуры.
мы планируем получить доработкой аппаратной части. Тем более, сейчас отчётливо видны недостатки данной конкретной аппаратной реализации, устранив которые, мы рассчитываем в следующей ревизии процессора ускориться в 4,5...5 раз.
Только один вопрос: куда слать бабло, которое побеждает зло?
Что касается представленной версии компилятора, то причины не очень хороших результатов тестов Coremark и popcnt, в основном, заключаются в отсутствии оптимизации циклов с учётом возможностей архитектуры, а именно, применения таких методов оптимизации, как раскрутка цикла, распараллеливание цикла, векторизация цикла.
Приятно видеть, что появилась новая статья теперь уже правда не в моем исполнении). Давно к вам не заходил, но выражаю тут бурные овации Михаилу за то, что сделал компилятор llvm примерно за полгода, не имея до этого опыта работы с llvm. Наверное это хорошо, когда один и тот же человек написал ассемблер, линкер, редактор связей, загрузчик, конверторы, компилятор llvm, это скорее плюс к надежности и скорости.
Чтобы у большинства пользователей было представление о производительности, рассмотрим ядро Cortex-M4. На данном ядре сделаны очень популярные процессоры stm32f4, процессоры фирмы nxp и многие другие. В сообществе nxp приводятся следующие результаты https://community.nxp.com/thread/327833 нас интересует строчка
С учетом процессора для теста на частоте 120 МГц получим на такт 8,3 нс. Далее 327000/8,3 = 39398 тактов.
У приведенных в статье процессоров эта процедура идет примерно в 20 раз быстрее. Для Мультиклет R1 смотрю не стали заморачиваться и оптимизировать реализацию FFT256, просто скомпилировали, что написано для P1. Для R1 мне обещали по временному распределению и с учетом новых команд 1500 тактов вместо 2350.
Но вообще изначально, чтобы где ни писалось и не говорилось мультиклеточная архитектура задумывалась как общего назначения, т.е. на последовательных операциях Мультиклет должен быть как минимум равен Cortex M4 и другим процессорам, а на распараллеливаемых операциях быть быстрее во много раз.
Стоит отличать архитектуру процессора и её реализацию, так как реализовать всё, что задумано, процесс не быстрый. R1 — вторая реализация, P1 — первая. Разница между ними не ступенька, а наверно пара этажей. И тем не менее у разработчиков Мультиклета есть целый список, часть которого опубликована на форуме, что нужно сделать для получения того же coremark или другого лапшеобразно витееватого кода как у Cortex M4 и при этом достигнув увеличения производительности на параллельном исполнении и выйгрыша в энергопотреблении.
Итак, что же нужно для полного воплощения мультиклеточной архитектуры в реальность:
1) 9 месяцев работы исключительно над ядром
2) 3 месяца на топологию, выпуск кристаллов и корпусирование их на фабрике
3) Думаю 30-40 млн руб. должно хватить по моим конечно же субъективным оценкам
Я бы посоветовал руководству Мультиклета первым шагом сделать на базе процессора R1 хорошую реализацию архитектуры, предоставив разработчикам достаточное количество времени без формата «должно быть готово полгода назад», формат «готово вчера» подойдет. А уже затем переходить к разработке больших вычислительных систем.
Желаю Мультиклету и другим отечественным разработчикам удачи и надеюсь увидеть новые статьи, и сам надеюсь найти время на публикацию своей новой статьи.
Чтобы у большинства пользователей было представление о производительности, рассмотрим ядро Cortex-M4. На данном ядре сделаны очень популярные процессоры stm32f4, процессоры фирмы nxp и многие другие. В сообществе nxp приводятся следующие результаты https://community.nxp.com/thread/327833 нас интересует строчка
— arm_cfft_radix2_f32 — 327.0 us; // real float32_t 256
С учетом процессора для теста на частоте 120 МГц получим на такт 8,3 нс. Далее 327000/8,3 = 39398 тактов.
У приведенных в статье процессоров эта процедура идет примерно в 20 раз быстрее. Для Мультиклет R1 смотрю не стали заморачиваться и оптимизировать реализацию FFT256, просто скомпилировали, что написано для P1. Для R1 мне обещали по временному распределению и с учетом новых команд 1500 тактов вместо 2350.
Но вообще изначально, чтобы где ни писалось и не говорилось мультиклеточная архитектура задумывалась как общего назначения, т.е. на последовательных операциях Мультиклет должен быть как минимум равен Cortex M4 и другим процессорам, а на распараллеливаемых операциях быть быстрее во много раз.
Стоит отличать архитектуру процессора и её реализацию, так как реализовать всё, что задумано, процесс не быстрый. R1 — вторая реализация, P1 — первая. Разница между ними не ступенька, а наверно пара этажей. И тем не менее у разработчиков Мультиклета есть целый список, часть которого опубликована на форуме, что нужно сделать для получения того же coremark или другого лапшеобразно витееватого кода как у Cortex M4 и при этом достигнув увеличения производительности на параллельном исполнении и выйгрыша в энергопотреблении.
Итак, что же нужно для полного воплощения мультиклеточной архитектуры в реальность:
1) 9 месяцев работы исключительно над ядром
2) 3 месяца на топологию, выпуск кристаллов и корпусирование их на фабрике
3) Думаю 30-40 млн руб. должно хватить по моим конечно же субъективным оценкам
Я бы посоветовал руководству Мультиклета первым шагом сделать на базе процессора R1 хорошую реализацию архитектуры, предоставив разработчикам достаточное количество времени без формата «должно быть готово полгода назад», формат «готово вчера» подойдет. А уже затем переходить к разработке больших вычислительных систем.
Желаю Мультиклету и другим отечественным разработчикам удачи и надеюсь увидеть новые статьи, и сам надеюсь найти время на публикацию своей новой статьи.
2) 3 месяца на топологию, выпуск кристаллов и корпусирование их на фабрике
1. Непонятно почему Мультиклет с таким упорством печет кристаллы, которые никому не нужны?
Оба варианта P1 и R1 гарантированно влазят не в самые большие FPGA. А для специалистов более чем достаточными являются данные по производительности в числе тактов на задачу полученные на FPGA прототипах. А максимальную частоту на FPGA так же можно экстраполировать на частоту ASIC. Но при этом цикл внесения изменений/исправлений на пару порядков быстрей.
2. Непонятны попытки сделать компилятор своими силами, при условии наличия как минимум 2-х специализирующихся на этом команд в России? Не хорошо считать чужие деньги и при всем уважении к полученному результату, но мне кажется на зарплату ушло больше чем просили бы профи. И результат у профи был бы лучше и за меньший срок.
3. Непонятно почему остановились на FFT256, есть еще классические 1К и 64К точечные преобразования, Они возможно показывают совсем другие результаты и не в лучшую сторону, так как не «влазят» во внутреннюю память кристалла (а в FPGA влезли бы....)
4. Непонятно как будут вести себя более чем 4 клетки в кристалле. Или как они же 4 шт будут решать разные задачи
Если наш FFT задумает исполняться на одной клетке, у него на это уйдёт 6008 тактов. При этом он освободит три другие клетки, которые, используя свойство динамической реконфигурации, мы прямо «на ходу» сможем параллельно направить на решение ещё трёх разных задач. Более того, так же, «на ходу» можем, при необходимости, решать задачу и на двух, и на трёх клетках.
Это же можно прям сейчас сделать? Покажите (докажите), что при решении разных задач на клетках выборка из памяти программ не будет узким местом?
Мое виденье Мультиклета было что это обычный процессор, для которого верхний уровень параллелизма (уровень не связанных функций и задач) реализуется на уровне компилятора, как для обычных многоядерных процессоров, а низкий уровень параллелизма (уровень вычисления логический функций итп) реализуется аппаратно на уровне клеток, которые сами «ищут» те инструкции которые могут быть выполнены. Но вы опять таки FFT пишите на ассемблере (параллелите вручную), и чем это отличается от классических DSP процессоров не ясно. Вообщем создается впечатление, что есть какие то фундаментальные проблемы в архитектуре.
1. Нет, не влезают. Вообще никак.
3. Разумеется, если данные приходится тащить снаружи, производительность резко падает. 1К-точечное влезет точно. Оптимизируем 256-точечное, сделаем из него 1К-точечное, и прогоним. Но не сразу.
4.
3. Разумеется, если данные приходится тащить снаружи, производительность резко падает. 1К-точечное влезет точно. Оптимизируем 256-точечное, сделаем из него 1К-точечное, и прогоним. Но не сразу.
не «влазят» во внутреннюю память кристалла (а в FPGA влезли бы....)Насчёт памяти FPGA утверждение очень спорное.
4.
Непонятно как будут вести себя более чем 4 клетки в кристалле. Или как они же 4 шт будут решать разные задачиКонкретизируйте, пожалуйста, что именно вам не понятно? В статье по ссылке тов. krufter подробно описывал, как работает реконфигурация.
Это же можно прям сейчас сделать?Без проблем. Берёте отладку с ЭрОдин, берёте пример, запускаете.
Покажите (докажите), что при решении разных задач на клетках выборка из памяти программ не будет узким местом?Не будет, и обеспечивается это структурой памяти программ. Она, мало того, что разбита на восемь вертикальных столбцов по 32 бита шириной каждый, так ещё и по длине разделена на четыре равных банка. С независимым доступом к каждому столбцу каждого банка. Так что достаточно, чтобы задачи находились в разных банках, и проблем не будет. Более того, память данных разделена аналогичным образом.
Но вы опять таки FFT пишите на ассемблереЭто нормальная практика.
параллелите вручнуюПокажите, где это? Вас смущает то, что циклы частично развёрнуты вручную? Ну так это просто помогает процессору извлекать необходимый параллелизм.
и чем это отличается от классических DSP процессоров не ясноПод «классическими», видимо, следует понимать VLIW? Так у них весь параллелизм извлекается компилятором под конкретный кристалл. И уже ни шага в сторону не сделать, двоичный код на другом процессоре не запустить, VaalKIA выше высказывался на эту тему. О том, чтобы запустить вторую (третью, четвёртую) задачу на простаивающих устройствах, лучше не думать. И о реконфигурации на ходу — даже не мечтать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Компилятор С/С++ на базе LLVM для мультиклеточных процессоров: быть или не быть?