В продолжение темы о русской электронике...

[Вадим Семенов]

Так сделаноунас известный желтый (пропагандитский) сайт. Цитировать его признак дурного тона и несолидности собеседника.

Сделаноунас - просто набор перепечаток самых разных источников.
Как и любой агрегатор воспринимать его можно по-разному, но ничего "жёлтого" или "пропагандисткого" там нет.
признак дурного тона - навязывать всем своё своеобразное мнение, выдавая его за абсолютную истину (что, кстати, и является признаком "желтизны").

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

Во всяком случае в чем достижение пока совершенно непонятно.

Непонятно ВАМ. ВАМ лично - непонятно. Это ВАШИ проблемы, решайте их самостоятельно. Причём тут мужики-то?

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

А всё остальное Вами сказаное - и есть пропагандисткая шелуха в стиле "я ничего не понимаю, но мнение своё выскажу".
Это неправильно.

Так пояснили бы мне темному, в чем собственно заключается  невероятное достижение. Неужели в том, что заказали 4 готовых ядра на заказной микросхеме?   А то у вас прям как на сайте сделаноунас - художественного свиста много, а конкретики никакой.

[Вадим Семенов]

Вы разучились отделять глянцевую упаковку от содержимого.
Мне лень искать, но тут НЕЧЕГО публиковать, потому что это дается в приличном ВУЗе в виде максимум курсовой, даже не диплома.

Если вы чего-то не увидели - это не значит, что этого не существует.

2003 – synputer gained a prize in nomination "The best product of the Year" at the forum of new products presented at Annual International Signal Processing Conference in Dallas, USA.

А какие еще претенденты были? Ну что оценить уровень конкурентов на сей приз. А пока можно лишь заключить, что сия гениальная поделка существует как минимум с 2003 года. Очень странно, что она за прошедшее без малого десятилетие не заполонила весь электронный мир, а так и осталась в безвестности. Пока известный пропагандисткий сайт в 2012 не вытащил ее забвения и не объявил очередным невероятным достижением.  

Кстати, в той же википедии, которую вы процитировали прочел: MultiClet Corp. is resident of Skolkovo innovation center. Что также свидетельствует в пользу пустышечного пиарно-баблопопильного проекта.

[zyxman]

Вы разучились отделять глянцевую упаковку от содержимого.
Мне лень искать, но тут НЕЧЕГО публиковать, потому что это дается в приличном ВУЗе в виде максимум курсовой, даже не диплома.

Если вы чего-то не увидели - это не значит, что этого не существует.

2003 – synputer gained a prize in nomination "The best product of the Year" at the forum of new products presented at Annual International Signal Processing Conference in Dallas, USA.

Почитайте ВНИМАТЕЛЬНО то что я выделил цветом.
Так, на всякий случай, напомню, что я говорю про ОБЩИЙ случай, а Signal Proccessing (для нашего случая вероятно лучший перевод Цифровая Обработка Сигналов) это ЧАСТНЫЙ случай - так понятно?

- Так, на всякий случай, первый промышленно производимый VLIW был как раз DSP, и начал производиться ЕМНИП еще в середине 1990-х и он такие там чудовищные показатели и производительности и потребления показывал, что лучшие универсальные процессоры даже не курили а просто лежали кверху лапками;
А средние (не топовые!) FPGA как раз на задачах DSP, где-то с Y2K, обставляли лучшие суперскаляры в разы - там был такой примерно расклад, что на DSP задаче платка с FPGA ценой 200$, питающаяся от эквивалента зарядки мобильника, жестко, с сухим счетом уделывала 4-процессорный сервак на PentiumPro, питающийся чуть не Киловаттом.

А сколько было всяческих хитрых реализаций железа для проблем DSP, я даже затрудняюсь сказать - сам лично видел не меньше десятка диковинных зверушек живьем, и читал несколько десятков Whitepapers по темам, которые реализовывались в единичных экземплярах.
Но универсальным решением никто из них не стал - самые лучшие случаи это Cell, GPU и MMX/SSE/3D-Now.

