Сообщество

krufter_multiclet wrote:

При производстве ускорителя я думаю действительно надо думать и о внешней версии для ноутбуков.

Тогда сразу ориентируйтесь на USB 3.0, при этом стоит обратить внимание на эту технологию: USB Power Delivery
http://www.ixbt.com/news/hard/index.shtml?15/99/42
100Вт, это вполне реальный теплопакет для ускорителя и позволит подключатсья без внешнего блока питания, а у кого её нет, всегда поможет переходник.

Добра всем!
Хотелось бы спросить у ЖИВЫХ людей, не отсылающих "гуглить" и "читать документацию на сайте" (спасибо за понимание), в двух словах: в чем отличие архитектур синпьютера и мультиклеток? Синпьютер я знаю, про мультиклет доки на сайте проглядел, но не осознал, в чем "соль", в чем "прорыв". На первый взгляд - тот же синпьютер, взявший в 2003 приз в Далласе, как самый инновационный продукт... В двух словах, пожалуйста, если вам не сложно. :-)
Спасибо!

В дополнение к полугодовой давности дискуссии "за распараллеливание и циклы". Если у мультиклета (как впрочем и у синпьютера) идиосинкразия к условиям с маленьким телом - с телом, компилирующимся в меньшее количество инструкций, чем количество устройств/клеток(очень грубое описание, просьба не придираться :-) ), то "спекулятивное исполнение инструкций" - лучший выбор в данном случае (если есть возможность воплотить это в железе). За аналогами можно сходить в следующие места:
1. Итаниум - поиск по ключевому слову "спекулятивное исполнение", но зуб не дам, я плохо помню как там что
2. X86-архитектура, семейство 'cmov'-операций, выполение персылки "регистр-память" при условии выставленного какого-либо флага (конкретный флаг и направление условия специфицируется суффиксом операции: cmovne, cmovge, cmoveq итд)
3. X86, очередное расширение ISA AVX-512F, маскированная запись результата выполнения операции в <destination> в зависимости от бит-маски одного из операндов операции (для подробности смотрите соответствующий мануал, конкретнее - регистры %k)

Aha wrote:

Добра всем!
Хотелось бы спросить у ЖИВЫХ людей, не отсылающих "гуглить" и "читать документацию на сайте" (спасибо за понимание), в двух словах: в чем отличие архитектур синпьютера и мультиклеток?
В двух словах, пожалуйста, если вам не сложно. :-)

В этом же разделе, в теме про TRIPS я задавал аналогичный вопрос (а также в разделе "критика", тема: "более полное освеение достоинств"), неужели там нет ответа?!

Форум я не смотрел - я документацию люблю читать, доверия как-то к ней больше, такой условный рефлекс уже, поэтому не найдя ответа на свой вопрос, сразу обращаюсь к первоисточнику в "живом" виде - к никам *_multiclet :-)
А в документации (я про свежайший пдф) про отличие один невнятный абзац со смыслом "все то же самое, что и в синпьютере, только чуть по другому", а как по другому - не понятно.
В теме же про TRISP нет такого, я немного о другом вопрос задал: сначала был синпьютер, который потом перерос в мультиклет и мне интересно что добавилось/изменилось в "мажорной" версии архитектуры (если можно так сказать), а в TRISP-теме вопрос про "соседние" архитектуры-конкуренты

Хихи!

Цитата из раздела "кртитка" со моими ремарками:
Это было в начале "нулевых", и это был "Синпьютер"

Автором мультиклеточной (синпьютерной) архитектуры является Николай Стрельцов, это вариант MIMD-архитектуры.

Вообще говоря, эту архитектуру Николай Стрельцов разработал, работая в 2001—2004 годах в российском отделении компании SYCS ApS (Denmark) главным конструктором. Стрельцов показал архитектуру на ежегодной международной конференции по цифровой обработке сигналов «International Signal Processing Conference» (ISPC) в Далласе (США 31 марта 2003 года) от лица Копенгагенского стартапа «SYCS ApS — Synergetic Computing Systems A/S». Работа получила приз «Лучший продукт года», но энтузиазма на западе не вызвала. А вот в России бабло в тему решили вложить.

Это началось в 2010 и ловким движением инженерной мысли "Синпьютер" превращается в "Мультиклет

