Сообщество

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

Ээ.. я вообще-то думал что это раздел "Техподдержка", это типа там, где драйвера и биосы качают..
Я бы рекомендовал переименовать во что-то более соответствующее, ну или опрос проведите и всё равно - переименуйте :-)

Вопрос про ПО остаётся: они что-нибудь сделали дельного?

О принципиальном отличии мультиклеточной архитектуры от потоковых машин, EDGE, CISC, RISC, VLIW – архитектур и их модификаций
...
повышение производительности процессора
...
RISC процессоры – сокращая объем реализуемых операций и, следовательно, время выполнения одной команды; CISC процессоры – увеличивая объем операций выполняемых одной командой и, соответственно, время, но при этом уменьшая общее количество выполняемых команд.

Чушь, сокращение объёма реализуемых операций никак не влияет на время выполнения одной комманды (ну разьве что среднее, что никак ни сказывается на производительности в лучшую сторону, ибо таких комманд надо много больше). Более того, RISC по набору комманд можно рассматривать как подмножество CISC и совершенно не следует, что используя не все комманды CISC (тупо програмно) мы получим какое-то ускорение. И даже ещё более того - со стороны программиста RISC и CISC процессоры могут обладать одним и тем же набором комманд (эмуляция "больших cisc инструкций" микропрограммами), как это произошло с Cyrix-ом (cisc)

, который когда-то купила VIA и заменила его на весьма отстойного аутсайдера Win-Chip (risc)

А вот и "оборотень", который уже нисколечко не Cyrix:

. Фишка в другом: схемотехническое решение становится проще, что позволяет добиться больших частот при приемлемом тепловыделении на ТЕХ ЖЕ топологических нормах, то есть, выполнять больше тактов и как следствие - инструкций, за то же время, чем АНАЛОГИЧНЫХ на CISC платформе. Более того, используя конвееры для RISC, вероятность параллельного исполнения выше, чем у конвееров для CISC, как за счёт элементарно большего количества инструкций в еденицу времени, так и за счёт "сплавления" эмулиремых CISC инструкций (как solid режим в RAR архиве) в одну длиннющую микропрограмму.
А у CISC да, всё верно - одна большая комманда выполнялась очень оптимально по сравнению с целой микропрограммой RISC, но на меньшей частоте всего процессора в целом и с параллельностью была вообще беда, а уж про добавление новых комманд в процессор вообще было лучше не думать. Так что MMX был первым камнем в гроб Cyrix, а уж MMXII, 3dNow, 3dnow+ и далее SSE, это уже всё из разряда фантастики, зато переключение на MMX у intel было 40 тактов, а у Cyrix 1 так, как у колосса на глиняных ногах.

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

Насколько я понимаю, для исполнения параллельно инструкций, их надо прочитать из памяти, память по традиции "однопоточна" (по той же причине, по которой risc работает на больших частотах чем cisc, память опережает частоты risc), в том плане, что скорости хватает и особо не заморачивались: параллельно два случайных байта не прочтёшь (в целом, оно уже всё жутко многоканальное, но с латентностью, всё равно беда, так что 6 каналов intel ничего не дают против обычных 2ух). А вот инструкции в процессоре - разной длинны и что бы их распараллелить, надо прочитать следующую как можно раньше, но что бы это сделать, надо знать где закончится текущая, пока же не декодируешь полностью текущую (не прочтёшь) и не узнаешь сколько операндов и т.п. с этим большие проблемы, а вот когда уже прочли, то куча времени упущена. Вот и придумали "очень длинные инструкции" со стандартной длинной

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

DF машина

Аббревиатуры вообще не расшифровываются в этом тексте (как это читать неподготовленному читателю?) вот и я уже не знаю что такое DF

Очень мало информации по TRIPS и вообще слабенький текст и очень обобщённый, на полноценное сравнение не тянет.

