Сообщество

Yaisis wrote:

Здравствуйте.
То, что я узнал по Мультиклету выглядит интересно.
За счёт большого количества клеток может быть получена большая производительность, но весь ресурсоёмкий код заключён в циклы, как обстоят дела с ускорением этого кода ?
Как в мультиклете реализованы циклы ? Умеет он их разворачивать или их должен разворачивать заранее компилятор ?
Если их разворачивает заранее компилятор, то получается, что для процессоров с большим количеством клеток необходимо перекомпилировать программу, чтобы оптимальней использовать ресурсы процессора ?
А если длина цикла известна только на этапе выполнения, то как обстоят дела с такими циклами ?

То, что называется "раскруткой цикла", в Мультиклете выполняется автоматически на аппаратном уровне.

"То, что называется "раскруткой цикла", в Мультиклете выполняется автоматически на аппаратном уровне."
Это очень хорошо.
Где-нибудь можно поподробней об этом почитать или это пока секрет ?

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

Секретов здесь нет. Все получается "естественным" путем. Клетки не понимают цикл это или не цикл. При выборке команд n клеток одновременно выбирают n команд и складывают их в свои буфера. Процесс выборки продолжается пока не будет выбрана команда с признаком "complete" - т.е. конец параграфа. Если к этому моменту известен адрес следующего параграфа, то выборка продолжается с этого адреса. Если нет, то процесс выборки приостанавливается. Он также приостанавливается если переполнен буфер, т.е. если не выполнены какой-то клеткой 64 ранее выбранные команды.
Процесс исполнения команд в буфере не связан с процессом выборки. Если есть готовые к исполнению команды - то они выполняются независимо от того идет в данный момент выборка или нет. В результате, если итерации цикла информационно не связаны, то одновременно могут исполняться несколько итераций. При этом мы видим следующую картинку.
Идёт выборка команд первой итерации. С некоторой задержкой начинается её исполнение. Для циклов типа for проверяется счетчик и при необходимости выбирается следующая итерация. Как правило к этому моменту команды предыдущей итерации не выполнены и на их фоне и на общих основаниях начинают выполняться команды очередной итерации, если конечно нет готовых к исполнению команд предыдущих итераций и т.д.

Можете посмотреть более подробно про работу архитектуры тут: http://habrahabr.ru/post/226773/

Статью на хабре я читал давно, сейчас посмотрел, там вроде новые картинки в конце появились.
Раньше в ней не было информации про циклы, а мне был интересен именно этот момент.
Архитектуру работы, описанную в статье, я понял, но циклы - это особенные куски кода, т.е. если обычные куски кода загружаются последовательно и каждая инструкция ложиться на свою клетку, то цикл - это кусок кода, который должен загружаться в клетки не один раз, следовательно для автоматической развёртки его, что-то должно его обходить и загружать повторно инструкции в клетки, ну или действовать как-то так, поэтому и возник такой вопрос. Что-то должно определять закончился ли уже цикл или ещё нет и надо ли его и дальше раскладывать или нет. К примеру бесконечный цикл без счётчика цикла, итерации которого можно выполнять параллельно, но выход из него зависит от алгоритма тела цикла, а этот алгоритм могут посчитать только вычислительные устройства, т.е. клетки. Поэтому если например есть 16 клеток и на все параллельно загрузить 16 итераций, но вдруг последней итерацией будет 8-я ? То как узнать сколько итераций загружать ? Ведь нельзя узнать когда будет осуществлён выход из цикла не обработав его инструкции клетками.

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

Поэтому вот эти вопросы мне интересны. И пока я не знаю, как это в Мультиклете работает.

Смотрите: Мультиклет "не знает", что такое цикл. Для него вся программа -- это цепочка параграфов, связанных инструкциями перехода. Таким образом, цикл будет выглядеть примерно так:

cycle:
...
jmp cycle

iter:
getl #1
getl #2
addl @1,@2
setl @1,#1
setl @4,#2
jmp iter
complete