Кстати, даже интересно, вот вы вроде как над DSP задачами работаете - почему про тот-же Cell я тут ликбез устраиваю а не вы?

[Татарин]

Вы разучились отделять глянцевую упаковку от содержимого.
Мне лень искать, но тут НЕЧЕГО публиковать,

Тогда откуда масса публикаций по EPIC?
Или тем же - если стряхнуть пыль - транспьютерам? Неужто идея транспьютеров кажется менее очевидной?

Нет, это не очевидно. Посчитайте на калькуляторе несколько случаев разной длины блока (скажем, начиная от 3 команд - не стоит надеяться что в общем случае будет сильно больше)

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

Ну в самом деле, неужели вы думаете, что инженеры и в Intel дураки и в HP тоже, и в AMD, VIA, IBM и в прочих (если хотите я тут дам список более десятка процессоростроительных фирм) не заметили такую простую вещь?

Вы опять за своё "улучшения невозможны, ибо если б они были бы возможны, то уже были бы сделаны" почти (С).

? Сплошь и рядом люди не замечают простые вещи.
Потому что простых вещей много, а вот какая из них даст выигрыш - дело неочевидное.

Вообще проблема обсуждения в том, что вы сразу перепрыгиваете на VLIW, а я предложил обсудить УЧЕБНЫЙ случай, а именно, ПРОСТОЕ процессорное ядро, для простоты взять канонический load-store RISC

Хорошо. Давайте рассмотрим простой RISC. Что Вы хотите показать на его примере?
Можете расписать Вашу мысль детально?

[Татарин]

Но универсальным решением никто из них не стал - самые лучшие случаи это Cell, GPU и MMX/SSE/3D-Now.

Если отбросить то, что DSP-задачи алгоритмически проще задач ПОЗ, то можно и нужно ещё вспомнить, что экспериментировать со спец-процессорами ЦОС куда проще.

Это область, где куда меньше заботятся о совместимости и куда больше об абсолютной производительности. И там классные спецы. Именно там сейчас обкатываются идеи, которые затем приходят на ЦП ПК.

Собссно, мы ведь до сих пор используем х86 не потому, что CISC рулит или х86 - это такой невероятный, потрясающий, незаменимый набор команд, просто верх совершенства.
Нет. Просто переход на другую архитектуру слишком уж дорог. А переход на другую парадигму программирования (например, в виде MPP) - настолько дорог, что лишь единицы-энтузиасты используют мощь видеопроцессоров для решения не-игровых задач.

Хотя там и совместимость, и стоимость, и, блин, какое-то чудовищное, подавляющее превосходство числомолки над ПОЗ.
Просто это очень дорого - потеря совместимости для программ, для средств разработки и для программистов (последнее - самое дорогое).

[Татарин]

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

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

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

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

Так пояснили бы мне темному, в чем собственно заключается  невероятное достижение.

?!
Я пояснил Вам, тёмному, что люди сделали. А Вы снова задаёте этот вопрос.

Хорошо. Ещё раз. Люди разработали интересную архитектуру и довели её до железа. Если для Вас это рядовое дело, как позавтракать и посрать, ну, могу только позавидовать.
В остальном мире  это даже неплохому коллективу стОит многомесячного труда.

А то у вас прям как на сайте сделаноунас - художественного свиста много, а конкретики никакой.

А зачем Вам конкретика? Это ведь не мешает Вам уверенно высказывать своё мнение?

Да, безусловно, это Ваше мнение очень ценно. Ни в коем случае не художественный свист. Пожалуйста, продолжайте, мы с интересом ждём от Вас дальнейших описаний, чего Вы не поняли и риторических вопросов в духе "я, всё ж таки, д'Артаньян".

[zyxman]

Нет, это не очевидно. Посчитайте на калькуляторе несколько случаев разной длины блока (скажем, начиная от 3 команд - не стоит надеяться что в общем случае будет сильно больше)

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

Вам череп не жмет?

