Сообщество

krufter_multiclet wrote:

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

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

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

Если же выполнять все команды подряд, то некоторые команды должны выполняться со 100% вероятностью, некоторые с 50%, которые попадают в условие, некоторые с 25%, которые попадают в двойное условие и т.д. Поэтому процессор должен большее внимание уделять командам с наибольшей вероятностью выполнения, тогда производительность будет выше. Хотя тут тоже не всё так просто...

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

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

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

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

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

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

VaalKIA wrote:

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

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

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

Yaisis wrote:

Если же выполнять все команды подряд, то некоторые команды должны выполняться со 100% вероятностью, некоторые с 50%, которые попадают в условие, некоторые с 25%, которые попадают в двойное условие и т.д. Поэтому процессор должен большее внимание уделять командам с наибольшей вероятностью выполнения, тогда производительность будет выше. Хотя тут тоже не всё так просто...

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

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

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

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

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

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

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

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

Yaisis wrote:

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

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

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

Можете пример привести условных команд, как бы они выглядели применительно к нам? У нас в R1 были добавлены команды условия, которые например помогают поставить в параграфе несколько безусловных команд перехода, что может быть полезно, если в зависимости от условия мы хотим переходить на выполнение параграфа соответствующего отрезка.
Т.е. допустим 3 параграфа у нас есть и в зависимости от 0<x<2, 2<x<4, x=15 мы можем в одном параграфе определить на выполнение параграфа для какого отрезка мы переходим.

Yaisis wrote:

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

Кроме "пусть процессор сам всё параллелит как может и как хочет" и "пусть программист сам всё пишет" есть промежуточный вариант. Есть библиотеки и компиляторы. Например если речь идёт о проце общего назначения, нужна а) некая поддержка в ядре б) компилятор. Если речь идёт об ускорителе, который к примеру подключается по некоей шине, то нужна поддержка в библиотеках. Ну типа OpenMP например. Или OpenCL, о коем уже говорили.

Можете пример привести условных команд, как бы они выглядели применительно к нам?

Я наверно их неправильно назвал, имел ввиду условное выполнение команд, как в ARM.

Т.е. например есть такой код:

cmp x, 0
addje @1, x,1
addjne @2, x,2

Тут ассемблер вымышленный, но работает он так:
1) cmp x, 0 -- сравнивает x с 0 и в случае совпадения возвращает true, иначе false(на самом деле в результате больше бит, по которым можно также определить меньше, больше и т.д.)
2) addje @1, x,1 -- команда выполняет сложение копии x c 1, но применит результат к x тогда, когда станут доступны данные первой команды и если x будет равен 0, иначе проигнорирует результат.
3) addjne @2, x,2 -- команда выполняет сложение копии x c 2, но применит результат к x тогда, когда станут доступны данные первой команды и если x будет не равен 0, иначе проигнорирует результат.

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

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

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

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

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

kernel:
...
complete

main:
...
run kernel 100 // или -- run kernel @5

complete

Тогда получается команда run должна запустить параграф kernel 100 раз(параллельный запуск) или количество раз, возращённое в операнде со смещением, например 5(@5).
При этом в параграф kernel можно передавать значения, через регистры, как и в другие параграфы, но они будут доступны только для чтения, потому что с ними будут работать параллельно много копий этого параграфа. Так же в каждую копию параграфа передаётся свой индекс(в примере от 0 до 99), благодаря ему код в параграфе сможет строить адрес смещения к соответствующим данным(можно конечно предусмотреть возможность передачи нескольких индексов, например "run kernel 100, 200", тогда параграф будет получать 2 индекса, но это сложнее реализовать и не знаю, есть ли большая необходимость в этом, т.к. любое количество измерений можно реализовать с помощью нескольких команд run с одним измерением. Только run с множеством измерений может быстрее запускать соответствующий код, чем такая же реализация, через run с одним измерением. Но тут надо думать, как выгодней это реализовать на аппаратном уровне).

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

Кроме "пусть процессор сам всё параллелит как может и как хочет" и "пусть программист сам всё пишет" есть промежуточный вариант. Есть библиотеки и компиляторы. Например если речь идёт о проце общего назначения, нужна а) некая поддержка в ядре б) компилятор. Если речь идёт об ускорителе, который к примеру подключается по некоей шине, то нужна поддержка в библиотеках. Ну типа OpenMP например. Или OpenCL, о коем уже говорили.

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

Сейчас объясню, что я имел ввиду в предыдущих комментариях и опишу ваши варианты, которые все важны:

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

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

В результате все команды начнут выполнятся одновременно, команды 2 и 3 сохранят результат в специальном буфере, а после того, как станет известен результат команды 1, то одна из команд отбросится, а от другой значение из буфера скопируется в x.

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