getl #1

setl @1,#1

L1:
irm 0x00000011
exa #12;
je @1, L2;
jne @2, L1;
rdq #8, x + 0 * 8;        x0
rdq #8, x + 2 * 8;        x2
rdq #8, x + 4 * 8;        x4
rdq #8, x + 6 * 8;        x6
rdq #8, x + 1 * 8;        x1
rdq #8, x + 3 * 8;        x3
rdq #8, x + 5 * 8;        x5
rdq #8, x + 7 * 8;        x7
rdq W + 64 * 8;            W4_1
addc @9, @5;            x0=x0+x1
subc @10, @6;            x1=x0-x1
addc @10, @6;            x2=x2+x3
subc @11, @7;            x3=x2-x3
addc @11, @7;            x4=x4+x5
subc @12, @8;            x5=x4-x5
addc @12, @8;            x6=x6+x7
subc @13, @9;            x7=x6-x7
mulc @9, @5;            W4_1*x3
mulc @10, @2;            W4_1*x7
addc @10, @8;            x0=x0+x2
addc @10, @3;            x1=x1+W4_1*x3
subc @12, @10;            x2=x0-x2
subc @12, @5;            x3=x1-W4_1*x3
addc @10, @8;            x4=x4+x6
addc @10, @6;            x5=x5+W4_1*x7
subc @12, @10;            x6=x4-x6
subc @12, @8;            x7=x5-W4_1*x7
wrq @8, #8, x + 0 * 8;
wrq @8, #8, x + 1 * 8;
wrq @8, #8, x + 2 * 8;
wrq @8, #8, x + 3 * 8;
wrq @8, #8, x + 4 * 8;
wrq @8, #8, x + 5 * 8;
wrq @8, #8, x + 6 * 8;
wrq @8, #8, x + 7 * 8;
complete

Я всё понял, мне нравится данный подход.

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

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

Для многоклеточных процессоров нужна быстрая память, Hybrid Memory Cube наверно подойдёт.

Конечно я понимаю, что всё зависит от финансирования...

Спасибо за ответы.

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

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

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

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

Не знаю, как в Мультиклете это всё реализовано, но было бы интересно это узнать.

logru010 wrote:

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

1. известен адрес начала параграфа;
2. в буферах клеток и коммутаторе есть место;
3. получены значения всех РОНов, изменявшихся в предыдущем параграфе;
4. нет блокировки по очерёдности чтения/записи.

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

P.S. В куске кода FFT я коварно умолчал о том, что там в самом начале программа отключается (установкой соответствующего бита PSW) контроль очерёдности чтения/записи; что, собственно, и позволяет нам параллельно обращаться к разным областям памяти в разных итерациях цикла.

Yaisis wrote:

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

Почти всё верно. За исключением того, что в данном случае толку не будет не от мультиклеточности, а от внутренней "многопоточности" клетки.
Смотрите: доступ к памяти организован так, что на каждом такте ядра каждая клетка загружает одну инструкцию. Таким образом, даже если клетки не успевают заполнять буферы команд, всё ядро в целом выполняет по N инструкций за такт, где N -- число клеток. Если же клетка всё же успевает заполнять буферы, то начинает "играть" ещё и многопоточность, т.е. способность клетки внутри себя запускать на исполнение несколько инструкций за такт (разумеется, при готовности соответствующих ФУ).

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

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

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

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

Не знаю, как в Мультиклете это всё реализовано, но было бы интересно это узнать.

Вот, попытался ответить на вопросы. Спрашивайте ещё ;-)

Почти всё верно. За исключением того, что в данном случае толку не будет не от мультиклеточности, а от внутренней "многопоточности" клетки.

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

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

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