Ладно.
В том и дело, что есть информация (упрощенно), что практически только для задач DSP (ЦОС - mp3, avi, также сюда подпадает jpeg HD разрешения) имеют место блоки команд, которые повторяются по миллиону раз (ну там например для каждого пиксела сделать какое-то вычисление над группой соседних пикселов), но там обычно не очень сложные вычисления, на уровне S = SUM(A*X(I)+B*Y(k)), для прямоугольной матрицы, хотя конечно эти вычисления можно сделать циклом а можно разложить линейно (и уменьшить потери от переходов и заодно дать возможность эти линейки считать независимо), и это как раз вот то место которое и на FPGA реализуют, и на GPU, когда сильно надо.
Вторая группа хорошо исследованных алгоритмов - управление - там просто по разным источникам от каждой 5-й до каждой 15-й команды условный переход, то есть блоки совсем маленькие, и кстати там RISC плохо себя показывают.
А для типичных офисных задач чаще всего применяются операции поиска и сортировки, которые сводятся к крохотному ядру с кучей условных переходов внутри, и тоже блоки получаются крохотные.
Даже элементарный момент: ведь не случайно у процессоров общего назначения обычно довольно малое число регистров (это кстати классическая задачка из ВУЗовской контрольной) - просто элементарно, если у нас блок алгоритма состоит из десятка команд, то ему не нужно больше десятка регистров - нужно объяснять почему или сами поймете? - Собственно, есть RISC у которых 32 регистра и даже 64 и 128, но они чаще всего применяются как раз в частных задачах, где многие регистры используются для хранения глобальных переменных или даже констант, чтобы их из памяти не читать и не тратить на это пропускную способность шины.
И да, скорость памяти давно уже настолько отстает от скорости процессоров, что если-бы были соответствующие алгоритмы, уже был-бы смысл и 1000-регистровые монстры делать, но не делают

Вот так сложилось, что для общего случая сложно найти независимые группы команд сильно больше 3-5, ну пусть 15 команд, и конечно-же, разработчики Итаниума об этом знают.
Второй момент, что у RISC обычно длина команды фиксированная, как раз для упрощения декодера.
Соответственно, если у нас средняя длина команды допустим 2 байта (именно так у ARM), и делаем выделение блока парой команд-тегов, то у нас на 5 командах будут 40% потери (2 команды тега на 5 полезных команд), а на 3 командах будут потери 67%.
Делать теги битами внутри команды не всегда получится, либо прийдется делать 32-битовые командные слова (24 бита плохо, тк нужно выравнивать), и вот надеюсь что на этой фразе вы уже догадались, что так и просится эти 3-5 командные параграфы утрамбовать в сверхдлинную команду VLIW - там всё получается действительно красиво.

[Вадим Семенов]

Источник же - сайт разработчика.

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

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

Так пояснили бы мне темному, в чем собственно заключается  невероятное достижение.

?!
Я пояснил Вам, тёмному, что люди сделали. А Вы снова задаёте этот вопрос.

Хорошо. Ещё раз. Люди разработали интересную архитектуру и довели её до железа.

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

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

[zyxman]

Собссно, мы ведь до сих пор используем х86 не потому, что CISC рулит или х86 - это такой невероятный, потрясающий, незаменимый набор команд, просто верх совершенства.
Нет. Просто переход на другую архитектуру слишком уж дорог. А переход на другую парадигму программирования (например, в виде MPP) - настолько дорог, что лишь единицы-энтузиасты используют мощь видеопроцессоров для решения не-игровых задач.

Да, вы вобщем верно говорите про совместимость, но нужно говорить именно про совместимость технологии разработки - она идеально вылизана для x86, более-менее подходит для RISC и даже где-то для VLIW, но уже EPIC требует очень существенной научной работы, на которую даже Интела с Хьюлетом пока не хватило.

Кстати, вспомнил еще один критичный момент:
все современные компьютерные системы характеризуются параллельной (псевдо-параллельной) работой множества программ с разделяемым множеством системных ресурсов (память полностью разделяема, а регистры и мегагерцы программы используют поочередно), так вот проблема RISC, что они сильно заточены на малый процент обмена с памятью, то есть программа работает в основном в регистрах, а для регистров систему защиты еще не придумали, и кстати то же и с SIMD и GPU - там с защитой совсем плохо.

