Сообщество

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

Объяснений много, но думать не над чем. Кроме экономии на цикле ничего из этой ОЧЕНЬ сложной хрени не получается, но сам по себе цикл - не затратен: выборка со скоростью памяти, параллельность естественная, в том числе наслаиваются параллельно итерации циклов, всё!

VaalKIA wrote:

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

Объяснений много, но думать не над чем. Кроме экономии на цикле ничего из этой ОЧЕНЬ сложной хрени не получается, но сам по себе цикл - не затратен: выборка со скоростью памяти, параллельность естественная, в том числе наслаиваются параллельно итерации циклов, всё!

То, что я объяснил, вроде реализуется не сложно и работать будет быстро. Возможно я написал, что-то непонятно.
Единственный сложный момент -- это рассылка сообщений клеткам, но они же вроде итак соединены и может можно как-то приспособить их связь.
Другое дело, если это делать не нужно...

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

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

И что в результате произойдёт ? Развернётся ли цикл на все клетки ?

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

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

Может не правильно объяснил, попробую попонятней, допустим у нас такой цикл(каждая строчка - это инструкция и выполняется она за такт):

// параграф цикла
1) Вычисление индекса i
2) a[i] = b[i] + c[i]
3) условие завершения, если не истина, то переходим на первую инструкцию

// следующий параграф
4) инструкция за циклом
5) инструкция за циклом
6) инструкция за циклом
7) инструкция за циклом
8) инструкция за циклом

И допустим, что у нас 8-ми клеточный процессор и каждая клетка за такт загружает по команде. В результате 4 и 5 клетка загрузят 4 и 5 инструкцию(или не загрузят ничего, т.к. неизвестно, что загружать). Как они узнают, что надо было им загружать 1 и 2 инструкции соответственно, ведь результат вычисления условия будет известен только в следующем такте ?
А в следующем такте клетки номер 1 и 3 освободятся, но станет известно условие и можно будет загрузить ещё 3 команды, при этом команда 2 будет ещё не выполнена, а новое условие неизвестно и таким образом одновременно полезно будут загружены всего 4 команды(клетки), а вторые 4 клетки будут работать впустую или не будут работать вообще, т.к. в них инструкции следующего параграфа(или ничего нет, т.к. они не знают какой из параграфов загружать).

Вообщем загрузка клеток не будет обгонять вычисления и поэтому загрузка будет не полной.
Мультикоманда решила бы эту проблему и загрузила бы всё полезной нагрузкой по-максимуму.

Если мультиклет работает не так, то расскажите как ?
И как там обработается данная ситуация ?

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

Мы говорим о сферическом коне в вакууме. Я не знаю как работает Мультиклет, да это и не особо важно. Суть-то она простая: если не подразумевается вычислений: тело цилка за один такт, та какими бы расчудесными ни были клетки, память одна на всех и поэтому выбрать 100 ячеек массива займёт 100 тактов (хоть одна клетка, хоть сто). Да, в оригинале добавится 1 такт на обслуживание цикла итого будет 200, в вашем случае этот 1 такт нивелируется ценой офигительно сложной логики. Но это сферический конь в вакууме, потому что на практике тело цикла будет 1000 тактов и более, и 1 такт роли не играет и не сможет затормозить "клеточный конвеер" (за одну итерацию не 1 клетку мы сможем загрузить, а 1000), об этом я и пишу, а там где тело цикла 1 такт, скорее всего речь идёт о банальном копировании и там вообще процессор не загружается этим всем, а работает DMA, который копирует 100 ячеек за 100 тактов (упрощённо), ещё и проц параллельно с DMA делает всё что ему нравится без всякого торможения.

В результате 4 и 5 клетка загрузят 4 и 5 инструкцию(или не загрузят ничего, т.к. неизвестно, что загружать).

Загрузят всё, если данные не связаны с предъидущими итерациями (типа a[i]=a[i-1]+1), если же связаны, то никакие ухищрения и пакетные "мультикомманды" не помогут. Ведь скзаано, что в Мультиклете вычисления производятся по готовности данных, поэтому если правильно написано тело цикла, то итерации будут идти как на конвеере задействуя все клетки.
Кстати говоря, даже в бейсике вводились такие комманды как do loop, где нет никаих условий, тупо цикл энное количество раз, даже без возможности использовать итератор, аналог в современных языках: foreach

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

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

krufter_multiclet wrote:

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

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

В таком случае я бы сделал примерно так, но это уже на программном уровне:

1) Весь код по обработке массива написал бы в отдельных двух параграфах -- первый вычислял бы диапазон индексов, а во втором бы шёл цикл обработки по этому диапазону.
2) Получил бы количество клеток процессора и реконфигурировал бы его, что бы каждая клетка стала ядром
3) Затем на каждую клетку передал бы эти два параграфа на выполнение -- в первом рассчитался бы диапазон обрабатываемых чисел для клетки, после чего он перешёл бы на второй, который его станет обрабатывать.
4) По завершению всех обработок, восстановил бы реконфигурацию процессора и код стал бы выполнятся дальше.

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

И по по-поду этого и пункта 2, ещё одну важную вещь скажу(я уже раньше её приводил):
Если процессор уже реконфигурирован и например разделён на 10+54 клеток, а нужный поток выполняется на 54 клетках, то при его реконфигурации этот поток должен видеть только свои 54 клетки и только их он может реконфигурировать, поэтому это число где-то должно хранится, а после выполнения обработок надо восстановить состояние этих 54 клеток.

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

VaalKIA wrote:

память одна на всех и поэтому выбрать 100 ячеек массива займёт 100 тактов (хоть одна клетка, хоть сто).

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

Для высокопроизводительного процессора нужна быстрая память, если память будет всё тормозить, то от процессора толку будет мало, кроме случаев, когда инструкции очень долго выполняются.
Но тут я могу привести пример, об очень популярных матрицах и векторах, а в их расчёте обычно две инструкции -- умножение и сложение. Умножение на Интеле выполняется за 3 такта, а сложение, за 1.
В таком случае процессор будет тормозить расчёт этих самых матриц и векторов, а они применяются повсеместно в 3Д графике, физике и т.д.
Нейросети тоже будут обрабатываться медленно -- их алгоритм это почти тоже самое, что и матрицы и вектора.
Я могу ещё кучу примеров привести.

в вашем случае этот 1 такт нивелируется ценой офигительно сложной логики.

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

В результате 4 и 5 клетка загрузят 4 и 5 инструкцию(или не загрузят ничего, т.к. неизвестно, что загружать).

Загрузят всё, если данные не связаны с предъидущими итерациями (типа a[i]=a[i-1]+1), если же связаны, то никакие ухищрения и пакетные "мультикомманды" не помогут. Ведь скзаано, что в Мультиклете вычисления производятся по готовности данных, поэтому если правильно написано тело цикла, то итерации будут идти как на конвеере задействуя все клетки.

В моём примере видны связанные данные ?
Я вам намеренно привёл пример без связи данных между итерациями, для связанных данных я воспользуюсь другими командами или переработаю алгоритм и сделаю их не связанными, если будет возможно это.

Кстати говоря, даже в бейсике вводились такие комманды как do loop, где нет никаих условий, тупо цикл энное количество раз, даже без возможности использовать итератор, аналог в современных языках: foreach

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

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

VaalKIA wrote:

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

Это может быть, но у нас процессор слабо греется и не потребляет много энергии и гореть не планирует).

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

Я так и не спросил: в Мультиклете есть CPUInfo (http://habrahabr.ru/company/intel/blog/220203/ http://habrahabr.ru/company/intel/blog/220851/)?

Здравствуйте.

Похоже вышел новый ГОСТ по шифрованию (ГОСТ Р 34.12-2015), так что планы по ГОСТ 89 наверное стоит пересмотреть: В ГОСТе сидел «Кузнечик»

sprin wrote:

Здравствуйте.

Похоже вышел новый ГОСТ по шифрованию (ГОСТ Р 34.12-2015), так что планы по ГОСТ 89 наверное стоит пересмотреть: В ГОСТе сидел «Кузнечик»

Да, спасибо за информацию.

Тут вопрос у меня возник из личного интереса.

Допустим у вас сейчас техпроцесс 180 нм и вы можете перейти на техпроцесс 90 нм, что позволит на кристалле той же площади уместить в 4 раза больше клеток. Но при этом техпроцесс 90 нм дороже, чем 180 нм(на сколько я не знаю).
Если же увеличить размер кристалла в 4 раза и техпроцесс оставить равным 180 нм, то в результате количество клеток тоже увеличится в 4 раза, но в 4 раза(примерно) уменьшится количество получаемых кристаллов с пластины и наверно увеличится количество брака.

Конечно при переходе на 90 нм можно ещё и частоту поднять и также снизить энергопотребление, но если эти параметры не учитывать, то по деньгам, что выгодней -- заказывать в 4 раза больший кристалл на 180 нм или переходить на 90 нм ?

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

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

Yaisis wrote:

Конечно при переходе на 90 нм можно ещё и частоту поднять и также снизить энергопотребление, но если эти параметры не учитывать, то по деньгам, что выгодней -- заказывать в 4 раза больший кристалл на 180 нм или переходить на 90 нм ?

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

VaalKIA wrote:

Техпроцесс это не самое главное, что бы сделать микруху по новому техпроцессу надо переделать полностью всю топологию.

Ну понятно, что для 90 нм надо ещё заново проектировать микросхему.
Но смысл моего вопроса был в другом.
Например сейчас на 180 нм можно в 4 раза увеличить кристалл с небольшими доработками и получить 16-клеточный процессор или можно перейти на 90 нм и при том же размере кристалла в него поместится 16 клеточный процессор.
Допустим что все шаблоны уже готовы и для (4х)180 нм и для 90 нм процессора, то что из них окажется дешевле производить ?

А действительно :-)
Что выгоднее будет по соотношениям производительность:тепловыделение:стоимость_владения(включая стоимость покупки-производства) , какие конфигурации на каких техпроцессах?
Наверняка же мечтали и прикидывали хотя бы "на глазок" по всем этим параметрам :-)