Ну если по полочкам всё сравнивать, то на монографию вытянет. А тут документ, в котором кратко приводится сравнение и отличия понятные для неподготовленного читателя, по аббревиатурам согласен, добавим их расшифровку, чтобы было понятнее.
DF = Dataflow.
Если нужно больше информации, то можно поискать в интернете, что заинтересовало. Цель данного документа http://multiclet.com/docs/PO/multicellular_architecture.doc показать, что мультиклеточная архитектура это не TRIPS, EDGE, RISC, CISC или VLIW.

Если нужно больше информации, то можно поискать в интернете,

Искал, по TRIPS EDGE вообще нет информации на русском в интернете (кроме анонса).
Поэтому задал вопрос тут, людям, которые кровно заинтересованы в том, что бы держать альтернативные решения конкурентов в своём кругозоре и разбираться в архитектурах, подобных или конкурирущих с Multiclet.

Соответственно, так же не понятно, может ли быть адаптирован подход в создании ПО для TRIPS к Multiclet и обратно.

Сочетанием методов отличается и проект TRIPS, архитектуру которого авторы относят к EDGE-архитектуре – явного исполнения графа потока данных

...

От традиционной DF машины они отличаются тем, что команды загружаются во все АЛУ одновременно, но процесс их выполнения как в DF машине – асинхронный, по готовности операндов.

Далее говорится про переупорядочивание комманд, в контексте RISC VLIW, можно опустить. Потом про архитектурную классификацию:

Возможны всего два способа реализации непосредственной информационной связи – адресная рассылка и широковещательная рассылка.

...

Использование адресной рассылки – ключевой принцип построения DF процессоров

...

В результате, последовательность команд в программе неупорядочена и в принципе может быть размещена в памяти программ произвольным образом.
Команда выбирается и выполняется «по готовности операндов»

...

Принцип исполнения команд потокового процессора «по готовности операндов» позволяет реализовать параллелизм «естественным» образом

Ну так и в чём отличие-то?
Вы же явно пишете: TRIPS > DF > неупорядоченные комманды > выполнение по готовности > естественный параллелизм.

Эпилог статьи: Трипса нет, это исследовательский проект, какие особенности у его DF мы не скажем, а у нашего DF особенность - широковещательная рассылка.

VaalKIA wrote:

Если нужно больше информации, то можно поискать в интернете,

Искал, по TRIPS EDGE вообще нет информации на русском в интернете (кроме анонса).

Набрал в гугл TRIPS процессор, первая ссылка на статью в википедии, там и про EDGE есть, вторая на сайт TRIPS.
Если Вы имели ввиду по-русски не написано, то много и других интересных материалов не обсуждается и не переведено.

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

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

Соответственно, так же не понятно, может ли быть адаптирован подход в создании ПО для TRIPS к Multiclet и обратно.

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

Сочетанием методов отличается и проект TRIPS, архитектуру которого авторы относят к EDGE-архитектуре – явного исполнения графа потока данных

...

От традиционной DF машины они отличаются тем, что команды загружаются во все АЛУ одновременно, но процесс их выполнения как в DF машине – асинхронный, по готовности операндов.

Далее говорится про переупорядочивание комманд, в контексте RISC VLIW, можно опустить. Потом про архитектурную классификацию:

Возможны всего два способа реализации непосредственной информационной связи – адресная рассылка и широковещательная рассылка.

...

Использование адресной рассылки – ключевой принцип построения DF процессоров

...

В результате, последовательность команд в программе неупорядочена и в принципе может быть размещена в памяти программ произвольным образом.
Команда выбирается и выполняется «по готовности операндов»

...

Принцип исполнения команд потокового процессора «по готовности операндов» позволяет реализовать параллелизм «естественным» образом

Ну так и в чём отличие-то?
Вы же явно пишете: TRIPS > DF > неупорядоченные комманды > выполнение по готовности > естественный параллелизм.

Эпилог статьи: Трипса нет, это исследовательский проект, какие особенности у его DF мы не скажем, а у нашего DF особенность - широковещательная рассылка.

У нас процессор не DataFlow машина и как я говорил не TRIPS. Как будет время подумаю над табличкой со сравнением архитектур, чтобы было просто, как некое дополнение к документу.

Тогда и стековые процессоры не забудьте:
Например, Муровский на 144 ядра.

http://geektimes.ru/post/133291/