Вот кстати, хороший вопрос, а как вы себе представляете работу субжа в системе с разделением ресурсов?
- Я к тому, что если переключать задачу, то ведь он должен будет где-то сохранить всё промежуточное состояние , которое должно быть очень немаленьким даже для 4 выч блоков, а для скажем 64 ВБ вообще гигантским, и это переключение будет хорошо съедать пропускную способность шин.

[Татарин]

В том и дело, что есть информация (упрощенно), что практически только для задач DSP (ЦОС - mp3, avi, также сюда подпадает jpeg HD разрешения) имеют место блоки команд, которые повторяются по миллиону раз

Это очевидно, как и выигрыш на задачах ЦОС для мультиклеток в сравнении с склассическим суперскаляром. Сойдёмся на том, что тут процессор общего назначения получит какой-то выигрыш за счёт того (аудио-, видео- кодеки, кастомный процессинг медиа), что ещё не вынесли в спецвычислители и пойдём далее.

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

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

Вот эти блоки и будут раскидываться по клеткам. Ровно точно так же, как сейчас раскидываются по обычным ИУ. Вы же не будете уверять, что вся эта суперскалярность - сплошная глупость, и ненешний процессор не загружает более одного ИУ за раз?
Ну так вот здесь получается то же самое, только наш процессор получает прямые подсказки от компилятора по наилучшей загрузке ИУ и связях между командами.
Уже только то, что нам больше не нужно спекулятивное исполнение в блоках (связи нам даны заранее и мы легко получаем правильный порядок исполнения предложения), экономит нам кучу ресурсов.

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

Речь же идёт о сравнении архитектур процессоров. Так вот скажите: а чем мультиклет тут будет _хуже_ любой другой архитектуры?
При удаче (как только код позволяет выделить блок независимых команд) он лучше. При неудаче он работает столь же хорошо (или столь же плохо - как угодно), как и любая другая архитектура.

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

Даже элементарный момент: ведь не случайно у процессоров общего назначения обычно довольно малое число регистров

Не случайно. Архитектуры с большим количеством регистров были. Оказались не нужны - по причине, которую назвали Вы - раз.
И два - то же самое СОЗУ оказалось проще (и не теряя совместимости) использовать в форме кэша. С современными инструкциями, которые напрямую могут управлять prefetch и содержимым кэша вообще разница оказывается чисто синтаксической.
Так зачем мне иметь, скажем, 128 регистров, когда я могу иметь 32000 слов в кеше первого уровня с почти тем же таймингом, не загромождая 100% инструкций лишними битами адресации регистрового пула?

И да, скорость памяти давно уже настолько отстает от скорости процессоров, что если-бы были соответствующие алгоритмы, уже был-бы смысл и 1000-регистровые монстры делать, но не делают

Делают-делают. Посмотрите современный код.

Вот так сложилось, что для общего случая сложно найти независимые группы команд сильно больше 3-5, ну пусть 15 команд, и конечно-же, разработчики Итаниума об этом знают.

Конечно.

И разработчики Итаниума вынуждены ориентироваться на минимальное количество команд в блоке. Потому что наличие nop-ов даже в 10% случаев в Итаниуме просадит его практическое быстродействие на те же 10%. Эти nop-ы нужно же выбрать и выкинуть, а раз доктор сказал, что исполняем по гигаслову в секунду, то мы ровно столько и исполняем, пусть даже те слова наполовину nop-ами забиты!

Понимаете, в чём прелесть мультиклета?
В его случае мы не паримся проблемой размера блока, для нас маленький блок независимых команд означает лишь простаивающие ИУ, но вот поток команд мы в любом случае используем на 100%. Что сумел нам скомпоновать компилятор, мы используем все. Там нет nop-ов, нет совсем. Поэтому мы можем поставить вместо 4 клеток 8, получив при этом прирост, пусть хоть на 20% на офисных приложениях, но прирост. Пусть мы не выигрываем на плохих участках в сравнении с обычным суперскаляром, но мы ничего и не теряем. Но на каждом удобном участке берём своё, отъедая выигрыш у традиционных процов.