L1:
irm 0x00000011
exa #12;
je @1, L2;
jne @2, L1;
rdq #8, x + 0 * 8;        x0
rdq #8, x + 2 * 8;        x2
rdq #8, x + 4 * 8;        x4
rdq #8, x + 6 * 8;        x6
rdq #8, x + 1 * 8;        x1
rdq #8, x + 3 * 8;        x3
rdq #8, x + 5 * 8;        x5
rdq #8, x + 7 * 8;        x7
rdq W + 64 * 8;            W4_1
addc @9, @5;            x0=x0+x1
subc @10, @6;            x1=x0-x1
addc @10, @6;            x2=x2+x3
subc @11, @7;            x3=x2-x3
addc @11, @7;            x4=x4+x5
subc @12, @8;            x5=x4-x5
addc @12, @8;            x6=x6+x7
subc @13, @9;            x7=x6-x7
mulc @9, @5;            W4_1*x3
mulc @10, @2;            W4_1*x7
addc @10, @8;            x0=x0+x2
addc @10, @3;            x1=x1+W4_1*x3
subc @12, @10;            x2=x0-x2
subc @12, @5;            x3=x1-W4_1*x3
addc @10, @8;            x4=x4+x6
addc @10, @6;            x5=x5+W4_1*x7
subc @12, @10;            x6=x4-x6
subc @12, @8;            x7=x5-W4_1*x7
wrq @8, #8, x + 0 * 8;
wrq @8, #8, x + 1 * 8;
wrq @8, #8, x + 2 * 8;
wrq @8, #8, x + 3 * 8;
wrq @8, #8, x + 4 * 8;
wrq @8, #8, x + 5 * 8;
wrq @8, #8, x + 6 * 8;
wrq @8, #8, x + 7 * 8;
complete

Тут я не все команды знаю, но, как я понял, данный пример подойдёт.
Т.е. в текущей ситуации, допустим процессор имеет в наличии 1000 клеток, а параграф состоит из 40("ДлинаПараграфа = 40") инструкций, то значит эти 40 инструкций загрузятся в первые 40 клеток, но в остальные 960 клеток ничего загружаться не будет, т.к. не выполнены ещё условные команды и поэтому неизвестен адрес следующего параграфа. Теперь допустим, что все инструкции в параграфе выполняются за такт, таким образом, когда становится известен адрес следующего параграфа, то и предыдущий параграф полностью выполнен и за следующий такт загружается опять ровно 40 клеток, а 960 опять простаивают.
Можно сделать следующий механизм: Мы знаем, что есть индексный регистр, имеющий определённое значение "Значение1", также мы знаем, что выхода из параграфа не будет пока это значение не сравняется со значением "Значение2", отсюда можно вычислить "ЧислоПовторенийПараграфа = ABS"(и равно, например, 1000), а теперь, если у нас клетки закольцованы, то начиная с текущей клетки(например "ИндексТекущейКлетки = 5") должны загрузить инструкции в себя следующее количество клеток "КоличествоЗагружаемыхКлеток = ДлинаПараграфа * ЧислоПовторенийПараграфа = 40 * 1000 = 40000", таким образом должны загрузиться клетки начиная с 5 по 40000+5, так как клеток всего 1000, но они закольцованы, то загрузка будет ходить по кругу, если буфер клетки равен 64 инструкции, то в каждую клетку может загрузиться по 40000/1000 = 40 инструкций. Но не всё так просто, т.к. каждая клетка не знает смещение к своей инструкции, то она должна его сама рассчитать, поэтому, если такое реализовать, то n-ное количество тактов будет расходоваться на расчёт смещения инструкции(можно реализовать аппаратно) и расчёт индекса(индексов) для соответствующего номера параграфа("СмещениеИнструкции = ИндексКлетки - ИндексТекущейКлетки - НомерПараграфа*ДлинаПараграфа" и "Индекс = НомерПараграфа + Значение1", где "НомерПараграфа = ОкруглениеВМеньшуюСторону((ИндексКлетки - ИндексТекущейКлетки)/ДлинаПараграфа)") и потом такт на её загрузку.
Таким образом в данной ситуации будет осуществлена загрузка всех клеток в процессоре и программу он выполнит намного быстрее. А таких ситуаций как в примере полно в программировании.
Конечно с помощью множества индексов и возможных комбинаций условий можно реализовывать сложные алгоритмы, которые таким способом, скорее всего, будет сложно предсказать и может даже невозможно без участия человека. Поэтому для данных ситуаций можно иметь дополнительную инструкцию, которая будет указывать сколько раз должен выполнятся параграф или другой вариант -- это предполагать, что следующий параграф будет равен предыдущему и тогда при ложном срабатывании параграфа, весь его результат надо отменять, т.е. наоборот - если подтвердится переход на этот параграф, то только тогда сохранять результат его расчёта. И тут опять возникают идеи...

