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

[zeaman]

В Эльбрусе/МЦСТ кстати никто не работал?

[dmdimon]

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

Все совсем не так плохо.

А процессор приколен внутренними связями каждый с каждым.

[Scarecrow]

... В смысле? В Дании им денег не дали и они теперь в Сколково переехали?

Датчане давали. Это российские им долго денег не давали, если я правильно понял. Впрочем их пиар - их, а не моё дело.

[Настрел]

C= A+B;
D=A+C;
превращается в:
C=A+B;
D=A+A+B;

Слушайте, Зюхман, вы это можете втюхивать  Старому, или Валерию. Хотя, первый, и без того понимает ваш уровень. Но тут есть люди знакомые с приграммированием.
D=1+2
C=1+3 вычисляются на раз, параллельно.
А если вы говорите про прямую адресацию, то:
A - вы нихрена не знаете как в символьной записи отделить адреса от значений.
B - применимость прямой адресации в много-процессорно-ядерных системах.
C - применимость прямой адресации в любых системах вообще.
A+C - вы нихрена не знаете про реализации мьютексов.

[Scarecrow]

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

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

[zyxman]

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

Все совсем не так плохо.

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

А процессор приколен внутренними связями каждый с каждым.

Вот это тот самый момент, который меня смущает и исследование которого я хочу увидеть от разработчиков: мало того, что не бывает абсолютно мгновенных внутренних связей, так ведь еще и речь идет о многовходовой связи, что еще более всё усугубляет.
Ну вот элементарный пример:
1. если у нас на шине сидит всего два черных ящика, "А" и "Б", тут просто - есть два буфера возле каждого ящика - когда "А" посылает информацию, она с некоторой задержкой "ы" попадает в буфер, который может считать "Б" за время "ё";
будет случаться ситуация, когда "Б" будет получать инфомацию с задержкой 2*"ё"+"ы"
2. то же, но буфер один - в таком случае когда "А" читает этот буфер, "Б" ждет минимум время 2*"ё" плюс арбитраж;
2. если у нас на шине 3 ящика "А", "Б", "В" - в таком случае если буфер один на всех, то уже пропускная способность этого буфера делится на троих, то есть будут ситуации, когда кто-то уже будет ждать 3*"ё"+2 арбитража;
3. если у нас 3 ящика с 3 буферами (3 копии), то максимальная задержка уже будет 2*"ы"+2*"ё" (считаю что буфер копирует сам)
И плюс тут уже нюанс, что должно быть независимых 6 копирующих устройств, либо шина кольцевая, и тогда задержка передачи по звеньям будет двухкратной.
4. если у нас 4 ящика с буферами, то уже должно быть 12 копирующих устройств (каждый каждому), либо задержка в части случаев будет трехкратной, либо пропускная способность шины уже делится на четверых;
Итого у нас задержка будет в любом случае расти, причем существенно нелинейно, и где-то так навскидку на 8 клетках затраты на копирование превысят выигрыш от клеточности в случае коротких параллельных цепочек.

[zyxman]

C= A+B;
D=A+C;
превращается в:
C=A+B;
D=A+A+B;

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

А скажите-ка мне, человек "знакомый с программированием", сколько команд выполняет современный процессор за время произвольного чтения/записи ОЗУ?
И второй вопрос, в вашей реальности синхронизация между кэшами происходит святым духом, или всё-же через посредничество не самой быстрой шины? И соответственно вопрос, сколько команд выполняет процессор за время синхронизации между кэшами?

[Татарин]

либо пропускная способность шины уже делится на четверых

Именно так и есть.

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

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

В общем, идея интересная. Минусы тоже очевидны, но тут вопрос, что перевесит. Судя по тому что они заявляют о потреблении, плюсов всё-таки по факту вышло больше.

[dmdimon]

а вы уверены, что каждый с каждым у них реализован через общую шину, а не реальными линками? Там пока не так много клеток...
Опять-же сходная задача на бытовом уровне  вроде как успешно решена в PS3 Cell

[goran d]

а вы уверены, что каждый с каждым у них реализован через общую шину, а не реальными линками? Там пока не так много клеток...
Опять-же сходная задача на бытовом уровне  вроде как успешно решена в PS3 Cell

Для 16 клеток каждый-с-каждым нельзя реализовать отдельными проводами, т.к. есть только 9-10 слоев провода в чипе. Кроме общей шины можно к примеру поставить в матрицу 4x4 и иметь связи только с соседними ядрами.

[goran d]

а вы уверены, что каждый с каждым у них реализован через общую шину, а не реальными линками? Там пока не так много клеток...
Опять-же сходная задача на бытовом уровне  вроде как успешно решена в PS3 Cell

Для 16 клеток каждый-с-каждым нельзя реализовать отдельными проводами, т.к. есть только 9-10 слоев провода в чипе. Кроме общей шины можно к примеру поставить в матрицу 4x4 и иметь связи только с соседними ядрами.

Кстати, Интел Terascale  был реализован в матрице, где у каждой колонки есть "рутер" который связан со всеми чипами в колонке, а "рутеры" связаны между собой.

[Татарин]

а вы уверены, что каждый с каждым у них реализован через общую шину, а не реальными линками? Там пока не так много клеток...
Опять-же сходная задача на бытовом уровне  вроде как успешно решена в PS3 Cell

Конкретно в имеющемся кристалле - общая шина. Инфа с хабра от человека причастного и непосредственно работающего с предметом (правда, он не железячник).

[dmdimon]

а вы уверены, что каждый с каждым у них реализован через общую шину, а не реальными линками? Там пока не так много клеток...
Опять-же сходная задача на бытовом уровне  вроде как успешно решена в PS3 Cell

