Речь идет вообще-то не об этом. В этом пункте речь идет о том, какой объем работ связан с появлением новой архитектуры.
Это хорошо, что для текущей, минималистичной реализации RISC-V они сейчас есть. Но, их кто-то когда-то написал. Потратил ресурсы. И будет еще тратить. Все это надо сопровождать. Система команд RISC-V неизбежно будет меняться, если конечно авторы захотят развивать свое детище. Значит будет меняться и системный софт. И прикладной надо будет перекомпилировать, если кому-то захочется воспользоваться новыми возможностями.
У мультиклета был предшественник — синпьютер. Его разрабатывали в 2000-2004г.г. Команда была интернациональной: мы, датчане и шведы. Так вот швед, который курировал проект со стороны датчан (они финансировали проект) сказал две фразы, которые мы вспоминаем до сих пор. Первая — по поводу архитектуры синпьютера (когда принималось решение о финансировании): «Все по отдельности знакомое и известное, а все вместе — новое». А вторая, которую он сказал, представляя проект в 2003г. в Далласе на международной конференции по цифровой обработке сигналов : «Я представляю новую архитектуру — это не удивительно. Удивительно — то, что ее сделали русские». Тогда мы получили первый приз на форуме новых продуктов. Но, это лирика. Томасуло — это в первую очередь одна из возможных реализаций буфера для хранения выбранных команд, до момента готовности результатов. У нас тоже есть такой буфер, он выполняет эту же функцию, но устроен по другому. Вариантов подобных буферов достаточно много. Все процессоры с внеочередным исполнением команд их используют. У каждого свой. Просто буфер Томасуло самый известный. Теперь по вопросам:
Как происходит обработка инструкций условных переходов? Если самая первая клетка получила такую инструкцию, что происходит с инструкциями остальных, все ждут результата декодирования первой и чистятся в случае перехода?
Переход осуществляется, когда будет выбрана команд с признаком завершения параграфа (признак complete). Он говорит о том, что все команды текущего параграфа выбраны и можно выбирать команды следующего параграфа. Команда перехода может стоять в параграфе где угодно. Переход будет только по complete. Более того, в параграфе может быть сколь угодно много команд перехода, но адрес следующего параграфа должна вырабатывать только одна из них.
Как осуществляется поддержка точных исключений (precise exception)?
В Multiclet R1 — прерывание.
Финальная рассылка результатов для случая большого количества клеток выглядит супертяжёлой в железе -- она либо очень медленная, либо занимает много тактов. 2ГГц указанные в тексте, это реальная частота полученная для конструкции из 64 клеток в железе или произвольное выбранное значение для симуляции?
Нет такого понятия, как финальная рассылка. Есть понятия поток результатов и массив результатов. Поток результатов — это то, что вычислено в данный момент. Массив результатов — это последние 64 результата, которые, естественно, постоянно модифицируются по мере поступления новых. Замыкать 64 клетки в единую конструкцию — бессмысленно. Статистически длина жизни результат около 8 команд, т.е. в большинстве случаев он используется одной из восьми последующих команд. Поэтому 8 команд в суперскаляре за одну выборку, 8 клеток в мультиклетке. 2ГГц — это результат реального топологического проектирования для мультиклетки из 8 клеток.
Универсальность — это не к архитектуре. Это к реализации. Intel и NVIDIA — это одна архитектура. Фон-неймановская. Просто одна реализована применительно к скалярным данным, а вторая — к векторным. И, соответственно, SISD и SIMD.
Подход Бабаяна к dataflow требует специальные языковые конструкции, спец. компилятор, запущенный рантайм компилятора для оптимизации "управляющего воздействия" на лету и конечно спец. железа. Я читал ваши статьи, вы когда-то утверждали что вам не требуется чтобы компилятор как-то по особенному упорядочивал команды. Соответственно я полагаю что вам не требуют и спец. языковые конструкции. Это до сих пор так?
Никаких специальных языковых конструкций нам не надо! Ни раньше, ни сейчас. Мы сейчас используем LLVM в его каноническом виде. Все, что позволяет LLVM, то доступно и нам. Требование к компилятору, в части упорядочивания команд только одно: команда выдающая результат должна стоять раньше, чем команды потребляющие этот результат. И это не противоречит фон-нейману! Разница в том, что это требование не связано с очередностью исполнения, как у фон-неймана, а связано с идентификацией команд. Т.е. инструмент один, а использование его различно.
Что у вас происходит, если все клетки не получили всех необходимых данных по широковещательной рассылке и находятся все одновременно в состоянии ожидания?
Мы просто зависаем! И это хорошо! Это аварийная ситуация, которой быть не может и которая позволяет выявить несанкционированное вмешательство, если оно произошло. У нас параграф это функциональный аналог команды в фон-неймановской машине. Как известно, вмешаться в выполнение команды мы не можем, и также вмешаться в выполнение параграфа без последствий мы тоже не можем. Представьте себе четырехадресный EDVAC, у которого адрес следующей команды доступен только на этапе компиляции. Вот это мы.
В дополнение к предыдущему комментарию по поводу «своего и чужого».
Мы постоянно будем получать граблями, пока не поймем, чем они отличаются. Во-первых, чужое могут отобрать в любое время. Во-вторых оно нас просто деквалифицирует.
Рассмотрим ситуацию с RISC-V. Систему команд взяли готовенькой. М.б. взяли и готовый RTL код. Проект то открытый! Значит на эту тему свои мозги не напрягали. Тоже и с компиляторами. Все прекрасно, но нет работы — нет ни квалификации, ни опыта. Т.е. навык создания компиляторов или формирования системы команд утрачен, а это весьма не простое дело. Например, у Мультиклета развитие и совершенствование RTL кода потребовало несколько лет проектной работы и апробации на трех работающих кристаллах. RISC-V, насколько нам известно, у нас в стране пока апробирован только на одном кристалле, выпущенным на Микроне. Хватит этого или нет — неизвестно.
Но, вернемся к тому, что у нас своего при подобном заимствовании. Свое — только прикладная начинка. Прошло два-три года и реальные хозяева RISC-V решили вступить на путь коммерциализации проекта. Они без лишней огласки добавили в систему команд пару тройку новых команд, втихую доработали компиляторы и сказали, что теперь все это будет платное. И с чем мы остались? Со своим софтом? Да, и с отставанием на несколько лет, поскольку просто за время безмятежного существования разучились работать, а можем только стряпать на коленке свою ISA. В принципе для нас чужое может быть полезно только как временное решение. Чтобы закрывая насущную потребность выиграть время для своих проектов. Для решения реально существующих проблем к числу которых относятся проблемы сложности, тестирования, производительности. В их число входит и проблема кибербезопасности, которая решается в Мультиклете за счет того, что его система команд обладает «природной» вирусоустойчивостью. Но, к сожалению это временное становится постоянным.
RISC-V, как и все существующие на рынке процессоры, имеет фон-неймановскую архитектуру со всеми ее проблемами. Есть такая организация, которая называется ITRS ( сейчас IRDS). Она регулярно в своих отчетах озвучивает весь спектр проблем IT технологий. В том числе и архитектурные. И, ни одна из архитектурных проблем, не решается RISC-V. Более того, и не может быть решена, поскольку эти проблемы порождены самой фон-неймановской архитектурой и без ее замены их не решить. Т.е. в научно-техническом плане RISC-V типичная тупиковая ветвь развития.
На рынке RISC-V никогда не заменит ARM, даже частично. К ARM можно относиться по разному, но надо отдать им должное, что из RISC, как из архитектуры, они выжали все и даже еще немного больше. Даже, если они где-то и отошли от RISC, то победителей не судят. Следовательно, чтобы RISC-V хотя бы догнал ARM, ему нужно пройти этот же путь. С кем он его пройдет? Сотни тысяч программистов потратили лучшие годы своей жизни на освоение, скажем мягко очень непростой, системы команд ARM и вряд ли они готовы повторить свой подвиг. И не надо говорить о предельно простых 37 командах RISC-V. Они, если RISC-V начнет решать те же задачи, которые решал ARM, очень быстро превратятся в 137 таких же сложных как и у ARM. И где найти программистов бессребреников для этого рывка? ARM ведь не луговой цветок, который рос сам по себе. Его целенаправленно растили на грядке, которую хорошо удобряли инвестициями. Если подобные инвестиции придут в RISC-V, то неизбежно за ними придут и лицензии. Бизнес пока никто не отменял. Вряд ли ARM будет спокойно смотреть на конкурента. Что-то перекупят, что-то тихо «задушат», но в любом случае постараются вытолкать его на обочину.
Софт заимствовать не получится — система команд другая. В этом плане что RISC-V, что наш Мультиклет, что своя наколенная RISC ISA сделанная за день — все едино. Системный софт придется переписывать. Прикладной — перекомпилировать. А это деньги и большие. И мы согласны, что вкладывать их надо действительно в то, что продумано и имеет потенциал расширения. В то, что по крайней мере решает часть проблем, о которых регулярно пишет ITRS (IRDS). Согласны, что работа эта далеко не простая, но только тогда есть вероятность, что этим будет действительно пользоваться весь мир. Но, это точно не RISC-V, который решает только одну задачу — не платить АРМ за лицензии. Задача актуальная, но не из списка ITRS (IRDS) и явно не для всего мира.
Не очень понятно причем здесь топонормы, если обсуждается архитектура.
Давайте порассуждаем. Фон-неймановские процессоры часто характеризуют как процессоры, управляемые потоком команд, а так называемые потоковые процессоры, как процессоры управляемые потоком данных (data flow). Это противопоставление двух архитектурных парадигм хорошо соответствует дуальности программ (команды+данные), но является крайне неудачным их определением, так как противоречит такому базовому понятию как управление. Как известно, управление — это совокупность определенных воздействий субъекта управления на управляемый объект. Т.е. есть субъект управления - это тот, кто управляет. Есть объект управления - это тот, кем управляют. И, соответственно, есть управляющие воздействия — инструменты управления. Для начала определим, что мы будем понимать под объектом управления. Поскольку мы говорим о порядке действий, то, естественно, нас интересует каким образом формируется поток команд поступающий на исполнение. Т.е. объект управления — поток команд. В фон-неймановских процессорах поток команд жестко предопределен программой (out-of-order execution — это только на этапе исполнения) и, говорить о том, что он кем-то или чем-то управляется явно некорректно. Поэтому их можно назвать процессоры с предопределенным потоком команд. В процессорах управляемых потоком данных ситуация другая. Поток команд не предопределен. Он формируется в процессе исполнения и следовательно управляется. Вопрос в том, что является субъектом управления? В «dataflow» управляющее воздействие формирует ранее выполненная команда (это субъект), которое в виде данных (это инструмент управления) поступает очередной команде (объект). Другими словами, данные в этом варианте не кучер, а вожжи! Думается, что несколько странно говорить об управлении лошадью вожжами. При помощи вожжей — это понятно, но не вожжами, ибо непонятно, а кто такой кучер и что он делает? Если кого-то данные все таки смущают, то их из этой схемы можно легко исключить. Никто не запрещает результаты команды записать в память, а следующей команде отправить однобитовый признак готовности данных. Работать процессор будет немного дольше, но принципиально ничего не изменится. В «dataflow» субъект и объект управления совпадают — это все команды одной программы, следовательно это типичное самоуправление. Корректное определения таких процессоров — процессор с (само)управляемым потоком команд.
Теперь рассмотрим как в этой схеме выглядит мультиклеточный процессор. Выполненная команда не вырабатывает никаких управляющих воздействий, так как она не знает кто будет потребителем ее результата. Она просто раздает свой поименованный результат всем клеткам, которые записывают его в массив результатов. Обращаю внимание на то, что результат поименован. Имя — это не адрес команды и не адрес памяти. По имени, как правило, невозможно понять какая команда его сформировала. Имя позволяет разорвать непосредственную связь между командами и сформировать связь между данными (результатами). Команды, которые находятся в клетках, мониторят поток результатов и с выполняются по поступлению требуемых результатов. Т.е. их исполнение инициирует поток результатов (данных). По уму наш процессор надо было бы назвать процессор с потоком команд управляемым потоком данных или процессор с управляемым потоком данных, но к сожалению, термин «управление потоком данных» уже достаточно сильно дискредитирован бездумным использованием этого термина. Поэтому мы — Мультиклет.
По поводу ARM и MIPS — эта калиточка для нас, как известно, уже закрылась. Хотя MIPS, справедливости ради, не дожил до этого момента, его победил RISC-V.
Теперь по поводу RISC-V, на Хабре есть отличный обзор на эту тему. Вот фраза из этого обзора: «А компании, «исповедующие» RICS-V, догонят «армовцев» по производительности и начнут копировать лицензионную политику Arm Limited и продавать свои решения как IP-блоки через 5-7 лет.» И, если ничего не изменится, то для нас все то огромное количество софта будет просто недоступно. Как это все делается — я думаю объяснять не надо. Удивляет другое. Сколько раз мы будем получать по лбу граблями? Первый раз мы получили в шестидесятых годах прошлого века. Пока мы копировали IBM 360 (которую нам не продавали), чтобы получить то огромное количество софта, которое действительно было на этой системе, наши «партнеры» резко бежали вперед. Убежали так, что их почти не видно. И это негативные последствия этой идеологии, так как если ты заточен под использование чужого, то никогда не будешь иметь своего.
Да, конечно, наш IDO практически на выходе, проект очень крупный. Могу посоветовать желающим участвовать в «токенизации мультиклетов» отправлять заявки на почту micron@multiclet.com, поскольку сбор может закончиться на этапе launchpad white list и в широкие массы не попадет.
Flow-based programming это же парадигма программирования, а не архитектура процессора, так что к нам отношения не имеет.
В основе абсолютно всех аппаратных архитектур (кроме мультиклета) лежит описание алгоритма как множества связанных данными вершин графа. В «data flow» эта связь задается явно — путем указания для каждой вершины (команды) перечня команд, которым непосредственно передаются вычисленный данной вершиной результат и в качестве какого операнда он передается. Команда выполняется, когда получит все операнды и также рассылает свой результат потребителям. В фон-неймановских машинах, связь между вершинами (командами) задается неявно — путем задания принудительного порядка их исполнения. При этом считается, что результаты ранее выполненных команд получены и доступны для всех последующих команд. Передача данных опосредована, через память.
В мультиклете для описания алгоритма используются не вершины, а дуги. Соответственно, все дуги именуются и для каждой выходной дуги указываются имена входных дуг и операция, которая должна быть выполнена. Операция выполняется, когда в общий массив результатов поступают все входные дуги. Ее результат (выходная дуга), также передается в массив результатов. Поток результатов — широковещательный. Отбор требуемых дуг осуществляется операцией, которой они необходимы.
К сожалению, никаких компенсирующих мер на себе не наблюдаем (и, кстати, переход на RISK-V считаем таким же просчетом, как и базирование «отечественных» процессоров на MIPS, ARM и т.п., с такими же последствиями в близкой перспективе). Относительно майнинга и прочего - да, нас не ограничивают ничем, кроме отсутствия финансов. На всё банально не хватает каких-то 20 млн.$, так что продолжаем развивать архитектуру… Это же относится и к специзделиям, где затраты на приемку превышают разработку, а заказчик отсутствует, несмотря на большое декларируемое нам желание предприятий этих отраслей.
Рассылка не абсолютная, в текущей реализации она ограничена последними 64 результатами. Т.е. в любой момент видны всегда только эти результаты. Мьютексы, семафоры или другие подобные примитивы - это инструменты организации параллельной работы между программами, а не команд внутри программы.
Многопоточность - это использование общих исполнительных блоков, например, арифметики с плавающей точкой, несколькими отдельными задачами, каждая из которых решается в своем окружении - потоке. Доступ к этим блокам может быть организован различными методами - это не суть важно. Важно, что каждый поток имеет свой набор регистров, начиная от счетчика команд и заканчивая блоком GPR. В суперскаляре каждый поток также суперскалярный, т.е. он также одновременно выбирает и обрабатывает несколько команд, у него еще также свой предсказатель переходов и т.п. Другими словами, многопоточность - это не деление суперскаляра на скаляры (как у нас деление мультиклетки на клетки), а просто существование нескольких суперскаляров в одной общей среде. Когда мы говорим о реконфигурации, то, в первую очередь, мы говорим, что это позволяет динамически из одного сложного параллельного процессора - мультиклетки, сделать несколько простых, непараллельных - для решения преимущественно последовательных задач.
Должен напомнить, что Мультиклет — частная компания, и никакой поддержки со стороны бюджета нет.
Выпуск процессора требует огромных финансовых затрат, и средств попросту пока не хватает.
Бенчмарк затрачивает определенное число тактов на выполнение. Вне зависимости от частоты процессора это количество тактов не меняется. Но чем выше частота процессора, тем быстрее это количество тактов выполняется. Частота 2 ГГц = 2 млрд тактов в секунду. Делим количество тактов в секунду на количество тактов, затрачиваемых на бенчмарк — получаем количество бенчмарков в секунду. На Ватты делили, чтобы показать, примерно, сколько бенчмарков можно сделать на единицу энергопотребления.
По поводу количества клеток, здесь 2 основных причины, почему именно 4 клетки на ядро.
Первое: с увеличением количества клеток увеличивается количество команд, которые выбираются одновременно. Так как при ветвлении кода невозможно продолжать выборку до вычисления следующего адреса, то рано или поздно выборка просто встанет, и все клетки, которым не хватило инструкций будут простаивать. Сколько клеток можно занять — это полностью зависит от алгоритма, поэтому 4 клетки выбрались как золотая середина. К тому же, если есть сильное желание запустить алгоритм на большем количестве, реконфигурация теперь доступно на уровне ядер, т.е. например, 4 ядра могут исполнять один код — 16 клеток будут производить выборку. Масштабирование как раз линейное: если программа это один большой линейный участок, то и клеток на выборку можно отправить все 64.
Второе: в мультиклеточной архитектуре каждая клетка связана с каждой для обмена данных, чтобы когда одна клетка выполнила какую-нибудь команду, другая могла незамедлительно получить её результат. Поэтому, с увеличением количества клеток увеличивается как количество этих связей (что увеличивает площадь кристалла), так и расстояния между клетками (что увеличивает задержки). В итоге, 16 ядер (64 клетки) — это, на текущий момент, разумный предел.
Да, верно. Количество одновременно выполняемых команд у нас может быть существенно выше.
Речь идет вообще-то не об этом. В этом пункте речь идет о том, какой объем работ связан с появлением новой архитектуры.
Это хорошо, что для текущей, минималистичной реализации RISC-V они сейчас есть. Но, их кто-то когда-то написал. Потратил ресурсы. И будет еще тратить. Все это надо сопровождать. Система команд RISC-V неизбежно будет меняться, если конечно авторы захотят развивать свое детище. Значит будет меняться и системный софт. И прикладной надо будет перекомпилировать, если кому-то захочется воспользоваться новыми возможностями.
У мультиклета был предшественник — синпьютер. Его разрабатывали в 2000-2004г.г. Команда была интернациональной: мы, датчане и шведы. Так вот швед, который курировал проект со стороны датчан (они финансировали проект) сказал две фразы, которые мы вспоминаем до сих пор. Первая — по поводу архитектуры синпьютера (когда принималось решение о финансировании): «Все по отдельности знакомое и известное, а все вместе — новое». А вторая, которую он сказал, представляя проект в 2003г. в Далласе на международной конференции по цифровой обработке сигналов : «Я представляю новую архитектуру — это не удивительно. Удивительно — то, что ее сделали русские». Тогда мы получили первый приз на форуме новых продуктов. Но, это лирика. Томасуло — это в первую очередь одна из возможных реализаций буфера для хранения выбранных команд, до момента готовности результатов. У нас тоже есть такой буфер, он выполняет эту же функцию, но устроен по другому. Вариантов подобных буферов достаточно много. Все процессоры с внеочередным исполнением команд их используют. У каждого свой. Просто буфер Томасуло самый известный. Теперь по вопросам:
Переход осуществляется, когда будет выбрана команд с признаком завершения параграфа (признак complete). Он говорит о том, что все команды текущего параграфа выбраны и можно выбирать команды следующего параграфа. Команда перехода может стоять в параграфе где угодно. Переход будет только по complete. Более того, в параграфе может быть сколь угодно много команд перехода, но адрес следующего параграфа должна вырабатывать только одна из них.
В Multiclet R1 — прерывание.
Нет такого понятия, как финальная рассылка. Есть понятия поток результатов и массив результатов. Поток результатов — это то, что вычислено в данный момент. Массив результатов — это последние 64 результата, которые, естественно, постоянно модифицируются по мере поступления новых. Замыкать 64 клетки в единую конструкцию — бессмысленно. Статистически длина жизни результат около 8 команд, т.е. в большинстве случаев он используется одной из восьми последующих команд. Поэтому 8 команд в суперскаляре за одну выборку, 8 клеток в мультиклетке. 2ГГц — это результат реального топологического проектирования для мультиклетки из 8 клеток.
Может, никаких.
Универсальность — это не к архитектуре. Это к реализации. Intel и NVIDIA — это одна архитектура. Фон-неймановская. Просто одна реализована применительно к скалярным данным, а вторая — к векторным. И, соответственно, SISD и SIMD.
Никаких специальных языковых конструкций нам не надо! Ни раньше, ни сейчас. Мы сейчас используем LLVM в его каноническом виде. Все, что позволяет LLVM, то доступно и нам. Требование к компилятору, в части упорядочивания команд только одно: команда выдающая результат должна стоять раньше, чем команды потребляющие этот результат. И это не противоречит фон-нейману! Разница в том, что это требование не связано с очередностью исполнения, как у фон-неймана, а связано с идентификацией команд. Т.е. инструмент один, а использование его различно.
Мы просто зависаем! И это хорошо! Это аварийная ситуация, которой быть не может и которая позволяет выявить несанкционированное вмешательство, если оно произошло. У нас параграф это функциональный аналог команды в фон-неймановской машине. Как известно, вмешаться в выполнение команды мы не можем, и также вмешаться в выполнение параграфа без последствий мы тоже не можем. Представьте себе четырехадресный EDVAC, у которого адрес следующей команды доступен только на этапе компиляции. Вот это мы.
В дополнение к предыдущему комментарию по поводу «своего и чужого».
Мы постоянно будем получать граблями, пока не поймем, чем они отличаются. Во-первых, чужое могут отобрать в любое время. Во-вторых оно нас просто деквалифицирует.
Рассмотрим ситуацию с RISC-V. Систему команд взяли готовенькой. М.б. взяли и готовый RTL код. Проект то открытый! Значит на эту тему свои мозги не напрягали. Тоже и с компиляторами. Все прекрасно, но нет работы — нет ни квалификации, ни опыта. Т.е. навык создания компиляторов или формирования системы команд утрачен, а это весьма не простое дело. Например, у Мультиклета развитие и совершенствование RTL кода потребовало несколько лет проектной работы и апробации на трех работающих кристаллах. RISC-V, насколько нам известно, у нас в стране пока апробирован только на одном кристалле, выпущенным на Микроне. Хватит этого или нет — неизвестно.
Но, вернемся к тому, что у нас своего при подобном заимствовании. Свое — только прикладная начинка. Прошло два-три года и реальные хозяева RISC-V решили вступить на путь коммерциализации проекта. Они без лишней огласки добавили в систему команд пару тройку новых команд, втихую доработали компиляторы и сказали, что теперь все это будет платное. И с чем мы остались? Со своим софтом? Да, и с отставанием на несколько лет, поскольку просто за время безмятежного существования разучились работать, а можем только стряпать на коленке свою ISA. В принципе для нас чужое может быть полезно только как временное решение. Чтобы закрывая насущную потребность выиграть время для своих проектов. Для решения реально существующих проблем к числу которых относятся проблемы сложности, тестирования, производительности. В их число входит и проблема кибербезопасности, которая решается в Мультиклете за счет того, что его система команд обладает «природной» вирусоустойчивостью. Но, к сожалению это временное становится постоянным.
RISC-V, как и все существующие на рынке процессоры, имеет фон-неймановскую архитектуру со всеми ее проблемами. Есть такая организация, которая называется ITRS ( сейчас IRDS). Она регулярно в своих отчетах озвучивает весь спектр проблем IT технологий. В том числе и архитектурные. И, ни одна из архитектурных проблем, не решается RISC-V. Более того, и не может быть решена, поскольку эти проблемы порождены самой фон-неймановской архитектурой и без ее замены их не решить. Т.е. в научно-техническом плане RISC-V типичная тупиковая ветвь развития.
На рынке RISC-V никогда не заменит ARM, даже частично. К ARM можно относиться по разному, но надо отдать им должное, что из RISC, как из архитектуры, они выжали все и даже еще немного больше. Даже, если они где-то и отошли от RISC, то победителей не судят. Следовательно, чтобы RISC-V хотя бы догнал ARM, ему нужно пройти этот же путь. С кем он его пройдет? Сотни тысяч программистов потратили лучшие годы своей жизни на освоение, скажем мягко очень непростой, системы команд ARM и вряд ли они готовы повторить свой подвиг. И не надо говорить о предельно простых 37 командах RISC-V. Они, если RISC-V начнет решать те же задачи, которые решал ARM, очень быстро превратятся в 137 таких же сложных как и у ARM. И где найти программистов бессребреников для этого рывка?
ARM ведь не луговой цветок, который рос сам по себе. Его целенаправленно растили на грядке, которую хорошо удобряли инвестициями. Если подобные инвестиции придут в RISC-V, то неизбежно за ними придут и лицензии. Бизнес пока никто не отменял. Вряд ли ARM будет спокойно смотреть на конкурента. Что-то перекупят, что-то тихо «задушат», но в любом случае постараются вытолкать его на обочину.
Софт заимствовать не получится — система команд другая. В этом плане что RISC-V, что наш Мультиклет, что своя наколенная RISC ISA сделанная за день — все едино. Системный софт придется переписывать. Прикладной — перекомпилировать. А это деньги и большие. И мы согласны, что вкладывать их надо действительно в то, что продумано и имеет потенциал расширения. В то, что по крайней мере решает часть проблем, о которых регулярно пишет ITRS (IRDS). Согласны, что работа эта далеко не простая, но только тогда есть вероятность, что этим будет действительно пользоваться весь мир. Но, это точно не RISC-V, который решает только одну задачу — не платить АРМ за лицензии. Задача актуальная, но не из списка ITRS (IRDS) и явно не для всего мира.
Не очень понятно причем здесь топонормы, если обсуждается архитектура.
Давайте порассуждаем. Фон-неймановские процессоры часто характеризуют как процессоры, управляемые потоком команд, а так называемые потоковые процессоры, как процессоры управляемые потоком данных (data flow). Это противопоставление двух архитектурных парадигм хорошо соответствует дуальности программ (команды+данные), но является крайне неудачным их определением, так как противоречит такому базовому понятию как управление. Как известно, управление — это совокупность определенных воздействий субъекта управления на управляемый объект. Т.е. есть субъект управления - это тот, кто управляет. Есть объект управления - это тот, кем управляют. И, соответственно, есть управляющие воздействия — инструменты управления. Для начала определим, что мы будем понимать под объектом управления. Поскольку мы говорим о порядке действий, то, естественно, нас интересует каким образом формируется поток команд поступающий на исполнение. Т.е. объект управления — поток команд. В фон-неймановских процессорах поток команд жестко предопределен программой (out-of-order execution — это только на этапе исполнения) и, говорить о том, что он кем-то или чем-то управляется явно некорректно. Поэтому их можно назвать процессоры с предопределенным потоком команд. В процессорах управляемых потоком данных ситуация другая. Поток команд не предопределен. Он формируется в процессе исполнения и следовательно управляется. Вопрос в том, что является субъектом управления? В «dataflow» управляющее воздействие формирует ранее выполненная команда (это субъект), которое в виде данных (это инструмент управления) поступает очередной команде (объект). Другими словами, данные в этом варианте не кучер, а вожжи! Думается, что несколько странно говорить об управлении лошадью вожжами. При помощи вожжей — это понятно, но не вожжами, ибо непонятно, а кто такой кучер и что он делает? Если кого-то данные все таки смущают, то их из этой схемы можно легко исключить. Никто не запрещает результаты команды записать в память, а следующей команде отправить однобитовый признак готовности данных. Работать процессор будет немного дольше, но принципиально ничего не изменится. В «dataflow» субъект и объект управления совпадают — это все команды одной программы, следовательно это типичное самоуправление. Корректное определения таких процессоров — процессор с (само)управляемым потоком команд.
Теперь рассмотрим как в этой схеме выглядит мультиклеточный процессор. Выполненная команда не вырабатывает никаких управляющих воздействий, так как она не знает кто будет потребителем ее результата. Она просто раздает свой поименованный результат всем клеткам, которые записывают его в массив результатов. Обращаю внимание на то, что результат поименован. Имя — это не адрес команды и не адрес памяти. По имени, как правило, невозможно понять какая команда его сформировала. Имя позволяет разорвать непосредственную связь между командами и сформировать связь между данными (результатами). Команды, которые находятся в клетках, мониторят поток результатов и с выполняются по поступлению требуемых результатов. Т.е. их исполнение инициирует поток результатов (данных). По уму наш процессор надо было бы назвать процессор с потоком команд управляемым потоком данных или процессор с управляемым потоком данных, но к сожалению, термин «управление потоком данных» уже достаточно сильно дискредитирован бездумным использованием этого термина. Поэтому мы — Мультиклет.
По поводу ARM и MIPS — эта калиточка для нас, как известно, уже закрылась. Хотя MIPS, справедливости ради, не дожил до этого момента, его победил RISC-V.
Теперь по поводу RISC-V, на Хабре есть отличный обзор на эту тему. Вот фраза из этого обзора: «А компании, «исповедующие» RICS-V, догонят «армовцев» по производительности и начнут копировать лицензионную политику Arm Limited и продавать свои решения как IP-блоки через 5-7 лет.» И, если ничего не изменится, то для нас все то огромное количество софта будет просто недоступно. Как это все делается — я думаю объяснять не надо. Удивляет другое. Сколько раз мы будем получать по лбу граблями? Первый раз мы получили в шестидесятых годах прошлого века. Пока мы копировали IBM 360 (которую нам не продавали), чтобы получить то огромное количество софта, которое действительно было на этой системе, наши «партнеры» резко бежали вперед. Убежали так, что их почти не видно. И это негативные последствия этой идеологии, так как если ты заточен под использование чужого, то никогда не будешь иметь своего.
Да, что-то вроде того.
Да, конечно, наш IDO практически на выходе, проект очень крупный. Могу посоветовать желающим участвовать в «токенизации мультиклетов» отправлять заявки на почту micron@multiclet.com, поскольку сбор может закончиться на этапе launchpad white list и в широкие массы не попадет.
Flow-based programming это же парадигма программирования, а не архитектура процессора, так что к нам отношения не имеет.
В основе абсолютно всех аппаратных архитектур (кроме мультиклета) лежит описание алгоритма как множества связанных данными вершин графа. В «data flow» эта связь задается явно — путем указания для каждой вершины (команды) перечня команд, которым непосредственно передаются вычисленный данной вершиной результат и в качестве какого операнда он передается. Команда выполняется, когда получит все операнды и также рассылает свой результат потребителям. В фон-неймановских машинах, связь между вершинами (командами) задается неявно — путем задания принудительного порядка их исполнения. При этом считается, что результаты ранее выполненных команд получены и доступны для всех последующих команд. Передача данных опосредована, через память.
В мультиклете для описания алгоритма используются не вершины, а дуги. Соответственно, все дуги именуются и для каждой выходной дуги указываются имена входных дуг и операция, которая должна быть выполнена. Операция выполняется, когда в общий массив результатов поступают все входные дуги. Ее результат (выходная дуга), также передается в массив результатов. Поток результатов — широковещательный. Отбор требуемых дуг осуществляется операцией, которой они необходимы.
Это не Data-flow architechture. Мы не описываем процесс выполнения операций. У нас альтернативный подход - мы описываем связи между данными.
Подробнее: Введение в мультиклеточные процессоры
К сожалению, никаких компенсирующих мер на себе не наблюдаем (и, кстати, переход на RISK-V считаем таким же просчетом, как и базирование «отечественных» процессоров на MIPS, ARM и т.п., с такими же последствиями в близкой перспективе). Относительно майнинга и прочего - да, нас не ограничивают ничем, кроме отсутствия финансов. На всё банально не хватает каких-то 20 млн.$, так что продолжаем развивать архитектуру… Это же относится и к специзделиям, где затраты на приемку превышают разработку, а заказчик отсутствует, несмотря на большое декларируемое нам желание предприятий этих отраслей.
Рассылка не абсолютная, в текущей реализации она ограничена последними 64 результатами. Т.е. в любой момент видны всегда только эти результаты. Мьютексы, семафоры или другие подобные примитивы - это инструменты организации параллельной работы между программами, а не команд внутри программы.
Многопоточность - это использование общих исполнительных блоков, например, арифметики с плавающей точкой, несколькими отдельными задачами, каждая из которых решается в своем окружении - потоке. Доступ к этим блокам может быть организован различными методами - это не суть важно. Важно, что каждый поток имеет свой набор регистров, начиная от счетчика команд и заканчивая блоком GPR. В суперскаляре каждый поток также суперскалярный, т.е. он также одновременно выбирает и обрабатывает несколько команд, у него еще также свой предсказатель переходов и т.п. Другими словами, многопоточность - это не деление суперскаляра на скаляры (как у нас деление мультиклетки на клетки), а просто существование нескольких суперскаляров в одной общей среде. Когда мы говорим о реконфигурации, то, в первую очередь, мы говорим, что это позволяет динамически из одного сложного параллельного процессора - мультиклетки, сделать несколько простых, непараллельных - для решения преимущественно последовательных задач.
UMC?
И почему SMIC - нет?
Выпуск процессора требует огромных финансовых затрат, и средств попросту пока не хватает.
По поводу количества клеток, здесь 2 основных причины, почему именно 4 клетки на ядро.
Первое: с увеличением количества клеток увеличивается количество команд, которые выбираются одновременно. Так как при ветвлении кода невозможно продолжать выборку до вычисления следующего адреса, то рано или поздно выборка просто встанет, и все клетки, которым не хватило инструкций будут простаивать. Сколько клеток можно занять — это полностью зависит от алгоритма, поэтому 4 клетки выбрались как золотая середина. К тому же, если есть сильное желание запустить алгоритм на большем количестве, реконфигурация теперь доступно на уровне ядер, т.е. например, 4 ядра могут исполнять один код — 16 клеток будут производить выборку. Масштабирование как раз линейное: если программа это один большой линейный участок, то и клеток на выборку можно отправить все 64.
Второе: в мультиклеточной архитектуре каждая клетка связана с каждой для обмена данных, чтобы когда одна клетка выполнила какую-нибудь команду, другая могла незамедлительно получить её результат. Поэтому, с увеличением количества клеток увеличивается как количество этих связей (что увеличивает площадь кристалла), так и расстояния между клетками (что увеличивает задержки). В итоге, 16 ядер (64 клетки) — это, на текущий момент, разумный предел.