[MrYuran 34]

Лично я понял только (если правильно понял), что в "мультиклеточном" процессоре "a+b" потребует 2 такта (как минимум, тк непонятно про накладные расходы) и 192 бита в программной памяти (3 слова * 64 бита).

А я понял, что нету никаких двух тактов. Вообще никаких тактов нету.

Все операции асинхронны и производятся по мере готовности данных.

Плюс, ассоциативная адресация вместо физической. Неважно, в какие клетки раскидали промежуточные операции, данные все равно встретятся в нужном месте в нужное время.

[Leka 1]

Сравним обычную, и "мультиклеточную" (как понял) реализацию выполнения a=b+c; все данные - в регистрах.

 

Обычная 3х-операндная архитектура:

одна команда, один такт, порядковый номер команды задается неявно - через адрес команды в памяти команд, в команде(32 разряда) указывается только код операции и номера трех регистров-операндов:

номер==адрес: (add a,b,c)

 

"Мультиклеточная" архитектура:

a=b+c при компиляции разбивается на 4 микрокоманды(64 разряда каждая), 3 такта:

read b; read c; add; write a;

микрокоманды кодируется с явным указанием своих порядковых номеров (физический адрес команды уже не несет никакой информации) и номеров команд-источников:

адрес0: (номер3, write a )

адрес1: (номер0, read b )

адрес2: (номер2, add номер0 номер1)

адрес3: (номер1, read c)

 

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

 

В итоге "мультиклеточная" архитектура многократно проигрывает обычной, по тактам, объему кода, площади кристалла. Если я неправильно понял "мультиклеточную" архитектуру - объясните мне понятно. (По поводу клока - он есть, см "даташит").

Edited April 17, 2012 by Leka

[MrYuran 34]

Сравним обычную, и "мультиклеточную" (как понял) реализацию выполнения a=b+c; все данные - в регистрах.

 

Обычная 3х-операндная архитектура:

одна команда, один такт, порядковый номер команды задается неявно - через адрес команды в памяти команд, в команде(32 разряда) указывается только код операции и номера трех регистров-операндов:

номер==адрес: (add a,b,c)

 

"Мультиклеточная" архитектура:

a=b+c при компиляции разбивается на 4 микрокоманды(64 разряда каждая), 3 такта:

read b; read c; add; write a;

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

[LV26 0]

причём с производством готов помочь российский процессорный гигант Ситроникс.

 

буга-га-га-га

гигант...

Ситроникс - дровосеки и ничем кроме распила реально не занимаются.

Это мне так кажется - я на них работал.

[Leka 1]

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

Выборка команды из памяти и проч. - конвейеризируется, а собственно исполнение арифметической команды обычно занимает 1 такт - видно по структуре конвейера (стадия execute):

http://ru.wikipedia.org/wiki/%D0%92%D1%8B%...%B9%D0%B5%D1%80

Другие(дополнительные) стадии конвейера и для "мультиклеточной" архитектуры будут.

 

[Soflover 0]

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

[Wic 0]

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

[Мур 5]

И где обещанное?...

http://www.new-electronics.info/programm

[Postoroniy_V 0]

.......

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

 

В итоге "мультиклеточная" архитектура многократно проигрывает обычной, по тактам, объему кода, площади кристалла. Если я неправильно понял "мультиклеточную" архитектуру - объясните мне понятно. (По поводу клока - он есть, см "даташит").

1) по тактам я не понял почему

2) по обьёму кода, да но не многократно, я бы сказал 20-30%

3) площадь кристала, х.з. как сравнить. и я бы сравнивал 4 клеточный с 4-х ядрённым мипсом,

предлагаю разобраться как следует.

-----------------------

target: z=SUM[(ai+bi)*ci-(ai-bi)*di]

тоесть на С так

for(int z=0,i=0;i<10;i++)

z=z+(a+b)*c - (a-b)*d)

 

triads:

1)sum_ab=a+b

2)sub_ab=a-b

3)mult_abc=1*c

4)mult_abd=2*d

5)sub34=3-4

6)target=target+sub34

 

(tag_2, <=0) i
(tag_1, <=0) target

(tag0, read [a+tag_2])
(tag1, read [b+tag_2])
(tag2, read [c+tag_2])
(tag3, read [d+tag_2])
-- вероятно эти таг0-3 можно было бы заменить на некую команду (tags0,1,2,3 read [a+tag_2<<2]). х.з.

(tag4, tag0+tag1)
(tag5, tag0-tag1)
(tag6, tag2*tag4)
(tag7, tag3*tag5)

(tag8, tag6-tag7)
(tag_1, tag_1 + tag8)
(tag10, store tag_1 to target adr)
(tag_2, tag_2 +1)- 

(tag_2, tag_2 EQU 10)
(tag11,jmpNZ tag_2, adr to tag0)

пояснения + упрощения

1)адреса команд не указаны, есть привязка к tag-у, тоесть это ассоциация как команды так и результата после выполнeния команды(для простоты tag это регистр ;) ).

2)показаны только 1 стадия конвейра exec

3)все стадии конвейра - 1 такт

4)все данные в cache (cache hit rate=1)

 

в данном и невероятно простом примере видно что ускорение выполнения может быть не более чем в 4 раза и выводы:

1) стадия fetch должна быть сделана следующим образом(чтобы было "4х" ускорение):

- либо широкий порт инструкций в "4 раза шире"

- либо в "4 раза быстрее"