Для 16 клеток каждый-с-каждым нельзя реализовать отдельными проводами, т.к. есть только 9-10 слоев провода в чипе.

Вы уверены? у меня навскидку получается 8 сигнальных слоев для 16 ячеек - хотя я могу и ошибаться, много времени прошло.

[zyxman]

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

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

Опять-же сходная задача на бытовом уровне  вроде как успешно решена в PS3 Cell

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

Для 16 клеток каждый-с-каждым нельзя реализовать отдельными проводами, т.к. есть только 9-10 слоев провода в чипе. Кроме общей шины можно к примеру поставить в матрицу 4x4 и иметь связи только с соседними ядрами.

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

[dmdimon]

а вы уверены...

Я уверен, потому что они сами в документации пишут про использование двухвходовой памяти FPGA

так то же внешняя память, а это - внутренний интерконнект. Впрочем, я не настаиваю.

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

или приличного аппаратного супервайзера - если очереди короткие а шина толстая... или использование GCD http://en.wikipedia.org/wiki/Grand_Central_Dispatch  или аналогичной технологии.

Но это так, адвокатство дьявола.

[zyxman]

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

Зависит от задачи и от качества компилятора.
- Если задача позволит распараллелить а компилятор это использует, то будет и на тысяче клеток профит, и даже при соединении клеток эзернетом :lol:
А прелесть суперскаляров в том, что для них старый код можно использовать и он автоматически работает быстрей.

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

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

Изначально RISC-подобные команды заранее заточены для перестановки - три.

В смысле это у вас плюс или минус?

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

Нууу, хороший RISC уровня MIPS 4000 еще больше выиграет от умного компилятора.
Точнее вся печаль, что RISC УЖЕ выигрывают, а тут кроме ассемблера еще ничего нет, и не факт что будет достаточно быстро.

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

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

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

Возможность более сложной реализации коммутатора (против неизбежных внутренних шин у суперскаляров) - шесть.

Более сложный коммутатор отъест площадь кристалла, и не факт что это лучше увеличения числа регистров или кэша.

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

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

В общем, идея интересная. Минусы тоже очевидны, но тут вопрос, что перевесит. Судя по тому что они заявляют о потреблении, плюсов всё-таки по факту вышло больше.

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

[zyxman]

а вы уверены...

Я уверен, потому что они сами в документации пишут про использование двухвходовой памяти FPGA

так то же внешняя память, а это - внутренний интерконнект.

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

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

Когда и если будет ASIC и компилятор ЯВУ, то уже будет совсем другая песня - там мы увидим и хитрые линки, и изощренные коммутаторы.

[goran d]

а вы уверены...

Я уверен, потому что они сами в документации пишут про использование двухвходовой памяти FPGA

так то же внешняя память, а это - внутренний интерконнект.

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

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

Когда и если будет ASIC и компилятор ЯВУ, то уже будет совсем другая песня - там мы увидим и хитрые линки, и изощренные коммутаторы.

Так на сайте мултиклета есть фотография ASIC-а, не только FPGA!

[zyxman]

Так на сайте мултиклета есть фотография ASIC-а, не только FPGA!

Я там слишком обобщил - вообще ASIC бывают разные:
есть чисто кастомные дизайны, когда заказчик разрабатывает все маски сам, то есть сам разрабатывает все ячейки вплоть до уровня транзисторов;
есть библиотеки ячеек - там заказчик берет готовые элементы у производителя (например целые регистры) и из них почти как из кубиков конструирует свой дизайн;
- Есть базовые матричные кристаллы (англ Uncommited Logic Array) - в принципе оно близко к библиотекам ячеек, но чуть проще потому что проектируются не сами ячейки а только связи между ними, а ячейки производитель производит заранее стандартизированные;
есть structured ASIC - суть что это практически та-же FPGA, только связи в ней прошиваются заказываемой металлизацией а не записаны в ОЗУ, и соответственно, такая ASIC делается почти простой перекомпиляцией проекта с FPGA в ASIC - ЕМНИП, structured ASIC дает выигрыш по частоте, потреблению и задержке в сравнении с FPGA где-то порядка 60%-100% (а чисто кастомный даст до 10 кратного улучшения).

Лучше всего по плотности и по производительности чисто кастомный дизайн, но он слишком дорогой для малых партий; библиотеки ячеек чуть дешевле, но тоже для малых партий сложновато.
БМК и structured ASIC плохи тем что кристалл используется далеко не на 100%, и уже появляются похожие на FPGA ограничения - ячейки далеко и задержка большая и поэтому низкие частоты.

Так вот, то что мы видим скорей всего structured ASIC (ну очень там говорящие обозначения ), а я подразумевал хотя-бы БМК.
Но если у них такой хилый БМК, то всё очень плохо.

[dmdimon]

если будет ... компилятор ЯВУ, то уже будет совсем другая песня

Судя по даташиту есть компилятор С:
http://www.multiclet.com/index.php?option=com_content&view=article&id=96%3Amcp0411100101&catid=39%3Amulticellular-processors&Itemid=62&lang=en
Ну и вот такие заявления интригуют конечно:
A cell of typical multicellular processor on a frequency of 5 GHz will reach 10 GFlops performance, 64-cell crystal, accordingly, will reach 640 Gflops performance with 7.7 W power consumption. Teraflops supercomputer with 1.2 Tflops performance and 15.4 W total energy consumption will be based on two 64-cell processors, 2000 crystals will provide 1.2 Pflops.

It is important to note that such performance is reached independent from class of problems.


Кроме того, в тему зафлужения шины:
Multicellular architecture patented by MultiClet Corp. in contrast to traditional von-Neumann architecture doesn't operate with rank-order commands, but with statements which consist of commands. Operations within the statements are launched without memory involvement.