Сообщество

krufter_multiclet wrote:

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

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

Вопрос: Чтобы нагрузить процессор по-максимуму и выполнить данную задачу как можно быстрее, то какой лучше способ выбрать ?
Я подозреваю, что способ 4.

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

Yaisis wrote:

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

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

Над периферией обсуждаем CAN, MMU дополнительно + многоканальный DTC.

krufter_multiclet wrote:

Aha wrote:

начиная с фразы krufter-a про "ведь на 16 клеток параллелизма не наберем"

Я такого не писал)

Прошу простить, редко кто появляется еще с ником *_multiclet. Говорим "Мультиклет-форум" подразумеваем "Krufter" ;-)

почти все задачи вычисления и циклы хорошо распараллеливаются

"хорошо" в какой-либо измеримой численно метрике это сколько? Я измерял в свое время различные реализации распространенных алгоритмов, в частности, приведенный выше Stream (он, как раз-таки, хоть на 16, хоть на 64 клетки разойдется, ему только лучше будет от этого), алгоритмы работы со звуком, что-то еще. Я не с потолка цифирь взял и это не результат кодогенерации, это потенциал после dataflow-анализа, к которому стремилась кодогенерация.

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

UPD. Ну да, поглядел я по диагонали документацию... Мультиклет R1 с возможностью реконфигурации в данном случае спасает, пара комментариев:
- наиболее эллегантно это все же будет выглядеть под управлением какой-либо среды, которая будет распоряжаться ресурсом "пул клеток", то есть близко к процессорам общего назначения под управлением какой-либо ОСи. Хотя это дело вкуса, я не настаиваю, я понятия не имею как его сегодня позиционирют создатели, но "сверхнизкое энергопотребление" - это все же ближе к специализированному применению (ну да, а там и специализированные ОСи есть), тем более, что сегодняшние сотовые зачастую мощнее суперкомпьютеров 60-х прошлого века :-)
- ну и Мультиклет R1 - это не 16 клеток по документации, это 4 клетки, или я не ту документацию скачал?!?!? Особо не разбежишься в реконфигурации :-(

krufter_multiclet wrote:

Над периферией обсуждаем CAN, MMU дополнительно + многоканальный DTC.

Controller Area Network это весьма по микроконтроллерски, MMU для нормальных ОС, DMA многокональный - Rulez. В общем, всё - в тему.

Мультиклет R1 с возможностью реконфигурации в данном случае спасает

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

VaalKIA wrote:

Мультиклет R1 с возможностью реконфигурации в данном случае спасает

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

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

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

В серию Microchip PIC32MZ EF вошло 48 моделей 32-разрядных микроконтроллеров с блоками вычислений с плавающей запятой

Вот ещё новость, может пригодится (?) (не понял, почему нельзя использовать для других платформ)
Конфигурируемые контроллеры Microchip MEC14XX предназначены для ноутбуков и планшетов на платформе x86

Вот с форума ixbt недавние "обсуждения/критика" по развитию мультиклета:

Думаю стоит почитать.

sprin wrote:

Вот с форума ixbt недавние "обсуждения/критика" по развитию мультиклета:

Да, очень даже интересно взглянуть с такой стороны.
Кстати, по поводу HBM/HBM2 в контексте энергоэффективности, оказалось, что задача ставилась именно на снижение потребления в сравнении GDDR5, а как там показатели в сравнении с DDR4 я не знаю, но имеет смысл проработать эту тему. Рекомендую вот эту статью: http://www.ixbt.com/video3/amd-hbm.shtml

Вот с форума ixbt недавние "обсуждения/критика" по развитию мультиклета:

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

В цитатах речь идет вроде как про R1, так вот, да, кто он - R1: универсальный процессор, DSP или что-то иное?!? Исходя из этого и пути развития архитектуры будут более понятны, ИМХО

Aha wrote:

Вот с форума ixbt недавние "обсуждения/критика" по развитию мультиклета:

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

В цитатах речь идет вроде как про R1, так вот, да, кто он - R1: универсальный процессор, DSP или что-то иное?!? Исходя из этого и пути развития архитектуры будут более понятны, ИМХО

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

Multiclet R1 сегодня позиционируется, как высокопроизводительный и низкопотребляющий DSP процессор, до универсального идеала нам потребуется выполнить 2 работы (уже начатые) - кодогенератор gcc/llvm-mc и оптимизацию компиляторв до более-менее приемлемых удельных показателей по coremark. Это все, что можно получить на Multiclet R1, далее в проектах новые, более совершенные кристаллы с живучестью (Multiclet L1), для суперкомпьютерных задач (64 клетки и более), обработки видео и телекоммуникаций (16 клеток).

micron_multiclet wrote:

Multiclet R1 сегодня позиционируется, как высокопроизводительный и низкопотребляющий DSP процессор, до универсального идеала нам потребуется выполнить 2 работы (уже начатые) - кодогенератор gcc/llvm-mc и оптимизацию компиляторв до более-менее приемлемых удельных показателей по coremark. Это все, что можно получить на Multiclet R1, далее в проектах новые, более совершенные кристаллы с живучестью (Multiclet L1), для суперкомпьютерных задач (64 клетки и более), обработки видео и телекоммуникаций (16 клеток).

Исчерпывающий ответ, спасибо.

ak_multiclet wrote:

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

Imec и Cadence подготовили к производству первый тестовый 5-нанометровый кристалл

Исследовательский центр imec и компания Cadence Design Systems сообщили о завершении подготовки к передаче в производство первого 5-нанометрового кристалла, рассчитанного на изготовление с использованием литографии в жестком ультрафиолетовом диапазоне (EUV) и иммерсионной литографии с длиной волны 193 нм (193i).
Для проектирования использовалась система Innovus Implementation System

Чтобы подготовить тестовый кристалл, imec и Cadence оптимизировали правила проектирования, библиотеки и технологию размещения и трассировки. Используя в качестве тестового образца процессор, специалисты imec и Cadence вывели несколько вариантов изделия в расчете на технологию EUV и 193i с применением четырехразового формирования структур с самовыравниванием (SAQP). При этом металлические площадки были уменьшены с номинального шага 32 нм до 24 нм.

Для проектирования использовалась система Innovus Implementation System, в которой архитектура с массовым параллелизмом объединена с передовыми приемами оптимизации.
http://www.ixbt.com/news/2015/10/08/imec-cadence-5.html

А вот тут, о том как работает классическая литография:
http://compress.ru/article.aspx?id=20185

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

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

Возможно будет полезно в дальнейших разработках:

Кристовский Г.В., Погребной Ю.Л., Потовин Ю.М. «Заказные блоки памяти на технологии 28 нм для кэш-памяти первого уровня микропроцессора серии “Эльбрус”

взято с сайта МЦСТ:

Доклады специалистов МЦСТ на Международной конференции Микроэлектроника

Новость увидел, может пригодиться в будущем: http://www.3dnews.ru/921671/?feed&utm_source=nova&utm_medium=vk

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

Yaisis wrote:

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

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

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

krufter_multiclet wrote:

Проблемы не возникнут.

Это хорошо.

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

Такой процессор наверно смог бы конкурировать с Intel Xeon Phi, у которого в последней версии 72 ядра, способных в сумме обрабатывать 288 потоков и работать он должен на частоте примерно 1.2 ГГц.
Я думаю, что если бы у вас получилось такого конкурента создать, то вы могли бы выйти на рынок ускорителей и там неплохо заработать на дальнейшее развитие. Тем более ранее мелькала производительность в 24 ТФлопса, такой нет ни у кого ещё. Конечно когда сделаете, может у кого-то уже будет. И так же энергопотребление было написано в районе 40 Вт(не знаю правильно ли я понял), когда другие ускорители потребляют примерно 300 Вт.

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

Я это понимаю.

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

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

У меня ещё вопрос:
Допустим у вас будет 64-клеточный процессор, то там во всех клетках будут присутствовать такие инструкции, как, например, деление ?
А то например в Эльбрусе 6 ALC, а деление присутствует только в двух из них, видимо, чтобы площадь кристалла сэкономить.
Вот мне стало интересно, у вас все клетки будут одинаковы и независимы от других или какие-то могут быть тоже урезаны и в таком случае инструкция деления будет попадать в другие клетки ?

Yaisis wrote:

krufter_multiclet wrote:

Проблемы не возникнут.

Это хорошо.

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

Такой процессор наверно смог бы конкурировать с Intel Xeon Phi, у которого в последней версии 72 ядра, способных в сумме обрабатывать 288 потоков и работать он должен на частоте примерно 1.2 ГГц.
Я думаю, что если бы у вас получилось такого конкурента создать, то вы могли бы выйти на рынок ускорителей и там неплохо заработать на дальнейшее развитие. Тем более ранее мелькала производительность в 24 ТФлопса, такой нет ни у кого ещё. Конечно когда сделаете, может у кого-то уже будет. И так же энергопотребление было написано в районе 40 Вт(не знаю правильно ли я понял), когда другие ускорители потребляют примерно 300 Вт.

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

Я это понимаю.

К этому проекту на предоставленных нам библиотеках для низких топонорм мы и проводили тесты отдельных объемных блоков и результаты показывали, что можно достичь 2 ГГц для этих блоков. Но разработка ускорителя из процессоров в 256 клеток потребует больше 1 года работы, пока, к сожалению, не нашлось человека готового на такой проект.
На kickstarter требуемый объем финансов тоже не собрать. Мы не смогли там на key_p1 собрать. В итоге сделали его сами немногим дольше, чем через полгода.

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

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

У меня ещё вопрос:
Допустим у вас будет 64-клеточный процессор, то там во всех клетках будут присутствовать такие инструкции, как, например, деление ?
А то например в Эльбрусе 6 ALC, а деление присутствует только в двух из них, видимо, чтобы площадь кристалла сэкономить.
Вот мне стало интересно, у вас все клетки будут одинаковы и независимы от других или какие-то могут быть тоже урезаны и в таком случае инструкция деления будет попадать в другие клетки ?

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

krufter_multiclet wrote:

На kickstarter требуемый объем финансов тоже не собрать. Мы не смогли там на key_p1 собрать. В итоге сделали его сами немногим дольше, чем через полгода.

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

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

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

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

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

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

Yaisis wrote:

krufter_multiclet wrote:

На kickstarter требуемый объем финансов тоже не собрать. Мы не смогли там на key_p1 собрать. В итоге сделали его сами немногим дольше, чем через полгода.

Я думаю, что ускорители людям интересней, чем электронные ключи.

Безусловно.

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

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

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

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

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

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

VaalKIA wrote:

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

Это я не согласен с вами. Любой программист при оптимизации кода старается избавиться от инструкций деления и заменить их умножением, т.к. умножение примерно в 30 раз быстрее, чем инструкция деления. Таким образом теоретически в коде присутствует больше инструкций умножения, чем деления. Сама инструкция деления, наверно, по схеметехнике сложнее инструкции умножения и следовательно занимает больше транзисторов. Теперь представим, что при текущем техпроцессе в процессор помещается 64 клетки и допустим, если мы урежем и сделаем инструкции деления не в каждой клетке, а только в четверти из них, то сможем увеличить количества клеток в процессоре в 2 раза, т.е. их станет уже 128. Но с учётом того, что в коде больше инструкций умножения, чем деления, мы не потеряем в производительности, а наоборот ускорим её примерно в 2 раза.
Возьмите к примеру матричные преобразования, которые используются в 3D-графике и ещё много где -- там везде используются в основном одни умножения со сложениями.
Конечно, если урезать инструкции деления например, то надо смотреть, какой положительный эффект они могут дать. Как в моём примере(от балды) положительный эффект был в виде увеличения количества клеток в 2 раза, а это было бы круто, но если в реальности таким образом будет добавлено например всего 5-лишних клеток, то может и нет смысла ничего урезать, т.к. мы потеряем 48 делений и получим всего 5 умножений, что не целесообразно(да и первый вариант я тоже не знаю целесообразен он или нет) -- это всё надо оценивать.

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

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

И то и то важно.
Чем меньше схема(клетка) занимает, тем больше схем(клеток) они смогут поместить в кристалл.

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

И тут не верно.
Допустим есть в коде очень непопулярная инструкция, например получения количества тактов пройденный процессором с момента его старта. Какой смысл плодить такую инструкцию во всех клетках, если она очень редко используется в коде ?

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

Она не подрезала ядра, а наоборот увеличивала их. Она в одно ядро вместо одного целочисленного блока вставила 2, т.к. наличие дополнительного блока приводило к увеличению кристалла всего на 10%, но в целочисленных вычислениях могло повысить производительность в 2 раза.
Только она нечестно называла процессоры, например 8-ядерными, когда в реальности там было полноценных всего 4 ядра, поэтому конечно это можно расценить, как урезание ядра.
И не взлетело не из-за такого метода, а из-за самой неудавшейся архитектуры, да и блоков FPU тоже должно быть много -- у Интел их больше было и Интел выигрывал, да и сама архитектура у него пока лучше.

И да, любую инструкцию аппаратно можно выполнить за один такт.

Операция умножения на Интеле аппаратно выполняется за 3 такта.
Операция деления на нём же аппаратно -- примерно за 40 тактов.
Есть там и другие более прожорливые операции.

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

Гипер-треадинг -- это очень полезная технология и он реально нужен.
Он не даёт вычислительным блокам простаивать и загружает их из других потоков.
Для сравнения, я делал многопоточную программу и запускал её на своём 4-ядерном процессоре с гипер-треадингом, т.е. в сумме было 8 ядер, 4 из которых виртуальные.
При разбитии процесса вычисления на 4 потока была получена производительность, соответствующая производительности процессора без гипер-треадинга и соответствующая производительности 4-ядерному процессору.
При разбитии процесса вычисления на 8 потоков была получена производительность, равная 6-ядерному процессору, т.е. 4 виртуальных потока принесли производительность равную 2-м дополнительным ядрам, которых в реальности нет в процессоре.
В результате при количестве транзисторов в процессоре примерно равным 4-ядерному процессору, гипер-треадинг дал производительность 6-ядерного процессора, что очень круто и очень полезно.

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

Это какая-то вариация VLIW по типу Итаниума и Трансметы

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

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

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

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

Допустим есть в коде очень непопулярная инструкция, например получения количества тактов пройденный процессором с момента его старта. Какой смысл плодить такую инструкцию во всех клетках, если она очень редко используется в коде ?

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

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

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

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

Yaisis wrote:

Допустим есть в коде очень непопулярная инструкция, например получения количества тактов пройденный процессором с момента его старта. Какой смысл плодить такую инструкцию во всех клетках, если она очень редко используется в коде ?

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

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

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

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

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

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

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

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