Не буду описывать дальше все идеи, т.к. долго, надо ещё продумывать всё и может вам это не интересно...

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

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

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

Привет krufter, без тегирования кэша (того что вы сейчас называете внутренней памятью процессора) развернуть циклы не получится. Я писал вам об этом на сайте IXBT.

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

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

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

Здравствуйте.
Стали интересны такие вопросы:

1) Когда вы приступите к десктопным процессорам(надеюсь, что приступите), то будете ли вы в них добавлять защиту по памяти, как в Эльбрусе например ?
Думаю, что это полезная штука и её надо изначально проектировать, чтобы потом было легче.

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

Yaisis wrote:

Здравствуйте.
Стали интересны такие вопросы:

1) Когда вы приступите к десктопным процессорам(надеюсь, что приступите), то будете ли вы в них добавлять защиту по памяти, как в Эльбрусе например ?
Думаю, что это полезная штука и её надо изначально проектировать, чтобы потом было легче.

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

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

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

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

Я просто поинтересовался, что если всё таки приступите к созданию такого процессора, то будете ли добавлять в него защиту по памяти ?

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

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

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

Yaisis wrote:

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

Я просто поинтересовался, что если всё таки приступите к созданию такого процессора, то будете ли добавлять в него защиту по памяти ?

Я думаю добавим всё необходимое, что захочет заказчик.

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

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

Вы правы, у нас есть даже наработки по созданию ускорителей для больших вычислений, которые также могут быть преобразованы и для обработки видео и в дальнейшем трансформированы в видеокарту. У нас при подготовке документации и презентаций по такому проекту проводились симуляции некоторых блоков на частоте в 2ГГц при техпроцессе в 65 нм и была разработана концепция реализации ускорителя. Как появится заказчик, так начнётся процесс патентования и разработки и после этого можно будет опубликовать в открытом доступе структуру работы многопроцессорной платы с PCI интерфейсом и набором 64-х клеточных процессоров.

Можно по подробней про ускорители?
Они общего назначения или для работы с графикой?
Елси графические, то думаю они будут очень востребованы в пару к Эльбрусу, но тогда вопрос: полигональная графика или ray-tracing? Как насчёт ускорителя физики и т.п.

В разработке у нас значился ускоритель общего назначения, рассматривалась стыковка в виде OpenCL.
Были и концепции по разработке графического ускорителя, но тут опять же увеличивается количество работы по его созданию.
Ну и бюджет исчисляется N x 100 млн. руб., где N принимает значения от 4 и далее.

krufter_multiclet wrote:

В разработке у нас значился ускоритель общего назначения, рассматривалась стыковка в виде OpenCL.
Были и концепции по разработке графического ускорителя, но тут опять же увеличивается количество работы по его созданию.
Ну и бюджет исчисляется N x 100 млн. руб., где N принимает значения от 4 и далее.

Что-то непонятно.
У вас такая архитектура, которая изначально выполняет всё параллельно по возможности и в этом её главный плюс, т.е. написал правильный алгоритм и он сразу станет быстро выполнятся. А OpenCL -- это недостаток, который усложняет программирование, конечно есть смысл его добавить для совместимости, но зачем делать на него ставку ?