В 2010 году была создана ОАО «Мультиклет» на основе объединения интеллектуальной собственности Уральской архитектурной лаборатории и фонда «Инновационные технологии». Возглавил компанию Борис Зырянов, должность технического директора занял Николай Стрельцов. Компания организована по принципу «fabless company» с головным офисом в Екатеринбурге.

Но синпьютер не просто так мультиклетом стал, у него появились ништяки, о которых мысль бурлила еще в 2001-2004, и в период с 2004 по 2010 год никакой уважающий себя думающий человек мозги на стенку не повестит, поэтому я слегка оскорблен тем абзацем в свежем описании архитектуры Мультклета, в котором написано примерно следующее "все как у синпьютера, отличия каксаются памяти команд" (я ежедневно читаю архитектурные мануалы Интела и АМД, я опечален)

Aha wrote:

Форум я не смотрел - я документацию люблю читать, доверия как-то к ней больше, такой условный рефлекс уже, поэтому не найдя ответа на свой вопрос, сразу >обращаюсь к первоисточнику в "живом" виде - к никам *_multiclet :-)

Как раз на этом форуме первоисточник с никами мультиклет во всех темах и отвечает, а вот с документаций - беда, она похожа на сделанную студентами в качестве задания методом копи-паста и домысливания, но прогресс - есть.

Но синпьютер не просто так мультиклетом стал, у него появились ништяки, о которых мысль бурлила еще в 2001-2004, и в период с 2004 по 2010 год никакой уважающий себя думающий человек мозги на стенку не повестит, поэтому я слегка оскорблен тем абзацем в свежем описании архитектуры Мультклета, в котором написано примерно следующее "все как у синпьютера, отличия каксаются памяти команд" (я ежедневно читаю архитектурные мануалы Интела и АМД, я опечален)

Собственно от меня это был - сарказм, так что повторюсь:

неужели там нет ответа?!

А я-яй! :-)

Aha wrote:

2. X86-архитектура, семейство 'cmov'-операций, выполение персылки "регистр-память" при условии выставленного какого-либо флага (конкретный флаг и направление условия специфицируется суффиксом операции: cmovne, cmovge, cmoveq итд)
3. X86, очередное расширение ISA AVX-512F, маскированная запись результата выполнения операции в <destination> в зависимости от бит-маски одного из операндов операции (для подробности смотрите соответствующий мануал, конкретнее - регистры %k)

Раз уж вы постоянно читаете мануалы, можно в кратце объяснить преимущество подобного подхода и как ими пользоваться?

(Вот предикаты в АРМ мне понятны, с их помощью можно размазать тело if конструкции по коду (часто код в условных ветках часично дублируется) или избежать постоянной проверки условия в цикле, думается мне - очень полезная вещь, мне всегда не хватало "маскируемых блоков" в языках высокого уровня, выходил тем что ставил бесусловный переход и потом его затирал на nop (при инициализации процедуры восстанавливался) и цикл крутился быстро всегда)

Aha wrote:

Добра всем!
Хотелось бы спросить у ЖИВЫХ людей, не отсылающих "гуглить" и "читать документацию на сайте" (спасибо за понимание), в двух словах: в чем отличие архитектур синпьютера и мультиклеток? Синпьютер я знаю, про мультиклет доки на сайте проглядел, но не осознал, в чем "соль", в чем "прорыв". На первый взгляд - тот же синпьютер, взявший в 2003 приз в Далласе, как самый инновационный продукт... В двух словах, пожалуйста, если вам не сложно. :-)
Спасибо!

Основное отличие синпьютера и мультиклета в способе организации связи. Полное отличие описано в патенте Стрельцова.
Для синпьютера был компилятор Си99 и вы принимали в нем участие, но синпьютер был больше похож на регистровую машину и компилятор был проще.
Для мультиклета также можно сделать компилятор, чем мы сейчас и занимаемся. Все силы сейчас у нас брошены на ПО.

1. Cmov
cmovXY - это полный аналог последовательности
jXY do_copy
jmp do_no_copy
do_copy:
mov %eax, mem
do_not_copy:

Такой код получается из сишного, например, такого
If (любое условие, скольугодно сложное) {
A = value;
}