А вот у Итаниума с увеличением слова (и ИУ) зависимость от удобности кода и качества компилятора растёт чудовищно быстро. Поэтому-то и остановились на трёх командах в слове (против 4-х у PA9000): трезво оценили требования современного кода и возможности компилятора.

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

И о переключении контекста. Считается, что переключение задач можно делать 1 раз в 2мс без заморок для пользователя. На частотах в сотни МГц-единицы ГГц это заведомо много больше времени выполнения параграфа, то есть, все промежуточные результаты в коммутаторе заведомо теряют актуальность и остаётся лишь сохранить при переключении регистровый пул.
Не проблема. Более того: ОС получает естественную разметку и подсказки о том, где переключение контекста будет наиболее удобно для задачи.

[Татарин]

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

И какое это имеет отношение к людям, которые разработали ядро со своей архитектурой?

Так что кто там чего доводил до железа тоже не понятно. Во всяком случае буковки на корпусе почему-то вражьи.

А, буковки... Уровень понимания ясен. :\
Замнём.

[Вадим Семенов]

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

И какое это имеет отношение к людям, которые разработали ядро со своей архитектурой?

А что именно они разработали, а что взяли из готовых блоков? Что сделали все, начиная с элементарных вентилей - не верю. Не того уровня сложности задача, чтобы ее могла сделать комада никому не известных разработчиков без серьезного предыдущего опыта. Значит все таки из блоков. Вопрос из каких. В агитматериальце этот вопрос скромно умалчивается. Мол, сделали и все. А что именно сделали, а что умные дяди помогли сделать - большой вопрос...

Чтоб вам было понятно, в России делают, например, ПК. Очень просто: берется корпус, материнская плата, проц, винт все это соединяется вместе и вуаля - компьютер готов. Или вот авто в последнее время так собирают с целью избежания таможенных пошлин. Это назвается отверточноная сборка. Так что формально "делают" в России. А по сути-то... Но сделаноунас может сообщать об очередном достижении  

Так что кто там чего доводил до железа тоже не понятно. Во всяком случае буковки на корпусе почему-то вражьи.

А, буковки... Уровень понимания ясен. :\
Замнём.

Замнем, коль возразить нечего...

[dmdimon]

нормальный даташит существует:
http://multiclet.com/docs/Datasheet_MCp0411100101.pdf
и первые результаты тестов железа (опопсяченные, но тем не менее):
...по результатам тестирования на задаче CFFT 256, выполняемой за 2487 такта, с разрядностью в 32 бита энергопотребление процессора MCp0411100101 составляет 0,45 mW/Mflops. В приведенных показателях на одинаковую топологическую норму и напряжение питания у мультиклеточного процессора MCp0411100101 энергопотребление в 3 раза  ниже, чем даже у одного только IP ядра ARM VFP9-S или ARM VFP 10.
...В ходе тестов, разработчиками также подтверждена ранее заявленная тактовая частота для исполнения Сommercial (0...+70 °C) в 100 MHz и производительность 2,4 Gflops.

[Вадим Семенов]

...В ходе тестов, разработчиками также подтверждена ранее заявленная тактовая частота для исполнения Сommercial (0...+70 °C) в 100 MHz и производительность 2,4 Gflops.

Как такое может быть? Гигафлопс это 10 в 9 операций с пл. запятой. Мегагерц это 10 в 6. То есть даже если предположить, что одна плавающая операция занимает 1 такт (что для процессора без конвеера совершенно невероятно), а процессоров там 4 на кристалле, то получается максимум 0,4 Gflops.

[goran d]

...В ходе тестов, разработчиками также подтверждена ранее заявленная тактовая частота для исполнения Сommercial (0...+70 °C) в 100 MHz и производительность 2,4 Gflops.