2)если каждая клетка это очень примитивный (одно лишь АЛУ) cpu, то автомат "дирижирующий" этим ансамблем видиться очень не простым.

3) и действительно в случае отказа 1 клетки, катастрофы не случится, пока есть хотя бы 1 работающая.

4) для случая 16 клеток ускорение расти не будет, будет тем же что и для 4-х клеток (для данного примера)

5) из п4 следует что для 16 клеток, возможно(?) выполение в параллель ещё какого то кода(справится ли fetch?)

6) тоесть данный алгоритм _не заточен_ для выполнения на 16 клетках, и следовательно нельзя говорить о "естественном" параллелизме

 

вообщем этот мультиклет что-то вроде systolic array cpu

http://web.cecs.pdx.edu/~mperkows/temp/May...-Processors.pdf

 

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

[Poluektovich 0]

И где обещанное?...

http://www.new-electronics.info/programm

Семинаров они не устраивают. Там есть стенд с представителями и распечатанными даташитами.

 

[Uuftc 0]

А что, москвичи, кому не влом - загляните, пожалуйста, узнайте: есть ли оно живьём, а не на FPGA? И здесь расскажите.

Рассказываю:

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

 

З.Ы. Пригласил их на наш форум, думаю, многое станет ясно, когда появится представитель. Или не появится...

 

З.З.Ы. Меня терзают смутные сомнения (с)

[Leka 1]

предлагаю разобраться как следует

 

1) по тактам я не понял почему

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

 

2) по обьёму кода, да но не многократно, я бы сказал 20-30%

Непонятна разрядность микрокоманды, если 64 разряда, то уже в 2 раза больше (как минимум)

 

3) площадь кристала, х.з. как сравнить. и я бы сравнивал 4 клеточный с 4-х ядрённым мипсом

Идеология Multiclet: компилируем код на ЯВУ в очень мелкие инструкции, аппаратно параллелим их, и получаем "превосходство" в MIPS и MIPS/W. Пример: "a=b+c;" компилируем в "rd b; rd c; add; wr a;", параллельно выполняем их на 100МГц, и получаем дутые 400MIPS. Так что сравнивать надо с обычным 1-ядерным процем (или с DSP, в зависимости от архитектурных примочек вроде индексных регистров и проч.) Ассоциативная адресация, буфера, и проч - отнимает площадь, ничего не давая взамен.

 

(tag_2, <=0) i

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

 

(tag0, read [a+tag_2])

если использовать специальные индексные регистры для косвенной адресации, тогда и сравнивать будем с DSP-процессором. А если сравнивать с универсальным( ai=a+i; ai=*ai ), то индексное чтение надо делить на несколько микрокоманд:

(tag00, read a)

(tag01, tag00+tag_2)

(tag02, read [tag01]) (?)

 

Ввод специальных DSP-примочек в "мультиклеточную" архитектуру уже настораживает - зачем это, если можно просто нарастить число клеток, сохранив чистоту концепции?

 

и действительно в случае отказа 1 клетки, катастрофы не случится, пока есть хотя бы 1 работающая

У каждой клетки своя независимая память команд, в случае отказа весь этот код пропадает --> катастрофа.

 

вообщем этот мультиклет что-то вроде systolic array cpu

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

 

 

[Postoroniy_V 0]

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

 

 

Непонятна разрядность микрокоманды, если 64 разряда, то уже в 2 раза больше (как минимум)

 

 

Идеология Multiclet: компилируем код на ЯВУ в очень мелкие инструкции, аппаратно параллелим их, и получаем "превосходство" в MIPS и MIPS/W. Пример: "a=b+c;" компилируем в "rd b; rd c; add; wr a;", параллельно выполняем их на 100МГц, и получаем дутые 400MIPS. Так что сравнивать надо с обычным 1-ядерным процем (или с DSP, в зависимости от архитектурных примочек вроде индексных регистров и проч.) Ассоциативная адресация, буфера, и проч - отнимает площадь, ничего не давая взамен.

 

 

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

 

 

если использовать специальные индексные регистры для косвенной адресации, тогда и сравнивать будем с DSP-процессором. А если сравнивать с универсальным( ai=a+i; ai=*ai ), то индексное чтение надо делить на несколько микрокоманд:

(tag00, read a)

(tag01, tag00+tag_2)

(tag02, read [tag01]) (?)

 

Ввод специальных DSP-примочек в "мультиклеточную" архитектуру уже настораживает - зачем это, если можно просто нарастить число клеток, сохранив чистоту концепции?

 

 

У каждой клетки своя независимая память команд, в случае отказа весь этот код пропадает --> катастрофа.

 

 

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

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

2)у z80 есть индексная адресация, вывод - он DSP! и можно с з80 сравнивать.

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

4)в systolic есть связи сосед-сосед, в клеточном - клетки соединены неявно через коммутационнцю среду каждая-скаждой.

 

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

 

з.ы. надо попробовать "клеточный" заиплементировать на досуге :smile3046:

 

 

[Uuftc 0]

А меня вот еще интересует вопрос - а как может обстоять дело с условными переходами в такой архитектуре ?

Имхо - это может быть весьма слабым местом.

[MrYuran 34]

А меня вот еще интересует вопрос - а как может обстоять дело с условными переходами в такой архитектуре ?

Имхо - это может быть весьма слабым местом.

А в чем проблема? Начать обрабатывать параллельно обе ветви, а потом ненужную отбросить.