Выгоды использования - убирание из конечного бинарного исполняемого кода условных переходов. В настоящий момент предсказание переходов в чипах интел довольно хорошо реализовано, но все равно в случае неверного предсказания (а такое бывает) потери по перформансу неизбежны: приходится как минимум скидывать конвейер, отменять его работу и набирать новый - по новому адресу. Ну и самая простая лежащая на виду выгода - одна инструкция cmov занимает памяти (в том числе в кэше/в конвейере) меньше, чем аналог и 5 последовательных i386 инструкций
2. Avx-512f
То же самое, но тут речь идет о векторных операциях, об отдельных элементах вектора и об различных инструкциях - не только об операции записи в память. Скажем, цикл
int a³²;
float b⁸, c⁸;
for (int i = 0; i < 8; i++) {
If (a[i] == 1) b[i] += c[i];
}
Может быть реализован одной ассмблерной командой (в АТ/Т-нотации):
addpd %zmm1, %zmm2, %zmm1{%k1}
При условии, что в %zmm1 находится массив b, в %zmm2 - массив с, в %k1 - битовая маска, массив а

krufter_multiclet wrote:

Aha wrote:

Добра всем!
Хотелось бы спросить у ЖИВЫХ людей, не отсылающих "гуглить" и "читать документацию на сайте" (спасибо за понимание), в двух словах: в чем отличие архитектур синпьютера и мультиклеток? Синпьютер я знаю, про мультиклет доки на сайте проглядел, но не осознал, в чем "соль", в чем "прорыв". На первый взгляд - тот же синпьютер, взявший в 2003 приз в Далласе, как самый инновационный продукт... В двух словах, пожалуйста, если вам не сложно. :-)
Спасибо!

Основное отличие синпьютера и мультиклета в способе организации связи. Полное отличие описано в патенте Стрельцова.
Для синпьютера был компилятор Си99 и вы принимали в нем участие, но синпьютер был больше похож на регистровую машину и компилятор был проще.
Для мультиклета также можно сделать компилятор.

Вот я и хочу увидеть что же Николай Викторович придумал с того момента как наши дороги разошлись.
Можно сделать все, это не вопрос, я хотел бы на это посмотреть слегка изнутри, раз уж вы меня "разоблачили" (сам нарывался :-) ). (только ногами не пинайте за тот код, если он у вас "на руках", страшненький он... :-) )

Aha wrote:

Вот я и хочу увидеть что же Николай Викторович придумал с того момента как наши дороги разошлись.
Можно сделать все, это не вопрос, я хотел бы на это посмотреть слегка изнутри, раз уж вы меня "разоблачили" (сам нарывался :-) ). (только ногами не пинайте за тот код, если он у вас "на руках", страшненький он... :-) )

Синпьютер же не был в итоге реализован в железе, компилятор ваш не тестировали насколько мне известно. Сейчас есть пути формата: gcc, llvm или полностью свое. Сейчас есть компилятор Си89 на базе lcc, который работает. Повторюсь, что сейчас все силы брошены на ПО.
Если вдруг не сталкивались с нашими статьями(в них содержится описание, что внутри, просто мне сложно сравнивать с синпьютером, т.к. я видел только переходный период в FPGA):
1) http://habrahabr.ru/post/226773/#first_unread
2) http://habrahabr.ru/post/257465/#first_unread

krufter_multiclet wrote:

Aha wrote:

Вот я и хочу увидеть что же Николай Викторович придумал с того момента как наши дороги разошлись.
Можно сделать все, это не вопрос, я хотел бы на это посмотреть слегка изнутри, раз уж вы меня "разоблачили" (сам нарывался :-) ). (только ногами не пинайте за тот код, если он у вас "на руках", страшненький он... :-) )

Синпьютер же не был в итоге реализован в железе, компилятор ваш не тестировали насколько мне известно.

Модель была сделана, эмулятор - на них и работали. Про железо я тоже не знаю...

Сейчас есть пути формата: gcc, llvm или полностью свое. Сейчас есть компилятор Си89 на базе lcc, который работает. Повторюсь, что сейчас все силы брошены на ПО.
Если вдруг не сталкивались с нашими статьями(в них содержится описание, что внутри, просто мне сложно сравнивать с синпьютером, т.к. я видел только переходный период в FPGA):
1) http://habrahabr.ru/post/226773/#first_unread
2) http://habrahabr.ru/post/257465/#first_unread

