Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Я не являюсь специалистом в схемотехнике и архитектурах процессоров, поэтому вопрос может показаться ламерским. Тем не менее, нельзя ли приспособить эту архитектуру для реализации нейрочипа? К примеру клетки рассматривать как нейроны и оптимизировать алгоритмы под них, а возможно и саму архитектуру?
Разве это не обыкновенная суперскалярная архитектура?
Мультиклеточная архитектура не является обыкновенной суперскалярной. Более подробно тут multiclet.com/docs/PO/multicellular_architecture.doc
Разница, скажем так, незначительна. Да, другая логика передачи операндов, но сути это не меняет — суперскаляр.
Грубо и очень приближённо говоря клетка мультиклеточного процессора может в чём-то быть суперскалярной, но в целом архитектура представляет совершенно другое восприятие алгоритма программы. Вся фишка в объединении процессорных блоков и то по каким принципам всё это работает. Клетка может быть чем угодно. В самом начале статьи расписано восприятие алгоритма.
И еще вот непонятен один момент… распределением блоков занимается компилятор или собственно сам процессор? т.е. скомпилированную программу с одинаковым результатом можно выполнить на 4-х клеточном или на 256-клеточном разница будет только в скорости выполнения(с учетом максимального количества задействованных клеток в программе)?
Это не супер скаляр, если только неявный. Но современные процессоры уже делают то что делает MultiClet, они могут заранее рассчитывать значения (по сути параллельно исполняемому коду), как правило это относят к Branch Prediction Unit.
Вы рассматриваете только одного из свойств архитектуры. Преимущество мультиклеточной архитектуры не останавливается на параллельно исполняемом коде. В пункте 2 в самом начале приводится 5 свойств. Ну и посмотрите сколько места обычно занимает такой предсказатель и кушает при этом.
А я не говорю, что MultiClet это плохо, просто заметил, что существующие CPU уже делают, что то подобное и без всяких MMX.
А на счёт других пунктов:
Между чем распределение? Если вы про:
Тогда это сильно сужает область применения.
Ограничений может бы и нет но производительность от количества клеток не прямо пропорционально зависима. Как минимум рано или поздно забъётся шина для широковещательных сообщений.
А на счёт других пунктов:
динамическое распределение вычислительных ресурсов;
Между чем распределение? Если вы про:
Благодаря свойству мультиклеточного процессора динамически распределять свои ресурсы, мы можем создавать системы способные выполнять задачу даже при отказах части клеток.
Тогда это сильно сужает область применения.
масштабируемость, нет ограничений на кол-во клеток.
Ограничений может бы и нет но производительность от количества клеток не прямо пропорционально зависима. Как минимум рано или поздно забъётся шина для широковещательных сообщений.
Между чем распределение?
Распределение вычислительных ресурсов. Клетка — вычислительный ресурс. Т.е. на задачу мы можем направить группу клеток. В пункте 2 расписано распределение. В пункте 4 приведен простой пример что это из себя представляет.
Благодаря свойству мультиклеточного процессора динамически распределять свои ресурсы, мы можем создавать системы способные выполнять задачу даже при отказах части клеток.
Тогда это сильно сужает область применения.
На мой взгляд расширяет.
Ограничений может бы и нет но производительность от количества клеток не прямо пропорционально зависима. Как минимум рано или поздно забъётся шина для широковещательных сообщений.
Если задача распараллеливается, то производительность зависит прямо пропорционально. Про масштабируемость планируется сделать отдельную статью.
Да, это что-то вроде если надо посчитать 8 независимых операций то при наличии 8 свободных клеток расчет будет выполнен за один раз, если окажется свободными только 4 клетки — то за два прохода, а если их 16 то работать будут только 8 а остальные простаивать, выигрыша в производительности не будет.
Оставшиеся 8 можно направить на другие дела, если обсуждать архитектуру в целом, а не конкретную реализацию, то существует теоретическая возможность сделать так, чтобы свободные клетки продолжали выборку и исполнение команд из следующих параграфов.
Но они не могут этого сделать пока не будет результата от предыдущего параграфа, ведь следующие могут зависеть от него, да скорей всего так и будет. А если работа с железом с необходимым соблюдением строгой последовательности исполнения инструкций?
Теоретически-то всю программу можно выполнить за один такт параллельно…
Теоретически-то всю программу можно выполнить за один такт параллельно…
Если есть зависимость по данным, то и в реальной жизни вы не решите эту проблему. Пока вы не построите фундамент дома, не получится поставить первый и второй этаж. В управляющем регистре PSW по умолчанию установлен бит контроля чтения и записи. Мультиклеточная архитектура не накладывает никаких запретов на выполнение инструкций в строгой последовательности.
В суперскалярной архитектуре поиск участков кода, которые можно исполнять параллельно, происходит аппаратно. В результате процессорное ядро содержит сложный блок управления, который занимает значительную площадь кристалла и потребляет энергию. В мультиклеточной архитектуре такого блока управления нет, а структура кода, обеспечивающая параллельное исполнение некоторых команд, формируется программистом (на ассемблере) или компилятором. Это также повышает возможности оптимизации кода. Ведь аппаратная схема не видит весь текст программы и поэтому некоторые решения, принимаемые ею, будут неоптимальными.
"… команды могут ссылаться на результат предыдущих команд с помощью оператора «@» ..."
Имхо, это ключевая особенность для понимания архитектуры.
Имхо, это ключевая особенность для понимания архитектуры.
Из статьи непонятно что именно умеет делать такой процессор, пока вижу только вычисления. Т.е. по большей части это именно параллельный вычислительный процессор заточенный под сложные и быстрые вычисления.
Есть ли в нем возможность ветвления алгоритма? каким образом помимо ячеек оперативной памяти осуществляется доступ к внешнему миру? Судя по всему, для практического применения этот процессор является сугубо специализированным вычислителем и нуждается в дополнительной периферии(модули связи типа UART-а, АЦП/ЦАП, внешняя EEPROM или FLASH-память, RAM, универсальные таймеры и т.д.).
Тоесть, для большинства практических применений его обязательно надо комплектовать отдельным FPGA.
Есть ли в нем возможность ветвления алгоритма? каким образом помимо ячеек оперативной памяти осуществляется доступ к внешнему миру? Судя по всему, для практического применения этот процессор является сугубо специализированным вычислителем и нуждается в дополнительной периферии(модули связи типа UART-а, АЦП/ЦАП, внешняя EEPROM или FLASH-память, RAM, универсальные таймеры и т.д.).
Тоесть, для большинства практических применений его обязательно надо комплектовать отдельным FPGA.
Статья устроена так, что в первой части мы рассказываем про устройство архитектуры. А во второй части (см. пункт 3) приводится конкретная реализация. В части 5 приведены два процессора Р1 и R1, которые выпущены на кристалле и конечно же имеют встроенную периферию UART, SPI, I2C, Ethernet, USBd, в R1 есть контроллер памяти. Процессор R1 может быть раскорпусирован в виде сборки с flash внутри.
Простите, а возможно ли на нем параллельно выполнять разные таски? Я имею в виду выполнение двух программ одновременно.
Собственно это и есть основной режим работы процессора. насколько я понял, максимум что можно запустить одновременно это столько задач сколько имеется клеток в процессоре. При этом если задач меньше, то одна задача может выполняться несколькими клетками одновременно, что несомненно ускоряет её выполнение. Причем сама задача не будет знать на скольки клетках она выполняется, там есть только одна цель — выполнить задачу а железо само решает КАК это сделать лучше всего. Тоесть в приложении не задано ни явным ни неявным способом на скольки ядрах оно будет выполняться. Возьмешь процессор с большим количеством клеток — быстрее выполнится задача, соответственно если она вообще превышает доступные «ресурсы процессора».
Еще раз перечитал статью. Все упоминания о задачах только в конетксте одного процесса. То есть программист не может запустить одновременно 2 программы. Задачи распределяются из одного куска кода.
Видимо, это из-за того что пытались показать работу нового процессора на простой задаче.
Если писать такой пример для x86 процессора, то он тоже покажется однозадачным. Только вот на x86 по большей части это псевдомногозадачность. А тут нативная многозадачность. Нет разницы между процессами и задачами кроме их взаимной связанности.
Если писать такой пример для x86 процессора, то он тоже покажется однозадачным. Только вот на x86 по большей части это псевдомногозадачность. А тут нативная многозадачность. Нет разницы между процессами и задачами кроме их взаимной связанности.
Можете запустить и две программы одновременно. Сейчас для простоты понимания к проекту из Си программ добавляется файл crt0.s и в нем можно задать реконфигурацию, например на такие-то группы клеток. Когда новые отладки придут пользователям, думаю к тому моменту реализуем разделение на клетки в Си по типу fork().
Для каждой группы можно задать свой стек и его размер. В конце апреля выйдет статья по R1.
Для каждой группы можно задать свой стек и его размер. В конце апреля выйдет статья по R1.
Начал анализировать рисунок 2. У меня возникла логическая нестыковка. Я чего-то не понял.
1. Из буфера команд клетка может взять на исполнение ЛЮБУЮ команду, для которой готовы источники и есть команда — приёмник данных? Не обязательно по порядку расположения в буфере? Тогда для третьей клетки на первом такте подходит команда с тегом 4. Для команды с тегом 3 данные ещё не готовы.
2. После выполнения команды её результат фиксируется в регистре-защёлке буфера команд или висит на выходе АЛУ, пока его не прочитают?
Судя по тому, что я понял из описания работы процессора, клетка не может выполнять команду в течение 2 или 3 тактов, если только сама операция не занимает столько времени. Клетка просто НЕ ДОЛЖНА начинать исполнять команду, для которой не готовы данные.
В первом такте заняты все клетки, во втором такте одна клетка не задействована, в третьем такте уже две клетки не задействованы, в четвёртом и пятом тактах работают по одной клетке. Незадействованные клетки в эти моменты могут выполнять другие команды из этого параграфа.
Поправьте меня, если я неправ.
1. Из буфера команд клетка может взять на исполнение ЛЮБУЮ команду, для которой готовы источники и есть команда — приёмник данных? Не обязательно по порядку расположения в буфере? Тогда для третьей клетки на первом такте подходит команда с тегом 4. Для команды с тегом 3 данные ещё не готовы.
2. После выполнения команды её результат фиксируется в регистре-защёлке буфера команд или висит на выходе АЛУ, пока его не прочитают?
Судя по тому, что я понял из описания работы процессора, клетка не может выполнять команду в течение 2 или 3 тактов, если только сама операция не занимает столько времени. Клетка просто НЕ ДОЛЖНА начинать исполнять команду, для которой не готовы данные.
В первом такте заняты все клетки, во втором такте одна клетка не задействована, в третьем такте уже две клетки не задействованы, в четвёртом и пятом тактах работают по одной клетке. Незадействованные клетки в эти моменты могут выполнять другие команды из этого параграфа.
Поправьте меня, если я неправ.
1. Клетка в R1 не ждет готовности приемника данных и может выполнить команду, которая есть в буфере команд этой клетки, т.е. допустим для группы из 4-х клеток будет следующее:
getl 1; эта команда уйдет в 0-ю клетку
getl 2; в 1-ю клетку
addl @1, @2; во 2-ю клетку
addl @1, 19052015; в 3-ю клетку
setl #0, @1; в 0-ю клетку и так далее
2. После выполнения команды её результат за 1 такт рассылается во все коммутационные устройства клеток.
Клетка исполняет только команды для которых готовы данные. Клетки могут выполнять даже команды следующих параграфов, если нет зависимости по данным, но порядок распределения команд см пункт 1.
getl 1; эта команда уйдет в 0-ю клетку
getl 2; в 1-ю клетку
addl @1, @2; во 2-ю клетку
addl @1, 19052015; в 3-ю клетку
setl #0, @1; в 0-ю клетку и так далее
2. После выполнения команды её результат за 1 такт рассылается во все коммутационные устройства клеток.
Клетка исполняет только команды для которых готовы данные. Клетки могут выполнять даже команды следующих параграфов, если нет зависимости по данным, но порядок распределения команд см пункт 1.
Наверно, мы разные рисунки смотрим. Я имею в виду Рис 2. Распределение команд по клеткам из этой статьи и последовательность команд в буфере чуть выше рисунка.
А что не так на этом рисунке?
По моему разумению содержимое диаграммы должно выглядеть так:
Такт Cell0 Cell1 Cell2 Cell3
1 get a get b get c get e
2 add @3, @2 sub @5, @3 get f — 3 mul @3, @2 — --- mul @4, @3
4 — add @2,@1 — ---
5 — --- mv g,@1
В предыдущем комментарии (18 мая 2015 в 22:19) я описал.
Такт Cell0 Cell1 Cell2 Cell3
1 get a get b get c get e
2 add @3, @2 sub @5, @3 get f — 3 mul @3, @2 — --- mul @4, @3
4 — add @2,@1 — ---
5 — --- mv g,@1
В предыдущем комментарии (18 мая 2015 в 22:19) я описал.
Нет, на диаграмме все верно. У нас с начала параграфа команды уходят по порядку в клетки, начиная с 0-й.
Т.е. если у нас есть параграф:
То команда get a уйдет на исполнение в 0-ю клетку, команда get b в 1-ю клетку, команда get c во 2-ю клетку, addl @2, @3 попадет в 3-ю клетку, get e попадет в 0-ю клетку и так далее.
Чуть больше подробностей можно посмотреть тут Вики с кратким обзором архитектуры
Т.е. если у нас есть параграф:
paragraph:
get a
get b
get c
addl @2, @3
get e
complete
То команда get a уйдет на исполнение в 0-ю клетку, команда get b в 1-ю клетку, команда get c во 2-ю клетку, addl @2, @3 попадет в 3-ю клетку, get e попадет в 0-ю клетку и так далее.
Чуть больше подробностей можно посмотреть тут Вики с кратким обзором архитектуры
Оказывается, всё совсем не так, как я предполагал. Получается, что у каждой клетки свой буфер команд и в буферах разных клеток разные команды. Раздача команд клеткам ПРИНУДИТЕЛЬНАЯ. Тогда общий буфер команд четырёх клеток имеет максимальный объём 64*4=256 команд?
В этом случае моя идея не проходит или требует серьёзного пересмотра.
Я то думал, что каждая клетка асинхронно из общего буфера выбирает готовую к исполнению команду (не обязательно по порядку) и выполняет её. При этом компилятору не надо просчитывать какую команду за какой оптимально располагать. Пример параграфа программы из п.2 — это пример НЕОПТИМАЛЬНОГО компилятора или просто вручную написанные команды. Это меня и смутило.
В этом случае моя идея не проходит или требует серьёзного пересмотра.
Я то думал, что каждая клетка асинхронно из общего буфера выбирает готовую к исполнению команду (не обязательно по порядку) и выполняет её. При этом компилятору не надо просчитывать какую команду за какой оптимально располагать. Пример параграфа программы из п.2 — это пример НЕОПТИМАЛЬНОГО компилятора или просто вручную написанные команды. Это меня и смутило.
В текущей реализации архитектуры команды уходят в клетки от начала параграфа, начиная с 0-й клетки и так далее последовательно. В общем да, буфер составит 256 команд.
Пока еще асинхронный механизм не реализовывали. Пример из п.2 для обычной демонстрации, написан вручную, цели по оптимизации не ставилось.На высоких частотах и при большем количестве клеток идею можно будет рассматривать. Но сейчас мы пока локальные изменения выписываем в рамках оптимизации текущей концепции.
Пока еще асинхронный механизм не реализовывали. Пример из п.2 для обычной демонстрации, написан вручную, цели по оптимизации не ставилось.На высоких частотах и при большем количестве клеток идею можно будет рассматривать. Но сейчас мы пока локальные изменения выписываем в рамках оптимизации текущей концепции.
Я изучил систему команд процессора, но остались непонятны некоторые моменты.
1. Команды с двумя операндами. Результат операции может быть только в буфере команды или в РОН? Могут ли две или более клеток в одном такте добавить к РОН свои слагаемые?
2. Что произойдёт, если операнд будет @0?
3. Команды условных и безусловного переходов могут работать только внутри параграфа или каким-то образом могут задать другой параграф?
4. Сколько тактов потребуется, чтобы подгрузить в буфер или кэш массив из памяти, например, 128 64-битных элемента.
5. Вопрос по окну видимости. Для 4 клеток 260 команда параграфа попадает в первый такт(вторая строка буфера команд) в нулевую клетку? Если она обращается к @8, операнд берётся от команды из 63 такта нулевой клетки?
1. Команды с двумя операндами. Результат операции может быть только в буфере команды или в РОН? Могут ли две или более клеток в одном такте добавить к РОН свои слагаемые?
2. Что произойдёт, если операнд будет @0?
3. Команды условных и безусловного переходов могут работать только внутри параграфа или каким-то образом могут задать другой параграф?
4. Сколько тактов потребуется, чтобы подгрузить в буфер или кэш массив из памяти, например, 128 64-битных элемента.
5. Вопрос по окну видимости. Для 4 клеток 260 команда параграфа попадает в первый такт(вторая строка буфера команд) в нулевую клетку? Если она обращается к @8, операнд берётся от команды из 63 такта нулевой клетки?
Надо мне оформить раздел «Часто задаваемые вопросы» по архитектуре, чтобы освоение проходило быстрее.
1. Результат большинства команд помещается в коммутатор, за исключением команд setl, wrl.
Чтобы записать значение в регистр или РОН, существует команда setl.
Например setl #0, 0x12345.
Никто не запрещает написать так:
paragraph:
setl #0, #0+12345
setl #1, #1+54321
addl @1, @2
jmp letsgo
complete
В этом случае в один такт произойдет запись в РОН 0 и РОН 1 в клетках 0 и 1.
Но вот так писать нельзя:
paragraph:
setl #0, #0 + 12345
setl #0, #0 + 54321
addl @1, @2
jmp letsgo
complete
Т.к. запись в РОН в текущей реализации мультиклеточной архитектуры проходит по концу параграфа (complete), то мы не гарантируем, что в это случае окажется в РОН 0.
В следующем процессоре мы планируем уйти от такого контроля РОНов.
2. Просто подставится 0.
3. Команды условных и безусловного переходов указывают на метку параграфа на который по complete произойдет переход(в качестве аргумента может быть и метка текущего параграфа).
4. Смотря откуда грузить и в какой буфер, вообще у нас доступ к внутренней оперативной памяти процессора (в R1 512 Кбайт) за 1 такт.
5. Оператор @ у нас означает ссылку на результат только предыдущей команды.
@8 означает, что в качестве аргумента для текущей команды будет взят результат из коммутатора для команды стоящей на 8 строчек выше. Окно видимости означает, что мы можем обратится максимум по @63, т.е. к результату 63-й команды, которая была записана 63 строчки назад.
Хотя в параграфе может быть неограниченно количество команд, например можно прокинуть результать дальше с помощью команды getl. Когда мы раскручиваем код на ассемблере, то у нас иногда бывают параграфы на 200 команд, но так в основном по методу «копировать» — «вставить» + корректировка ссылок. Хотя в ассемблере программно наверно можно сделать более удобной эту развертку.
1. Результат большинства команд помещается в коммутатор, за исключением команд setl, wrl.
Чтобы записать значение в регистр или РОН, существует команда setl.
Например setl #0, 0x12345.
Никто не запрещает написать так:
paragraph:
setl #0, #0+12345
setl #1, #1+54321
addl @1, @2
jmp letsgo
complete
В этом случае в один такт произойдет запись в РОН 0 и РОН 1 в клетках 0 и 1.
Но вот так писать нельзя:
paragraph:
setl #0, #0 + 12345
setl #0, #0 + 54321
addl @1, @2
jmp letsgo
complete
Т.к. запись в РОН в текущей реализации мультиклеточной архитектуры проходит по концу параграфа (complete), то мы не гарантируем, что в это случае окажется в РОН 0.
В следующем процессоре мы планируем уйти от такого контроля РОНов.
2. Просто подставится 0.
3. Команды условных и безусловного переходов указывают на метку параграфа на который по complete произойдет переход(в качестве аргумента может быть и метка текущего параграфа).
4. Смотря откуда грузить и в какой буфер, вообще у нас доступ к внутренней оперативной памяти процессора (в R1 512 Кбайт) за 1 такт.
5. Оператор @ у нас означает ссылку на результат только предыдущей команды.
@8 означает, что в качестве аргумента для текущей команды будет взят результат из коммутатора для команды стоящей на 8 строчек выше. Окно видимости означает, что мы можем обратится максимум по @63, т.е. к результату 63-й команды, которая была записана 63 строчки назад.
Хотя в параграфе может быть неограниченно количество команд, например можно прокинуть результать дальше с помощью команды getl. Когда мы раскручиваем код на ассемблере, то у нас иногда бывают параграфы на 200 команд, но так в основном по методу «копировать» — «вставить» + корректировка ссылок. Хотя в ассемблере программно наверно можно сделать более удобной эту развертку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мультиклеточный процессор — это что?