Разумеется, выгоднее 90нм, 4 клетки и мелкий кристалл.
Ведь на 16 клеток мы параллелизма не наберём. Так что пускай уж с 4 клетками работает, зато шустрее и экономичнее.

Кстати, знающие люди говорят, что топология что на 180, что на 90, что на 65нм очень похожа. Лишь бы фабрика нужные библиотеки давала.
А вот для всего, что мельче, уже спец. софт и свои подходы нужны.

ak_multiclet wrote:

Разумеется, выгоднее 90нм, 4 клетки и мелкий кристалл.
Ведь на 16 клеток мы параллелизма не наберём. Так что пускай уж с 4 клетками работает, зато шустрее и экономичнее.

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

Тут в форуме есть ещё ветка про Роботов. Так вот роботам лучше 16 клеток, чем 4, т.к. там много чего обрабатывать.

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

И ещё по поводу этого:

Ведь на 16 клеток мы параллелизма не наберём.

Пока ваша аппаратная часть так сильно не развита, делайте ставку на компилятор, точно также, как Эльбрус, ведь у него во VLIW-слове заметно больше 4-х инструкций.
Улучшайте свой оптимизатор, но при наличие только 4-х клеточного процессора, у вас нет стимула улучшать оптимизацию для процессоров с большим количеством клеток.

Так что пускай уж с 4 клетками работает, зато шустрее и экономичнее.

Думаю, что лучше смотреть на потребности клиентов...
Если им нужно 4 клетки, то делать 4.
Если 16 -- то 16.
Если кому-то 4, а кому-то 16 -- то выпускать две версии процессора, а если по себестоимости они будут одинаковые, то выпускать 16-клеточный(или более) и при этом добавить программную возможность полностью отключать некоторые клетки и управлять частотой, тогда клиент сможет настраивать процессор под себя и свою задачу. И это будет первым шагом к реализации технологии, которую вы хотели бы добавить -- при выходе части клеток из строя, процессор продолжает свою работоспособность.

Кстати, знающие люди говорят, что топология что на 180, что на 90, что на 65нм очень похожа.

А цена на них тоже очень похожа ?

По поводу

Ведь на 16 клеток мы параллелизма не наберём.

Склонен согласиться по крайней мере на данном этапе развития и становления мультиклеток и для традиционных языков программирования распространенных сегодня (без применения новых или существующих расширений языков наподобие OpenMP)
Мой опыт написания компилятора для подобной архитектуры показывает, что у большинства программ на С коэффциент параллелизации довольно невысок (опять же, если не применять спец средства разметки, свои придуманные или существующие - наподобие OpenMP), то есть, если перекомпилировать существующие алгоритмы на мультиклет, большинство из 16 клеток будут в основном простаивать, а в случае 4-х клеток все 4 клетки будут в основном задействованы

Aha wrote:

Склонен согласиться по крайней мере на данном этапе развития и становления мультиклеток и для традиционных языков программирования распространенных сегодня (без применения новых или существующих расширений языков наподобие OpenMP)

Я спокойно задействую все 16(и более) клеток в своих задачах на традиционном языке программирования без использования OpenMP, OpenCL, Click Plus, HSA и других подобных технологий. Задействую с помощь реконфигурации.

Как я понял, сейчас идут попытки по протированию LLVM.
В LLVM есть механизмы векторизации кода, которые автоматически распараллеливают циклы и при компиляции, например, под Интел могут автоматически задействовать AVX-512, например, для параллельных действия над 16-ю инструкциями, производящих вычисления в одинарной точности. После портирования LLVM под Мультиклет те же векторные инструкции могли бы задействовать 16 клеток или более.