Спасибо, первой половины первой статьи хватило, чтобы "догнать". Да, это хороший шаг вперед. Прям завидую по-хорошему :-)
Но вы немного кривите душой :-), что "распараллеливание" циклов на неизвестное заранее число клеток у вас идет на аппаратном уровне. Почему, потому что да, идет "распараллеливание", но компилятор все-таки должен посильно помогать: можно же такой код накомпилировать, такай датафлоу сделать, что все станет самым последовательным в мире и ничего не спасет, а можно сделать так, что каждая следующая операция будет независима по данным (в идеальной воображаемой вселенной так и есть :-) ) и все как "взлетит до небес!!! ;-)
Еще хуже будет, если пользователь на ассемблере напишет последовательно зависимый по данным код и будет удивляться, почему оно медленно работает...
Но это так...мысли в вслух...

Aha wrote:

krufter_multiclet wrote:

Aha wrote:

Вот я и хочу увидеть что же Николай Викторович придумал с того момента как наши дороги разошлись.
Можно сделать все, это не вопрос, я хотел бы на это посмотреть слегка изнутри, раз уж вы меня "разоблачили" (сам нарывался :-) ). (только ногами не пинайте за тот код, если он у вас "на руках", страшненький он... :-) )

Синпьютер же не был в итоге реализован в железе, компилятор ваш не тестировали насколько мне известно.

Модель была сделана, эмулятор - на них и работали. Про железо я тоже не знаю...

Сейчас есть пути формата: gcc, llvm или полностью свое. Сейчас есть компилятор Си89 на базе lcc, который работает. Повторюсь, что сейчас все силы брошены на ПО.
Если вдруг не сталкивались с нашими статьями(в них содержится описание, что внутри, просто мне сложно сравнивать с синпьютером, т.к. я видел только переходный период в FPGA):
1) http://habrahabr.ru/post/226773/#first_unread
2) http://habrahabr.ru/post/257465/#first_unread

Спасибо, первой половины первой статьи хватило, чтобы "догнать". Да, это хороший шаг вперед. Прям завидую по-хорошему :-)
Но вы немного кривите душой :-), что "распараллеливание" циклов на неизвестное заранее число клеток у вас идет на аппаратном уровне. Почему, потому что да, идет "распараллеливание", но компилятор все-таки должен посильно помогать: можно же такой код накомпилировать, такай датафлоу сделать, что все станет самым последовательным в мире и ничего не спасет, а можно сделать так, что каждая следующая операция будет независима по данным (в идеальной воображаемой вселенной так и есть :-) ) и все как "взлетит до небес!!! ;-)
Еще хуже будет, если пользователь на ассемблере напишет последовательно зависимый по данным код и будет удивляться, почему оно медленно работает...
Но это так...мысли в вслух...

Программа работает под любым количеством клеток, оптимальность работы программы зависит от того на какое количество клеток она ориентирована. Если бы процессор умел анализировать пользовательский код и сам раскладывать все в параллель, то это было бы автоматическое распараллеливание. Ну и любой компилятор под любой процессор должен выстраивать код как нужно, если хотим получить оптимизацию по быстродействию. В отличии от синпьютера код выстраивать параллельно ярус за ярусом в R1 не требуется для работоспособности.

У меня вопросик по прерываниям в Р1, по идее, прерывание это внештатное исполнение программы, мультиклет, насколько я понимаю, может динамически менять количество клеток под задачу, но выделять отдельно клетку под прерывание что бы она простаивало большого смысла нет, а если есть несколько прерываний, то имеет смысл разнести их поразным клеткам, а не выделять полностью все ресурсы под них последовательно, ведь это как раз не соответствует мультиклеточной архитектуре. Можно сделать так, что бы обработчики прерываний назначать конкретным клеткам, а реконфигурация происходила автоматически выделяя конкретную клетку под какое-то прерывание именно когда оно приходит, а затем возвращая её в общий пулл, то есть основной поток продолжал непрерывно выполняться на оставшихся клетках?

VaalKIA wrote:

У меня вопросик по прерываниям в Р1

Видимо, всё-такие речь идёт об "Эр 1"? Просто внешне буквы "P" (пэ латинская) и "Р" (эр русская) не различаются, а для прерываний это важно.

по идее, прерывание это внештатное исполнение программы

Ну, OK, пусть будет так.

мультиклет, насколько я понимаю, может динамически менять количество клеток под задачу, но выделять отдельно клетку под прерывание что бы она простаивало большого смысла нет, а если есть несколько прерываний, то имеет смысл разнести их поразным клеткам, а не выделять полностью все ресурсы под них последовательно, ведь это как раз не соответствует мультиклеточной архитектуре.

Сначала придётся реконфигурировать ядро, после чего у каждой группы клеток будет свой адрес обработчика прерываний и своя маска. А пока реконфигурация не произошла, никаких отдельных клеток нет, есть только неделимое 4-клеточное ядро.

Можно сделать так, что бы обработчики прерываний назначать конкретным клеткам, а реконфигурация происходила автоматически выделяя конкретную клетку под какое-то прерывание именно когда оно приходит, а затем возвращая её в общий пулл, то есть основной поток продолжал непрерывно выполняться на оставшихся клетках?

Вот нет, так не получится никак. Сам по себе акт реконфигурации -- это довольно драматичное событие, где "работает" не только железо, но и программа. И вот просто так взять работающую программу, и под ней прямо на ходу неожиданно перестроить ядро нельзя.

Вот, как-то так. Извиняюсь, что сумбурно...

VaalKIA wrote:

У меня вопросик по прерываниям в Р1, по идее, прерывание это внештатное исполнение программы, мультиклет, насколько я понимаю, может динамически менять количество клеток под задачу, но выделять отдельно клетку под прерывание что бы она простаивало большого смысла нет, а если есть несколько прерываний, то имеет смысл разнести их поразным клеткам, а не выделять полностью все ресурсы под них последовательно, ведь это как раз не соответствует мультиклеточной архитектуре. Можно сделать так, что бы обработчики прерываний назначать конкретным клеткам, а реконфигурация происходила автоматически выделяя конкретную клетку под какое-то прерывание именно когда оно приходит, а затем возвращая её в общий пулл, то есть основной поток продолжал непрерывно выполняться на оставшихся клетках?

Сделать так действительно можно, однако текущая реализация R1 (В P1 реконфигурация не предусмотрена) не предусматривает такого аппаратного механизма, чтобы это происходило автоматически. С другой стороны вы можете реализовать это программно. По приходу в группу клеток прерывания вы можете программно в первичном обработчике прерываний выделить одну из клеток группы на его обработку, вернув остальные к выполнению основной задачи. После завершения обработки прерывания клеткой, вы можете сгенерировать программное прерывание по которому вернете выделенную клетку в основную рабочую группу. Данный подход будет эффективен в случае, если обработка прерывания требует много процессорного времени, на фоне которого временные затраты на программную реконфигурацию окажутся незначительными.

y.chemodanov wrote:

Сделать так действительно можно, однако текущая реализация R1 (В P1 реконфигурация не предусмотрена) не предусматривает такого аппаратного механизма, чтобы это происходило автоматически.

Если такое можно реализовать, то мне кажется, что это очень хорошая идея. Аппаратная реконфигурация должна пройти быстро, мы не останавливаем основной поток исполнения и прерывание для него будет полностью прозрачным, что даже при очень частых вызовах не наложит на основной поток оверхед на всякие сохранения и восстановления состояния, ну и конечно, раскроется мощь клеток, ведь, к примеру, для 8 клеточного процессора, обработать одновременно 6 прерываний, да ещё не останавливая исполнение основного кода, это фактически идеал для систем реального времени. Даже более того, одно и то же прерывание, не успевшее обсчитаться, при новом сигнале будет запускаться на новой клетке, а не пропускаться, как в других архитектурах, то есть, если оно приходит не равномерно, и вдруг пришло 6 раз подряд, то все обработки начнутся вовремя и закончатся через прогнозируемое время. Вопрос только в том, насколько сложен сам процесс реконфигурирования с точки зрения железа.

С другой стороны вы можете реализовать это программно.