Как такое может быть? Гигафлопс это 10 в 9 операций с пл. запятой. Мегагерц это 10 в 6. То есть даже если предположить, что одна плавающая операция занимает 1 такт (что для процессора без конвеера совершенно невероятно), а процессоров там 4 на кристалле, то получается максимум 0,4 Gflops.

Ето возможно при изпользовании векторных инструкций.

[zyxman]

В том и дело, что есть информация (упрощенно), что практически только для задач DSP (ЦОС - mp3, avi, также сюда подпадает jpeg HD разрешения) имеют место блоки команд, которые повторяются по миллиону раз

Это очевидно, как и выигрыш на задачах ЦОС для мультиклеток в сравнении с склассическим суперскаляром. Сойдёмся на том, что тут процессор общего назначения получит какой-то выигрыш за счёт того (аудио-, видео- кодеки, кастомный процессинг медиа), что ещё не вынесли в спецвычислители и пойдём далее.

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

И да, скорость памяти давно уже настолько отстает от скорости процессоров, что если-бы были соответствующие алгоритмы, уже был-бы смысл и 1000-регистровые монстры делать, но не делают

Делают-делают. Посмотрите современный код.

Не видел ни разу КРИТИЧНОГО кода, который бы хорошо выигрывал хотя-бы от сотни регистров.

Понимаете, в чём прелесть мультиклета?
В его случае мы не паримся проблемой размера блока, для нас маленький блок независимых команд означает лишь простаивающие ИУ, но вот поток команд мы в любом случае используем на 100%. Что сумел нам скомпоновать компилятор, мы используем все. Там нет nop-ов, нет совсем. Поэтому мы можем поставить вместо 4 клеток 8, получив при этом прирост, пусть хоть на 20% на офисных приложениях, но прирост. Пусть мы не выигрываем на плохих участках в сравнении с обычным суперскаляром, но мы ничего и не теряем. Но на каждом удобном участке берём своё, отъедая выигрыш у традиционных процов.

Вы считать умеете? Как это ничего не теряем, если у нас на каждые 3 команды висит тег? :shock:
А железо, обеспечивающее все эти извращения, оно тоже по вашему бесплатное?

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

А вы не забыли, что у этой чуды по сути не один регистровый пул, а столько КОПИЙ регистровых пулов сколько клеток, да плюс еще какие-то межклеточные семафоры итп? - Вот что я имею в виду под чудовищным размером его контекста.

Вобщем который раз отсылаю вас к калькулятору.

[Вадим Семенов]

...В ходе тестов, разработчиками также подтверждена ранее заявленная тактовая частота для исполнения Сommercial (0...+70 °C) в 100 MHz и производительность 2,4 Gflops.

Как такое может быть? Гигафлопс это 10 в 9 операций с пл. запятой. Мегагерц это 10 в 6. То есть даже если предположить, что одна плавающая операция занимает 1 такт (что для процессора без конвеера совершенно невероятно), а процессоров там 4 на кристалле, то получается максимум 0,4 Gflops.

Ето возможно при изпользовании векторных инструкций.

В ихних манускриптах про векторные инструкции ничего не сказано. Но векторные инструкции это узкоспецифичная вещь, которая применима к узкому классу задач. Однако если они там есть, получается заявленное быстродействие достигнуто не благодаря их конгениальной архитектуре, а всего лишь благодаря хорошо известным до них векторным инструкциям. Для узкого класса задач. Да и показатели для векторных процессоров далеко не впечатляющие. Банальные GPU в рядовом писюке дают сотни гигафлопс - единицы терафлопс.

[zyxman]

...В ходе тестов, разработчиками также подтверждена ранее заявленная тактовая частота для исполнения Сommercial (0...+70 °C) в 100 MHz и производительность 2,4 Gflops.

Как такое может быть? Гигафлопс это 10 в 9 операций с пл. запятой. Мегагерц это 10 в 6. То есть даже если предположить, что одна плавающая операция занимает 1 такт (что для процессора без конвеера совершенно невероятно), а процессоров там 4 на кристалле, то получается максимум 0,4 Gflops.