...что у большинства программ на С коэффциент параллелизации довольно невысок

Все современные компиляторы умеют автоматически задействовать векторные инструкции при указании соответствующих опций и в архитектурах x86 такие векторные расширения, как SSE и AVX используются очень часто. Их векторные инструкции сильно увеличивают производительность в циклах. У Мультиклета заместо них было бы количество клеток.
Да и какая разница, что там делает большинство Си программ ?
Есть клиенты и им нужны процессоры с определёнными характеристиками, так вот надо стремится удовлетворить их потребности, а не заниматься анализом большинства программ. Ведь удовлетворение потребностей клиентов -- это доход фирмы.

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

Yaisis wrote:

Я спокойно задействую все 16(и более) клеток в своих задачах на традиционном языке программирования без использования OpenMP, OpenCL, Click Plus, HSA и других подобных технологий. Задействую с помощь реконфигурации.

Например? Просто любопытно, я с "реконфигурацией" не знаком, поэтому просто интересно

Как я понял, сейчас идут попытки по протированию LLVM.
В LLVM есть механизмы векторизации кода, которые автоматически распараллеливают циклы и при компиляции, например, под Интел могут автоматически задействовать AVX-512, например, для параллельных действия над 16-ю инструкциями, производящих вычисления в одинарной точности. После портирования LLVM под Мультиклет те же векторные инструкции могли бы задействовать 16 клеток или более.

...что у большинства программ на С коэффциент параллелизации довольно невысок

Все современные компиляторы умеют автоматически задействовать векторные инструкции при указании соответствующих опций и в архитектурах x86 такие векторные расширения, как SSE и AVX используются очень часто. Их векторные инструкции сильно увеличивают производительность в циклах. У Мультиклета заместо них было бы количество клеток.

Все верно, но количество такого кода, который хорошо автоматически раскладывается на клетки в среднестатистичекой задаче на любом языке програмирования не так уж много, чтобы увеличивать быстродействие в разы, на 16 клетках ускорение в 16 раз не получить, дай бог в 3-4 раза "в среднем по больнице"

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

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

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

И дело не в мкроконтроллерах, нет...

Aha wrote:

Например? Просто любопытно, я с "реконфигурацией" не знаком, поэтому просто интересно

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

Все верно, но количество такого кода, который хорошо автоматически раскладывается на клетки в среднестатистичекой задаче на любом языке програмирования не так уж много, чтобы увеличивать быстродействие в разы, на 16 клетках ускорение в 16 раз не получить, дай бог в 3-4 раза "в среднем по больнице"

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

Давайте приведу тут пример: Допустим есть 16 клеточный процессор и один поток программы. Этот поток выполняется и задействуются максимум 4 клетки из 16, а потом доходит до цикла из 32_000_000 итераций и тут программист этот цикл разбивает на 16 потоков, в каждом по 2_000_000 итераций, которые запускает на выполнение параллельно на 16 клетках. В результате цикл выполняется в 16 раз быстрее. И получается следующее: код, который не требователен к производительности, задействует максимум 4 клетки из 16, а весь ресурсоёмкий код заключён в циклах и ресурсоёмкий он потому, что многократно повторяется и именно этот код программист ускоряет за счёт разбиения циклов на потоки. В результате за счёт этого получается огромная выгода, так как код в данном примере ускоряется в целых 16 раз.
Точно по такому же принципу получается выгода от SSE и AVX -- они часто простаивают, но от них огромная польза, т.к. они задействованы там, где скорость важна больше всего, т.е. в циклах.

на 16 клетках ускорение в 16 раз не получить, дай бог в 3-4 раза "в среднем по больнице"

С помощь реконфигурации можно получить(теоретически и зависит от её реализации)
Если в самом процессоре будут какие-то задержки или задержки по памяти, то конечно не получить.
Фактически всё будет зависеть от скорости доступа к памяти -- если данные будут успевать приходить, то скорость можно увеличить в 16 раз.

Приведу пример с Интелом: Допустим у меня есть четырёх-ядерный процессор с гипертреадингом, т.е. 8 потоков. Если я распараллелю свою ресурсоёмкую задачу с одного потока на 8, во сколько раз я увеличу производительность ?
Теоретически 4 реальных ядра должны её увеличить в 4 раза, а от дополнительных виртуальных потоков непонятно есть ли толк вообще(я так думал вначале)
Так вот на 8 потоках я увеличил производительность своей ресурсоёмкой задачи ровно в 6 раз по сравнению с одним потоком -- в 4 раза она увеличена за счёт 4 ядер, а 4 дополнительных виртуальных потока дали производительность ещё двух ядер.