При этом чем дальше ветка от ствола, тем приоритет выполнения команд в ней меньше,

Даже приоритеты не делают эту идею убедительной.

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

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

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

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

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

И контраргумент остаётся в силе: ничто не мешает вместо условия стартовать два параллельных вычисления и потом одно из них дропать программно. Про выгоду на уровне еденичных инструкций смотреть выше :-)

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

Со строчки "Например с параграфами можно сделать так:" дальше всё идёт про параграфы.

Yaisis wrote:

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

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

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

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

Нельзя всё возлагать только на программиста, только на компилятор или только на процессор.

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

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

Yaisis wrote:

Со строчки "Например с параграфами можно сделать так:" дальше всё идёт про параграфы.

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

Нельзя всё возлагать только на программиста, только на компилятор или только на процессор.

Согласен, поэтому, на мой взгляд, рулят RISC архитектуры и микроядерные ОС. Которые всё делают просто, настолько, насколько это возможно, но - не проще.

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

Знаю, именно поэтому x86 проигрывает архитектуре ARM на мобильных платформах, и рано или поздно, эти динозавры вымрут. Кстати, если уж сравнивать разные платформы, то имел опыт сравнения PowerPC и x86: компьютеры, как известно - тормозят, так вот, тормоза на этих платформах вели себя очень по разному, на PPC всё немного замедлялось, а на x86 уходило в жёский фриз (одни и те же программы). То есть для пользователя PPC казалась более "плавной" платформой. А эффект этот - из-за перегруженности x86 оптимизациями и не такой уж высокой средней производительностью. Поэтому когда программист пишет алгоритм и у него есть возможность или уменьшить среднее время на 10% или в половине случаев будет +20%, а в половние - 40%(что очень круто), то первый варинт предпочтительней, потому что во второй редкие проблески произвоительности, которая в данный момент не так уж и нужна, будет сопровождаться тем, что всё встанет раком в остальное время (подобные оптимизации разных компонентов имеет свойство накладываться в самый не подходящий момент), что наглядно видно как дёрганность x86. Конечно, это всего лишь процессор и я утрирую, но эффект имеет место быть.

Про Run параграфов я видел, идея интересная, но я только присматриваюсь к мультиклету и оценить её не могу, в силу моей дилетантности.

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

Мне вообще не нравится слово "параграф", потому что я интуитивно чувствую, что их загрузка съедает кучу процессорного времени, которое сведёт на нет все блестящие идеи.

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

Согласен, поэтому, на мой взгляд, рулят RISC архитектуры и микроядерные ОС. Которые всё делают просто, настолько, насколько это возможно, но - не проще.

Мне нравится идея мультиклета -- у неё огромный потенциал.
Про микроядерные ОС согласен.

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

Конечно С/С++ нужны потому, что много исходников доступны на этих языках и много библиотек. А Rust был бы полезен для тех, кто пишет программы с нуля, да и сам язык современней, поэтому писать программы на нём быстрее. Наверно данный язык в самый раз подошёл бы и для ускорителя на вашем процессоре.
Мне ещё нравится язык программирования D, хотелось бы его видеть, но вряд-ли вы будете его делать, т.к. он пока не популярен, а вам надо с умом тратить свои ресурсы, т.е. на самое необходимое.

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

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

