Comments 27
Навеяло идеями VLIW. Практика показала, что если эффективность исполнения программы будет сильно зависеть от компилятора, то как процессор общего назначения не взлетит. Переписать все ПО тяжелее, чем сделать новый процессор.
А как же М1, 2, 3..?
а что там особенного, классический суперскаляр, правда с дополнительными блоками аппаратной акселерации насущных задач: видео, нейросети.
Самое грустно что классические подходы ещё себя не изжили. Помню читал про железо М1 и сложилось впечатление что они просто научились нормально мапить память и избавили кучу узких мест от копирования, в итоге +30% к скорости памяти из воздуха. И таких моментов в целом хватает
Согласен. Иной раз думаю, что если бы ресурсы соизмеримые с разработкой нового железа бросили на разработку компиляторов, то выхлоп тоже был бы соизмеримый.
Из того, что в голову первое приходит: цикл можно развернуть в линейный код, при условии что он помещается в кэш, и получить многократное ускорение за счёт prediction. Но, слишком много условий нужно учесть. В ряде случаев можно получить потерю производительности вместо ее прироста. Как говорится, море нюансов.
Некоторые компиляторы такое реально умеют. Именно которые для конкретной платформы писались самостоятельно. У интуля был свой компилятор который просто какую-то магию раньше творил. Ты просто собираешь свой код им и у тебя +50% ФПС на интуль процессорах (и -50% на амд)
Естественно эти вещи не станут открытыми, ибо на этом можно неплохо зарабатывать. Увы и ах
Проблема не только в компиляторах, но и в том, что процессор выполняет программу не в сферическом вакууме, и всего не предусмотришь. Наиболее очевидная проблема -- конфликты при доступе к памяти. Если программе нужен доступ к области памяти, которой нет в кэше, приходится обращаться к реальной памяти, а это не только во много раз медленнее само по себе, но может натолкнуться на одновременный доступ со стороны других процессоров или периферии, использующей DMA, -- и, как следствие, выполнение операции доступа к памяти придётся задержать на довольно неопределённый срок. Если VLIW не может завершить выполнение текущего "командного слова" до тех пор, пока не будут выполнены все заданные операции, проц, очевидно, вынужден стоять и ждать завершения обращения к памяти. Классический суперскалярный проц с внеочередным выполнением в такой ситуации стоять не будет -- он продолжит выполнять команды, расположенные уже после ожидающей операции доступа к памяти, если между ними нет зависимости по данным.
Именно с этим фактором столкнулись, продвигая мультиклеточную архитектуру. Именно поэтому предложили идею взаимодействия с risc v.
Может внедрение ECS паттерна может помочь? Это реально вопрос, я еще только пытаюсь в него въехать, не знаю еще, на сколько применим в корпоративной разработке.
ESC - это инструмент для программиста, а не для процессора. От него ничего не остается пока он пройдет все этапы трансляции в машинный код. Хотя, ход мыслей правильный. На любом уровне описания алгоритма, представление его в виде зависимости между данными более эффективно, чем в виде последовательности выполняемых операций.
У меня ноут 10-ти летней давности и процессор загружен в среднем на 5%. Т.е. грузят процессор совершенно определенные алгоритмы и именно под них и нужно оптимизировать процессор. Например, в arm есть специальные сопроцессоры для обработки видео.
Именно по такой логике система команд arm в конечном итоге получилась очень далекой от минималистичной - для работы с разными алгоритмами под разные задачи.
Особенность же мультиклеточной архитектуры не в радикально новой системе команд, а в альтернативном подходе к выборке команд и промежуточных результатов, который реализует естественный параллелизм на аппаратном уровне.
Пока успех архитектуры RISC-V — это, в первую очередь, ее открытость.
...
Открытость архитектуры важна для стартапов и небольших компаний. Для компаний, которые доминируют на этих рынках, важны другие характеристики.
Мультиклеточная архитектура — принципиально новая, патентно-защищенная, не-фон-неймановская архитектура.
Подобный путь должна будет пройти и архитектура RISC-V, чтобы выйти на эти рынки.
...мы забыли про симбиоз и строим только паразитарные модели и структуры. Грустно.
Как бы ни была хороша и открыта система команд risc v, её одной мало, чтобы разработать процессор. Нужна периферия под поставленную задачу. И тут уже не так всё просто с патентованием, в том числе системы команд, которая может расширяться за счет периферии.
Вся центральная часть статьи - это описание симбиоза. Насчет грусти, да, очень грустно. особенно, когда внимательно почитаешь сайт компании SiFive и задашь себе пару вопросов (технический и маркетинговый).
Во-первых, во что декодируют команды в процессорах этой компании, если сама по себе архитектура RISC имеет предельно простые команды. Понятна логика например декодирования CISC команд в команды типа RISC в суперскалярах х86. Но RISC во что? Ответа на этот вопрос нет. Пишут, как и в настоящей статье, что все фишки обеспечиваются микроархитектурой. На этом все.
Во - вторых, компания выпускает хорошие процессоры, может быть даже лучшие из RISC-V. Но, почему-то не слышно ни о смартфонах с этими процессорами,ни о планшетах и т.д.. Первый суперскаляр они сделали в 2019. Прошло 4-года. Вопрос - чего не хватает в продвижении этих продуктов?
Существующие реализации RISC-V — это, как правило, микроконтроллеры. Например, как микропроцессор MIK32, созданный АО «Микрон».
Очень ограниченный взгляд на ситуацию. Сама классификация risc-v решений показывает, насколько разнообразен сегмент уже имеющихся процессоров.
Также довольно легко найти уже готовые процы и платы с ними под традиционную замену PC компьютеров. И здесь опережение арм назревает, рынок быстро наполнится альтернативными и более мощными системами
Немаловажным преимуществом arm здесь является унификация. Создавая разные ядра под разные задачи, они могут обеспечить какую-никакую преемственность периферии и системы команд.
В то же время когда разные разработчики делают на основе risc v устройства под разные задачи - они очень вряд ли сохранят ту минималистичную систему команд и смогут обеспечить совместимость между своими процессорами.
На данный момент количество смартфонов на arm гораздо больше смартфонов на risc v. Чтобы это изменилось, сама архитектура risc v должна будет претерпеть изменения.
Случится ли это когда-нибудь и как это будет выглядеть - покажет время.
Не ограниченный, а реалистичный. Классификация - это протокол о намерениях, а не реальные сегменты, где уже используется RISC-V.
Буду благодарен за ссылку, где можно поискать и купить мамину плату на традиционную замену в мой старенький PC компьютер . Искал, но не нашел.
Вы хорошо рассказываете про автораспараллеливание комманд в рамках одного процесса, но современные реалии таковы, что компьютеры используются в мультипрограммном, а значит и в многопоточном режиме. Это означает, что одновременно исполняются программы, которые ничего друг о друге не знают, и не имеют общую кодовую базу. Это так же означает, что, например, на 4 ядерном процессоре нельзя одновременно запустить 4 функции, выполняющие один и тот же объём работ и, таким образом, ускорить, практически, без накладных расходов, программу в 4 раза. Нет, "соседняя", программа будет работать на тех же 4 ядрах, поэтому, один экземпляр функции будет выполняться на 1 ядре, второй на 0.1 ядре, а ещё два будут ждать освобождение ресурсов (соответственно, ждать окончания исполнения такого "пакета", что бы начать выполнять следующий - контрпродуктивно, потому что ожидание может затянуться на 10x и более, тогда как ускорение возможно только в 4x, далее идут накладные расходы на диспетчеризацию и загрузку ресурсов и всё это становится очень непростым делом), именно это очень сильно осложняет параллельное программирование, а не внеочередное исполнение потока комманд.
Наскольо я знаю, в планах мультиклет, было выпустить 256 клеточный процессор, но через некоторое время, вы их изменили, на более реалистичный сколько-то ядер по 4 клетки. И тут, мы приходим к тому, что разделяя клетки на группы, вы расписываетесь в полной беспощности в работе с многопоточным ПО. Если бы было всё так хорошо с выполнением по готовности, то это выглядело бы как: 1 клетка на поток и ещё 200 клеток, мигрирующих по потокам, прибивающимися туда, где они требуются, но у вас будут ядра по 4 клетки и, соответственно, не более 4 клеток на поток (либо софтовое распределене ресурсов на уровне ОС), печалька.. :(
Если мы начали говорить о распараллеливании, то давайте начнем с определений. Слишком многогранная тема. В качестве основы предлагаю взять https://habr.com/ru/companies/intel/articles/243385/ .
Мультипрограммность и многопоточность это разные понятия (см. википедию).
В мультипрограммном режиме могут исполняться как программы, которые ничего не знают друг о друге, так и информационно-связанные программы, которые являются частью программного комплекса. В многопоточном режиме , все потоки — это части одной программы. Формирует эти потоки программист. Цель одна — оптимизировать использование ресурсов ядра, чтобы АЛУ не простаивали, а непрерывно работали.
Пример с 4-мя функциями не понял. Если можно, то, пожалуйста, изложите его поподробнее с учетом п.1..
Планы АО «Мультиклет» пропустим. Это не тема настоящей статьи. А вот по полной беспомощности можно поговорить. 256 клеток, как я понимаю — это 64 мультиклетки, каждая из которых некоторый аналог суперскалярного процессора с одновременной обработкой 4-х команд. Т.е., с точки зрения ОС, имеется 64 ядра или, если будет так угодно, 64 потока в одном ядре. Все они, естественно, связаны. Поскольку они связаны в единое целое, то для передачи данных между ними их должны идентифицировать. Присвоить каждой номер. А чтобы трафик между ними был в разумных пределах и на кристалле он не занимал много места, они собраны в кластеры по 16 шт. Всего 4 кластера. Время передачи данных внутри кластера t, между кластерами 2t. И не надо здесь искать то, чего нет в принципе.
Рассуждения насчет миграции настолько далеко от истины, что их невозможно комментировать. И вот это действительно печалька..:(
Да, конечно, я не правильно использовал понятие потоков, подразумевалось, исполнение одновременно нескольких программ, у каждой хотя бы 1 поток, что недальновидно было сокращено до "многопоточности".
У мультирограммности, нет задачи полностью утилизировать ресурсы, а стоит задача именно одновременной работы нескольких программ. Если такой возможности нет, то вы вынуженны будете пользоваться своеобразными коммбайнами, где в текстовом редакторе, будет и проигрыватель и часы и браузер интернета, но при этом программист будет специалистом только по текстовым редкторам, а графического редактра, там не будет и в помине, поэтому, переодически, вам придётся этот комбайн закрывать и открывать графический редактор. Поэтому путь, когда программы узкоспециализированы, но при этом вынуждены работать независимо, это был естественный эволюционный, однако он порождает проблемы с распределением ресурсов.
Пример, с 4мя функциями, это то, как мультирограммность влияет на исполнение кода, а в современном качестве, к этому ещё добавляются всякие малые ядра и динамическое изменение частоты процессора. Но если вкратце, то имея в своём распоряжении 4 ядра, некую функцию, отрабатывающую, в среднем, за одно время и массив данных, то простейший алгоритм параллельной обработки, ничем не будет отличаться от развёртки цикла, мы просто запускаем по функции на ядро и ждём, когда они все отработают, после начинаем следующую итерацию, такой себе синхронный подход. Очевидно, что при мутипрограммности, время исполнения функции на одном ядре, перестаёт быть адекватно прогнозируемой величиной и мы вынуждены построить сложный планировщик процессов, а к нему внутрипрограммную обвязку из семафоров, приоритетов и т.п. И тут, мы вспоминаем, что есть такая вещь, как исполнение по готовности, причём, количество обслуживающих это действо клеток может меняться динамически. Тогда, возникает идея: выделит по 1 клетке на программу, и пусть уже не ОС, а сам процессор, по готовности, отдаёт оставшиеся клетки программам, при этом, если какие-то программы находятся в ожидании, а другой нужно много ресурсов, то именно она и получит их все.
Именно на это я и пытаюсь обратить внимание, что утилизация процессора одной программой, это хорошо, но компьютер общего назначения, это прежде всего мультипрограммный агрегат, а с этой точки зрения, мультиклеточная архитектура не несёт никаких плюсов, более того, клетки придётся объединить в ядра, а это значит, что отдельную программу уже не получиться выполнить на всех клетках процессора, то есть, если он имеет 256 клеток, но в ядрах по 4 штуки, придётся довольствоваться лишь 4мя при использовании механизма "по готовности", а всё остальное будет работать так же, как и в обычных процессорах с классическими ядрами, то есть, выгоды никакой не будет.
Ну, во-первых, «мультипрограммным агрегатом» являются не только компьютеры общего назначения. Им являются все процессоры, которые способны поддерживать ОС с мультипрограммным режимом. Причем их архитектуры весьма различны. Другими словами, архитектура процессора и возможность использовать его в мультипрограммном режиме — это разные стороны одной медали — процессора. И не надо их смешивать. Как говорится: «мухи отдельно, котлеты отдельно»
Во-вторых, по поводу «плюсов». Я не буду говорить о производительности, энергопотреблении и т. п. Это все изложено выше в статье. Отмечу только один момент. Только у мультиклеточной архитектуры программный код может быть исполнен на любом количестве клеток и с полной реализацией параллелизма, который присутствует в коде. При этом задача распараллеливания, по сравнению с другими архитектурами, ни программно (VLIW), ни аппаратно (суперскаляры) не решается. Распараллеливание обеспечивается автоматически, за счет изменения способа описания алгоритма. Об этом тоже сказано в статье. Понятно, что на практике количество клеток ограничивается. Аппаратные ресурсы должны быть задействованы с максимальной эффективностью. В реальных условиях — это 4,8 или 16 клеток. Количество клеток диктуется средним количеством команд в линейных фрагментах кода. Конечно, есть задачи, которые распараллеливаются и на сотни, тысячи веток, но это уже специфические алгоритмы. Для их решения используются SIMD процессоры. Есть подобные решения и для мультиклета, но мы пока говорим о процессорах общего назначения.
>Ну, во-первых, «мультипрограммным агрегатом» являются не только компьютеры общего назначения.
Именно. Микроконтроллеры, где допустимы разные упрощения, это своеобразная ниша, для внедрения новой архитектуры, это мелковато.
>Только у мультиклеточной архитектуры программный код может быть исполнен на любом количестве клеток и с полной реализацией параллелизма, который присутствует в коде.
Только клетка, это не ядро, заявление из разряда: все регистры процессора доступны в полном объёме и в любой момент, для вычислений без обращения к памяти, а то что их надо постоянно сохранять и восстанавливать, для использования.. То же и с клетками: что толку, что они МОГУТ быть использованы, если в этот момент, они не доступны ни для какого кода, пока весь параграф полностью не будет выполнен? Если у вас ядро состоит из 16 клеток и на на этом ядре выполняется код, который требует всего 3 клетки, от этого ни жарко не холодно, потому что код, исполняемый на соседнем ядре и никакой другой тоже, не может использовать оставшиеся 13 клеток, более того, если конкретной процедуре нужно 256 клеток для исполнения, то он будет довольствовать лишь 16тью, а остальные ядра будут простаивать. Группировка клеток по ядрам, (по четыре клетки :-) ), хоронит саму суть Мультиклеточной архитектуры
Программа может использовать любое количество из 256 клеток, если это количество не более четырёх, ну - отлично!
Я думаю Вам известно, что большое количество смартфонов построено на базе гетерогенных многоядерных чипов, которые безусловно являются «мультипрограммным агрегатом», но никак не являются микроконтроллерами и никак не являются процессорами общего назначения. И, не надо обижать микроконтроллеры. С этой рыночной ниши начинали свой путь не только х86 и ARM, но и многие другие.
Если проводить аналогии с существующими процессорами, то:
Клетка — это полноценное скалярное ядро с внеочередным исполнением команд.
Мультиклетка — это суперскалярное ядро. Мультиклетка из 4-х клеток обеспечивает одновременную выборку и обработку 4-х команд. Мультиклетка из 8-ми клеток обеспечивает одновременную обработку 8-ми команд. И, соответственно, из 16 клеток — 16 команд.
Принципиальное отличие мультиклетки от суперскаляра то, что в любой момент она может быть реконфигурирована в исходные 4,8 или 16 ядер. При этом, например, одно ядро будет продолжать выполнение текущей программы, а остальным ОС поручит решение других задач. Реконфигурирование м.б. более сложным. Например, 16 клеток могут быть собраны в две 8-ми клеточные мультиклетки, или в 4 четырехклеточные, или в 8 двухклеточных. Это к вопросу использования ресурсов и это не теория. Все это было реализовано в процессоре R 1(см. сайт компании).
В классическом суперскаляре, таких возможностей нет. Во-первых они не могут одновременно обрабатывать 16 команд, максимум 8 (и то не все). Во-вторых суперскаляр, что у х86, что у ARM это единое целое, а не система простейших скалярных процессов. Следовательно, если у нас в программе есть блок с линейной последовательностью команд, то при выполнении этого блока 8-ми командный суперскаляр будет загружен на 12,5%, а мультиклет на 100%, оставив одну клетку на решение этого блока и загрузив другие клетки другими блоками.
Развитие RISC-V & мультиклеточная архитектура