Программно, конечно это сделать можно, но это будет довольно обременительно для логики основного потока.

ak_multiclet wrote:

Сам по себе акт реконфигурации -- это довольно драматичное событие, где "работает" не только железо, но и программа. И вот просто так взять работающую программу, и под ней прямо на ходу неожиданно перестроить ядро нельзя.

Поскольку я не знаю внутреннюю механику, то, конечно я не представляю сам акт реконфигурации, но подозреваю, что вряд ли для каждой клетки прописано много действий наперёд и из всех клеток можно будет выбрать ту, что быстрей всего станет свободна выполнив свой ближайший локал и запретить дальнейшее планирование операций с ней, ну и грузить в неё программу прерывания. Фактически, при таком подходе даже вредно приписывать прерывания конкретным клеткам, надо наоборот указывать откуда брать вычислительные ресурсы, тогда даже несколько одновременных прерываний запустятся одновременно на нескольких клетках и каждое выберет "наименее загруженную" клетку.

VaalKIA wrote:

Аппаратная реконфигурация должна пройти быстро, мы не останавливаем основной поток исполнения и прерывание для него будет полностью прозрачным, что даже при очень частых вызовах не наложит на основной поток оверхед на всякие сохранения и восстановления состояния, ну и конечно, раскроется мощь клеток, ведь, к примеру, для 8 клеточного процессора, обработать одновременно 6 прерываний, да ещё не останавливая исполнение основного кода, это фактически идеал для систем реального времени.

Представим 8-ми клеточный процессор, в который загружен основной поток. Инструкции равномерно распределились по клеткам. Основной поток выполняется и тут возникло прерывание, которое требует освободить одну клетку, в которой находится часть инструкций основного потока. Т.е. эти инструкции нужно по-любому сохранить, а потом восстановить.
Теперь представим, что мы их временно выгрузили в память. Как подразумевается в комментарии -- идёт обработка прерывания, которая не останавливает вычисления основного потока. А в реальности оказалось, что в основном потоке есть инструкции, которые зависимы по данным от инструкций в данной клетке и весь поток встал, т.е. чтобы такое не произошло, инструкции из данной клетки надо не просто выгрузить в память, а отправить на выполнение в другие клетки, т.е. распределить по ним(в клетке буфер из 64 инструкций).

Не знаю, как точно работает реконфигурация и что будет, если реконфигурировать процессор на меньшее количество клеток для потока, который уже выполняется. Чисто теоретически, как я описал выше, это может быть не очень эффективное действие.

Все инструкции в клетке загружаются скорее всего с начала индекса, т.е. если в клетке 64 инструкции, то самые вероятные к выполнению будут те, чей индекс меньше, т.е. те, которые ближе к 0. Самые менее вероятные будут те, чей индекс ближе к 64.

Можно сделать буфер инструкций кольцевым так, чтобы инструкции основного потока загружались последовательно в сторону увеличения индекса, а инструкции прерывания загружались в сторону его уменьшения(перед инструкциями основного потока), т.е. для инструкций потока смещение относительно границы буфера будет равно +1, а для инструкций прерывания -1(и они будут смещать границу буфера). Таким образом, при загрузке инструкций прерываний, будут вытесняться менее вероятные инструкции основного потока с конца буфера. После завершения прерываний, выгруженные инструкции можно заново подгрузить из памяти, если не делать для них специальный буфер для временного хранения.
Ну и также в таком случае вероятность выполнения инструкций в начале буфера должна быть выше, т.е. если в данный момент доступны к выполнению в буфере клетки 2 инструкции по индексам 0 и 64, то первым делом клетка должна выполнить инструкцию по индексу 0. Именно данная вероятность и обеспечит наибольший приоритет выполнения инструкций прерывания перед инструкциями основного потока. Основной поток тоже будет выполняться, если у инструкций прерываний нет разрешения на выполнение из-за отсутствия данных.

Ну и также максимальное смещение границы буфера не должно превышать его размера в обе стороны, т.е. +-64. Т.е. если в клетку загрузились 64 инструкции прерывания, то смещение границы буфера стало равно -64, после этого каждая новая инструкция прерывания уже не может больше сдвигать границу буфера клетки и вытеснять инструкции. Точно так же и с инструкциями основного потока, которые будут двигать смещение к значению +64, но которые не умеют вытеснять инструкции из буфера, т.е. они двигают данную границу при появлении соответствующего свободного места.