Вон Интел в своих Xeon Phy говорит, что там используется привычное программирование, т.е. можно просто писать программы на C/C++ без использования всяких OpenCL и HSA, и это Интел выставляет, как преимущество своей архитектуры. И это действительно преимущество. В вашей архитектуре может быть такое же преимущество. Только Интел Xeon Phy - это просто многоядерный процессор, но я заметил, что в многоядерных процессорах, например в моём ноутбучном(да и в десктопном тоже) невыгодно распараллеливать цикл с малым количеством итераций и малым телом, например, если в цикле итераций 100, то теоретически можно было бы разбить его на части по 25 и выполнять на 4 ядрах параллельно(в 4 раза быстрее), но на самом деле это не выгодно, т.к. разбивка занимает много времени и в результате выполнение на одном ядре происходит быстрее, чем на 4-х. А разбивка цикла выгодна для циклов с очень большим количеством итераций или большим телом. Т.е. получается, что я не могу ускорить цикл со 100 итерациями путём распараллеливания на процессорах Интел ? Но лично я нуждаюсь в таком ускорении. Возможно я чего-то не знаю, но пока мне не удалось ускорять маленькие циклы путём распараллеливания на Интелах. В вашем же процессоре, чисто теоретически, не должно возникать таких проблем и любой цикл должен при распараллеливании выполняться быстрее -- в этом и есть одно из преимуществ вашей архитектуры.

Я думаю, что всякие OpenCL и HSA вам надо развивать только для совместимости с соответствующими технологиями и программами, но делать ставку на естественное программирование -- это будет одно из конкурентных преимуществ вашего процессора. Так же лично мне бы хотелось видеть супер производительный процессор с кучей универсальных клеток, без всяких встроенных дополнительных ускорителей, например, как в x86 -- это наборы MMX, SSE, AVX, также встраивают какие-то схемы для ускорения видео и т.д. И эти все схемы задействованы только в исключительных случаях, они не подходят для большей части кода и следовательно, скорее всего, часто простаивают -- это недостаток. Ваш же процессор я вижу так -- есть куча универсальных клеток и нет никаких дополнительный блоков узкого назначения, а любое действие реализуется программно. И это огромное преимущество. Ведь на самом деле, если создать например 1000-клеточный процессор, то скорее всего можно полностью программно реализовать все графические алгоритмы и он сможет конкурировать с видеокартами.

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

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

Я предполагаю, что если бы вы создали ускоритель с 24 Tflops-ной производительностью, то тогда он мог бы вызвать интерес и привлечь инвесторов для дальнейшей разработки, потому что он был бы уникален. Именно его вы бы возили с собой на выставки, на которых привлекаются клиенты(инвесторы). Я например больше не знаю таких ускорителей.

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

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

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

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

Если производительность такого ускорителя общего назначения превысит производительность видеокарт, в расчёте на Вт, то безусловно, надо концентрироваться на производстве такого устройства. Ну и плюс к этому, в теории, можно будет так же полностью занять рынок маршрутизаторов для госучереждений, а это серьёзный профит и устройств таких нужно больше чем компьютеров офисному планктону.
Например (процессор для маршрутизаторов):
http://www.ixbt.com/news/hard/index.shtml?18/66/27

krufter_multiclet wrote:

В разработке у нас значился ускоритель общего назначения, рассматривалась стыковка в виде OpenCL.
Были и концепции по разработке графического ускорителя, но тут опять же увеличивается количество работы по его созданию.
Ну и бюджет исчисляется N x 100 млн. руб., где N принимает значения от 4 и далее.

Мне представляется что на десктопы вам выходить рановато, дороговато и долго.

Yaisis wrote:

Думаю, что вам нужно стремиться в серверный сегмент

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

tyrannozaur wrote:

телекоммуникации - ближняя цель, неттопы/сервера - средняя. всё остальное - потом.

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

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

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

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