Если память не будет тормозить вычисления, то на 16 клетках увеличу производительность ровно в 16 раз по-сравнению с одной клеткой.

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

Правильный ответ в том, что в данной теме это не имеет значения, т.к. допустим, что я потенциальный клиент Мультиклета и мне нужны 16 клеток, то какая разница кто там до сих пор жив -- Си или Фортран -- меня не это волнует, а наличие 16 клеток.
Как клиенту, мне всё-равно какой код был до этого у других и что он там внутри использует -- у меня есть свои задачи и я знаю как их решить, мне нужны только 16 клеток и нормальная реконфигурация с быстрой памятью и шиной, чтобы не тормозили процесс вычислений, а код я напишу сам.
(это я говорю образно)

По поводу Фортрана, то он жив из-за большого количества библиотек, написанных под него, но не всем клиентам нужны эти библиотеки, как и сам этот язык(даже наверно большинству не нужны они) и нельзя по наличию этих библиотек определять нужны ли 16 клеток в Мультиклете или нет -- это не связанные вещи, если только конечно Мультиклет не позиционируется, как ускоритель Фортран-кода...

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

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

Мысли понятные, но смею опять-таки напомнить, что я не тролль.
Фортран жив, потому что на нем написано очень много научного кода и переписывать его на новые современные языки никто не желает - его ну очень дофига и он не лежит мервыми байтами, он работает. То же самое касается С/С++. То же самое случится через десяток лет с сегодняшними новомодными разработками, и ни один здравомыслящий потенциальный покупатель мультиклета, имеющий уже в своем багаже набор софта (если только это не просто пара программ а-ля helloworld) и умеющий считать деньги в фонде заработной платы своих программистов, не будет покупать новый процессор с перспективой полностью переписывать все свое хозяйство. Доделать, доработать, "обработать чуть-чуть напильником", подправить драйвера - может быть, но это не тема мультиклета, единственный драйвер тут - компилятор, который может автоматически что-то напареллелить.

Что же касается реконфигурации, то это уже больше похоже на задачи операционной системы, это отдельный разговор: ось работает, задачи запускается, там все хорошо. Особенность же мультиклета - это "мелкозернистый параллелизм", а на 16 клеток действительно сложно набрать параллелизма в пределах одной задачи, одной нитки, возможно у нас изначально произошло недопонимание в терминах, начиная с фразы krufter-a про "ведь на 16 клеток параллелизма не наберем"

А давайте так, чтобы не быть голословным
Вот бенчмарк
http://www.cs.virginia.edu/stream/
Я знаю, каковы его потенциальные способности по распраллеливанию на 16, на 8, на 4 клетки

Господа *_multiсlet, поиграем, посмотрим потенциал клеточек? ;-)

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

Disclaimer. Это не тест производительности, это тест пропускной способности памяти, просто примеры для распараллеливания хорошие :-)

Aha wrote:

Что же касается реконфигурации, то это уже больше похоже на задачи операционной системы, это отдельный разговор: ось работает, задачи запускается, там все хорошо. Особенность же мультиклета - это "мелкозернистый параллелизм", а на 16 клеток действительно сложно набрать параллелизма в пределах одной задачи, одной нитки, возможно у нас изначально произошло недопонимание в терминах, начиная с фразы krufter-a про "ведь на 16 клеток параллелизма не наберем"

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

P.S. скоро(через 2 недели) планируется предоставить возможность любому желающему запустить любой тест на нашей отладке удаленно.

Aha wrote:

единственный драйвер тут - компилятор, который может автоматически что-то напареллелить.

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

...и ни один здравомыслящий потенциальный покупатель мультиклет... не будет покупать новый процессор с перспективой полностью переписывать все свое хозяйство.

Это зависит от покупателя и его задач, а не от его здравомыслия, хотя и от этого тоже.
К примеру, я хочу, чтобы появилась LLVM не только потому, что это крутая технология, но и потому, что с помощью её я смогу перенести нужные мне программы(и при этом они не все на С/С++) -- их уже сама LLVM хорошо векторизует и при наличие много числа клеток эти куски кода могли бы заполнить их все вычислениями. В крайнем случае я могу что-то доработать в самих программах и они станут лучше векторизоваться, но мне не надо переписывать всё с нуля.
Тоже самое касается и всех остальных -- они точно так же смогут переносить свои программы.

И вот речь шла о том, что при наличие LLVM я могу перенести свою старую программу и нагрузить её на все 16 клеток.