Ещё я тут не учёл фрагментацию буфера клетки.
Ну и также не ясна ситуация со множеством прерываний.

Хотя ситуацию со множеством прерываний можно решить путём чередования загружаемых инструкций из разных прерываний или их последовательной загрузки по времени возникновения, тогда должна быть очередь прерываний.

Ответ, конечно, более или менее технический, но хотелось бы услышать мнение разработчиков процессора.
На мой взгляд динамическая реконфигурация это вещь, которая напрямую касается самой концепции мультиклеточного процессора.
Изначально посыл был такой: несколько клеток, они все вместе способны молотить поток эффективней чем конвееры и даже ядра, потому что распараллеливание получается на более мелких вещах (это преимущество перед многоядерностью/многопроцессорностью), даже там где в стадартном многоядернике просто не будет смысла раскладывать на несколько ядер, ну и при этом код организуется в параграфы, это преимущство перед конвеерами, плюс к тому же клеток в теории должно быть больше чем ядер и больше чем конвееров, поскольку пока что конвееры из разных ядер не объединяют для одной задачи, а клетки - запросто (хотя уже есть технологии где полностью виртуальные ядра, и конвееры берут именно с разных ядер для одного потока комманд).
Всё красиво, но. На самом деле, для программистов многопоточность важна так же как распараллеливание одного потока комманд, даже когда процессоры были одноядерными это было видно по многозадачным системам, и тут речь не о производительности процессора, а о произвоидтельности программирования, это логическая еденица, которая позволяет создавать программы по определённой технологии, без этого сейчас никуда. Сливать логику разных задач в один поток нет никакого смысла. А Многопоточность очень красиво ложится на многоядерность (многопроцессорность). И получается, что несмотря на мультиклеточность нужна ещё и мультипроцессорность. Очень красиво эта проблема решена в Мультиклете, с помощью реконфигурации, фактически получается многопроцессорный модуль. При этом тут же появляется необходимость в специальном арбитраже обмена данными, мы уже обсуждали комманды позволяющие работать нескольким процессорам или ядрам с общими данными, надеюсь эти комманды будут включены в Мультиклет и работать быстрее чем в x86.
Так вот, всё хорошо, всё прекрасно, но эти группы клеток, которые можно считать отдельными процессорами идут вразрез с идеологией многоклеточности, мы фактически фрагментируем Мультиклет, не давая основному потоку достаточно производительности, а для других задач избыточно держим ресурсы, которые простаивают и получаем ту же картину, что и на обычных многоядерных системах: процессор не стоит реконфигурировать потому что это времязатратно и надо будет не надолго по времени, поэтому основной поток будет использовать то, что есть. Похожая ситуация, только с обратной стороны, для многоядерников, где не стоит париться с раскладыанием маленьких участков на несколько ядер.
Единственный правильный выход, это реализовать возможность быстрой реконфигурации. То есть, если технически возможно быстро забрать клетку из группы (и добавить к группе), без значительного оверхеда и раскидать комманды на другие клетки, то это сделает Мультиклет идеальным, никакая заморозка того, что делала клетка тут не пройдёт. Если же процессор надо останавливаь полностью, затем реконфигурировать ядра и заново прогружать параграфы, это полный тырндец. Ну представьте, что мы всё-таки сделали ускоритель с овер100 клетками, вот эти 100 штук молотят тяжёлую задачу и тут приходит одно из прерываний, ну и чего, мы останавливаем все сто штук, реконфигурируем и запускаем, а потом ещё раз? Нет, спасибо - не надо. Держать по 3-4 клетки, что бы они смогли обработать каждая группа своё прерывание и уложились во фрейм, ну полчится, что из 100, 30 будут в резрве под прерывания, а 70 будут разбиты на 7 по 10, что бы обеспечить многопоточность, итого, вместо 100 клеток под основной поток, там, где это нужно, у нас будет не более 10, и там, где мжно было ограничиться одним потоком будет искуственное разделение, только что бы лишний раз не реконфигурировать проц и вытянуть производительность.
По моему, я изложил всё очень точно.