Ето возможно при изпользовании векторных инструкций.

Если быть точнее это даже не столько векторные, сколько SIMD (single instruction multiple data), подмножеством которых являются векторные.
Типичнейший пример, это когда например у нас есть строка изображения, по которой нужно посчитать сумму (чтобы затем вычислить среднюю яркость).
У нас получается буквально S = img[0]+img[1]+img[2]+...+img.
Если у нас изображение 8-битовое и пикселы расположены в памяти последовательно и всё выровняно, а процессор имеет 32-битовую шину, это означает что за один такт обращения к памяти, шина может прокачивать сразу 4 пиксела.
Данный момент заметили многие процессоростроители и например конкретно в Интел ввели некоторую группу особых но достаточно типовых инструкций, одна из которых за один такт суммирует сразу 4 последовательно лежащих в памяти числа, и соответственно у нас получается 4-кратное ускорение.
Если шина 64 бита, то можно сделать инструкцию, суммирующую сразу по 8 8-битовых чисел.

Судя по тому, что чуда делает 2.4Гфлопс вместо 0.4, следовательно там SIMD инструкции работают сразу с 6 слагаемыми, а ширина шины кратна 48 битам, то есть то-ли 48, то-ли 96, то-ли 144, то-ли 192;
- ИМХО, скорей всего речь идет о 32-битовых числах с плавающей точкой (это довольно типично, делать тесты быстрого преобразования Фурье на так-называемой одинарной точности (single precision)), следовательно 32*6=192.

PS Из современных процессоростроителей и хоть как-то к ним причастных, конвеер не делали только такие ленивые как я :lol:

[zyxman]

И два - то же самое СОЗУ оказалось проще (и не теряя совместимости) использовать в форме кэша. С современными инструкциями, которые напрямую могут управлять prefetch и содержимым кэша вообще разница оказывается чисто синтаксической.
Так зачем мне иметь, скажем, 128 регистров, когда я могу иметь 32000 слов в кеше первого уровня с почти тем же таймингом, не загромождая 100% инструкций лишними битами адресации регистрового пула?

С кэшем та же проблема что и с регистрами - нужно потратить пропускную способность шины, чтобы его заполнить полезной информацией перед обработкой и затем тоже потратить чтобы выгрузить результаты после обработки.
Плюс еще неудобство, что кэш обычно не чисто ассоциативный как регистры, а разбит на линейки, как правило порядка 32 байтов (256 бит=8*32 или 4*64) и более, то есть еще будут потери на выравнивание.

Кстати, биты адресации регистрового пула вообще-то ЗНАЧИТЕЛЬНО дешевле чем биты адресации памяти, потому что биты адресации регистрового пула растут как log2 от числа регистров (128 регистров это 7 бит, причем биты адресации можно реализовать хитро, с сжатием, сделав скажем первые 16 регистров с короткой адресацией, всего по 4 бита на регистр, а остальные с полной длинной), а адресация памяти съедает сразу 32 или 64 бита.

[zyxman]

..энергопотребление процессора MCp0411100101 составляет 0,45 mW/Mflops. В приведенных показателях на одинаковую топологическую норму и напряжение питания у мультиклеточного процессора MCp0411100101 энергопотребление в 3 раза  ниже, чем даже у одного только IP ядра ARM VFP9-S или ARM VFP 10.

Кстати, вы будете смеяться, но вот прямо практически во время нашей типа дискуссии, почитал бенчмарк от Фороникса кластера на ARM v7 (8 плат с двухядерниками ARM соединили эзернетом 100мбит), супротив купленных в обычном магазине Атома, Коре-2 i7 и Фюжн, и там написано, что система на Коре-2 оказалась как раз примерно в 3 раза энергоэффективнее чем система на ARM :lol:

Правда там такой нюанс, что система ARM работала с твердотелых SD карточек, а Коре-2 с нормального HDD, у которого очень немаленькое потребление, ну и прочих нагревателей тоже на материнке Коре-2 хватало, но пожалуй погрешность не в разы, да.
http://www.phoronix.com/vr.php?view=17473