"Вторым продуктом были представлены результаты синтеза 256-клеточного процессора для платы-ускорителя. При производительности 24 TFLOPS энергопотребление такой платы составит всего 40 Вт."
(фраза из этой новости: http://www.multiclet.com/index.php/ru/news/313-multiclet-inatronics-2014)

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

Yaisis wrote:

"Вторым продуктом были представлены результаты синтеза 256-клеточного процессора для платы-ускорителя. При производительности 24 TFLOPS энергопотребление такой платы составит всего 40 Вт."
(фраза из этой новости: http://www.multiclet.com/index.php/ru/news/313-multiclet-inatronics-2014)

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

Мы просто пока не можем выложить всю структуру как это будет работать до начала уже конкретных работ по проектированию. Но структура взаимодействия процессоров на плате ускорителе уже была создана. Надо бы запатентовать. В общих чертах должно было быть 8 процессоров на плате 256-ти клеточных процессоров. Каждый 256-ти клеточный процессор должен состоять из 16-ти 16-клеточных ядер, с частотой 2 ГГц. Для моделирования собирались отдельные тяжеловесные блоки и проверялась их работа на 2ГГц. Конечно по ходу разработки могут быть корректировки и изменения. Но, то что есть на сегодня написал.

krufter_multiclet wrote:

Мы просто пока не можем выложить всю структуру как это будет работать до начала уже конкретных работ по проектированию. Но структура взаимодействия процессоров на плате ускорителе уже была создана. Надо бы запатентовать. В общих чертах должно было быть 8 процессоров на плате 256-ти клеточных процессоров. Каждый 256-ти клеточный процессор должен состоять из 16-ти 16-клеточных ядер, с частотой 2 ГГц. Для моделирования собирались отдельные тяжеловесные блоки и проверялась их работа на 2ГГц. Конечно по ходу разработки могут быть корректировки и изменения. Но, то что есть на сегодня написал.

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

И вам, скорее всего, там нужна очень быстрая память, типа HBM.

Ещё вопрос: Там планировалась двойная точность ? Двойная точность в ускорителях вычислений очень желательна.
А если там будет ещё реконфигурация, то можно будет использовать как 2048(256*8)-ядерный процессор.

Надо бы запатентовать.

Патентуйте всё и не только в России. А то, например, Эпл потом запатентует ваши идеи и на вас в суд подаст, будет обидно.

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

Yaisis wrote:

И ещё лично я бы предпочёл не в виде PCI платы, а в виде внешнего модуля, потому что я в свой ноутбук не смогу воткнуть PCI версию, поэтому если будете её

Есть коробочки USB 2.0, они, правда не держат скорости больше PCIx4, но тем не менее. Самые производительные (и дорогие) LightBolt2 но дают PCIx8, например:
http://habrahabr.ru/sandbox/45652/
http://www.sonnettech.ru/catalog/thunderbolt_solutions/107622/
На стационарных компах тундерболт не проблема, на ноутах тоже встречаются, но только у Apple (сони пыталсь что-то делать (Light Peak Sony Vaio Z21), но она больше не производит ноуты).
Зато скоро будет USB 3.0 и остаётся подождать коробочки для него.
Так что PCIe это самое оно. Я конечно не против разнообразия, но при экономии средств..

И вам, скорее всего, там нужна очень быстрая память, типа HBM.

Для начала хорошо было бы просто DDR4, он хотя бы энергоэффективный и с коррекцией ошибок "из коробки", можно сдлать 4 канала. А ширину шины нарастить не проблема на самом деле (HighBrandWidthMemory). При этом DDR4 это уже main-stream и для портативных устройств - просто манна небесная, так что охватывает устройства от умного дома и контроллеров до серверов. Огромная ошибка, что его не поддерживает Эльбрус и всё ещё не поддерживает Мультиклет.
И потом, широкая шина повышает латентность, это не очень критично для обработки графики, но для ускорителя общего назначения это не хорошо.

Надо бы запатентовать.

Патентуйте всё и не только в России. А то, например, Эпл потом запатентует ваши идеи и на вас в суд подаст, будет обидно.

Патентование это не так уж и дорого, хотя стран много, но США, Европа, Япония, Китай, Индия.. думаю вполне достаточно. Я уже задал вопрос в параллельной ветке.

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

VaalKIA wrote:

И ещё лично я бы предпочёл не в виде PCI платы, а в виде внешнего модуля, потому что я в свой ноутбук не смогу воткнуть PCI версию, поэтому если будете её

Есть коробочки USB 2.0, они, правда не держат скорости больше PCIx4, но тем не менее. Самые производительные (и дорогие) LightBolt2 но дают PCIx8, например:

Спасибо за информацию, может пригодится.

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

Сейчас у них в разработке Эльбрус-8С2, который будет поддерживать DDR4.

На HBM уже переходят Интел, АМД и Нвидиа.
В АМД -- она будет в последней видеокарте, которая скоро должна уже выйти.
У Интела -- в последнем Xeon Phi, который должен выйти во второй половине года и который также будет доступен в виде самостоятельного процессора.
А у Нвидиа -- это архитектура Паскаль, она позже первых двух появится.

HBM конечно лучше, она быстрее и компактней, я читал, что к одному модулю может сразу обращаться куча процессоров и при этом не будет возникать очередей. Плюс она очень компактная -- есть модуль на 4 Гбт и на 8 Гбт, т.е. можно припаять 4 маленьких микросхемы вокруг процессора и получить 32 Гбт. Сами же микросхемы по размеру меньше, чем аналогичные у DDR4 и вроде потребляют меньше энергии, но про энергию точно не знаю. Возможно я сейчас описал второй стандарт(HBM2).

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

krufter_multiclet wrote:

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

А ещё памяти должно быть много для такого ускорителя.
В последнем Intel Xeon Phi будет встроено 16 Гб HDM памяти, при этом его производительность на двойной точности составляет 3 Tflops -- это по новостям.
(мне конечно 16 может не хватить)