Сообщество

ak_multiclet wrote:

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

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

VaalKIA wrote:

ak_multiclet wrote:

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

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

Вот не совсем так. Блок флагов совсем не обязан подключаться так же, как память. Мы его можем засунуть в блок РОНов, например. И получать к нему доступ инструкциями get/set. Никаких проблем с кэшем, MMU и пр.

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

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

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

Вот не совсем так. Блок флагов совсем не обязан подключаться так же, как память. Мы его можем засунуть в блок РОНов, например. И получать к нему доступ инструкциями get/set. Никаких проблем с кэшем, MMU и пр.

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

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

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

Я, честно говоря, за то, что бы при модификации одной ячейки двумя ядрами было не известно кто первый. Разделяемые данные должен контроллировать программист для получения предсказуемого результата. И мы обсуждаем две модели подобного подхода: RMW и, Линки для отслеживания изменений, как в АРМ, ну или что-то своё. Вот я не понимаю что именно вы предлагаете (или с чем не соглашаетесь), я предлагаю гибрид этих подходов.
У вас, примерно то же написано, что я и говорю. Флаги вообще не видны программисту, для него стандартный набор RMW комманд, для обеспечения консистентности перезаписыаемых данных, а уже сами эти комманды НЕ блокируют шину, как в оригинале, а используют ФЛАГИ (линки) для контроля своей работы. Но поскольку это получается транзакционная модель (флаг операция поставила и он показал, что пока ядро операцию сравнения (внутри комманды CAS) проводило и сами флаги ставились что-то уже изменилось и разрешение перезаписи реальзовывать нельзя, соответственно, надо ещё раз повторить начиная с флагов и так, пока за наши такты выполнения этой инструкции CAS не будет вмешательства в данные для этой инструкции от других ядер, только тогда операция сравнения и возможная перезапись будут корректными). Соответственно, никаких чудовищных рекурсий и циклов с прерываниями в процессе жизни флагов не будет, флаги будут "работать" только несколько тактов конкретных инструкций. А программист получает проверенный механизм RMW позволяющий проверять и корректно изменять любые данные в любой сложности программах и ему не надо бороться с ограничением линков и в то же время RMW не используют блокировки и работают быстро.
Кстати, с удивлением узнал, что деленеие на линейки L1/L2 кеши, это не прихоть, а как раз обеспечение межядерного взаимодействия, по принципу работы кеши подразделяются на false и true sharing и суть в том, что оба ядра берут одни и те же данные в свой l1 кеш, одно из ядер что-то в своём кеше модифицирует второе ядро должно свой кеш сбросить, а первое вернуть изменения в память. Получается полная фигня - данные вроде как разные, вроде как должны кешироваться, даже более того, одно я дро модифицирует, а второе только читает, но благодаря тому что даныне лежат близко и попадают в кеш одной линейкой, получается такая фигня, для разрешения ситуации l2 кеш делается общим, заменяя как бы обычную память и всегда содержит данные персоанльных кешей ядер (я это к тому, что для линков там тоже ад и персональные кеши перезаписываются каждую инструкцию). Тоже получается не быстро, но быстрей чем с памятью. В общем кеш, в многоядерных системах - зло.

Yaisis wrote:

ak_multiclet wrote:

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

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

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

VaalKIA wrote:

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

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

Можно даже примерно подсчитать скорость на бесконечном числе ядер -- допустим создание узла процесса и его запуск занимает такт, тогда запуск 1000 процессов занял бы 11 тактов и примерно столько же тактов(может побольше) заняло их уничтожение. А за 64(+1) такта уже могло бы запуститься 64 триллиона процессов.

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

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

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

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

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

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

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

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

Zveruga wrote:

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

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

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

Zveruga wrote:

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

Насколько я понимаю, у Мультиклета нет кеша, а так же у каждого "ядра" есть своя локальная память.

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

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

bav wrote:

Zveruga wrote:
Наличие же пула свободных клеток позволит частично решить проблему с прерываниями путем динамического выделения при наличии свободных.
А не как сейчас когда клетки освобождаются в никуда.

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

VaalKIA wrote:

bav wrote:

Zveruga wrote:
Наличие же пула свободных клеток позволит частично решить проблему с прерываниями путем динамического выделения при наличии свободных.
А не как сейчас когда клетки освобождаются в никуда.

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

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

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

Zveruga wrote:

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

В Мультиклете нет кэша и вроде не планируется, поэтому назовём это "буфером параграфов".

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

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

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

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

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

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

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

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

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

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

Yaisis wrote:

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

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

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

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

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

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

VaalKIA wrote:

Я вообще считаю, что кеш, это - контрпродуктивно.

Кэш придумали для того, чтобы ускорить доступ к памяти, т.к. кэш намного быстрее ОЗУ, но быстрой памяти пока не бывает много.
Скоро возможно ОЗУ переместится в процессор и будет работать со скоростью кэша, тогда кэш будет не нужен. Интел уже задумалась об переработке существующего ПО в связи с развитием памяти 3DXpoint.

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

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

у нас давно уже ОС потребляют значительные ресурсы и много чего делают в фоне.

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

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

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

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

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

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

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

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

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

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

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

Вернусь к вопросу о блокировках, транзакциях и т.д.
Я думаю, что хотя бы одну атомарную инструкцию надо добавить в процессор, например инструкцию сравнения с обменом, в которую будет передано три параметра:
1) адрес памяти
2) значение сравнения
3) новое значение
Если значение по адресу в памяти равно сравниваемому значению, то данная инструкция заменяет его на новое значение.
Если ей удалось присвоить новое значение, то она возвращает истину, иначе - ложь.

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

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

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

IBM и Samsung разработали 11-нм память STTMRAM

У Everspin готовы первые в отрасли микросхемы памяти ST-MRAM плотностью 256 Мбит; они изготовлены на мощностях Globalfoundries

Микросхемы плотностью 256 Мбит Everspin относит к третьему поколению ST-MRAM, отмечая, что поддержка DDR3 упрощает их использование в твердотельных накопителях и контроллерах RAID. Производитель уже разрабатывает микросхемы ST-MRAM плотностью 1 Гбит с интерфейсом DDR4. Производственным партнером Everspin выступает компания Globalfoundries.

В модулях Aupera Aup-AXL-M128 типоразмера M.2 используется память ST-MRAM

Магниторезистивная память ST-MRAM (Spin-Torque Magnetoresistive RAM) характеризуется высоким быстродействием и долговечностью, а также способностью хранить информацию в отсутствие питания. По скорости записи ST-MRAM превосходит флэш-память NAND более чем в 100 000 раз. В отличие от флэш-памяти, в ST-MRAM нет необходимости в распределении нагрузки, поскольку износ при записи практически отсутствует.
Этим определяются достоинства модулей Aup-AXL-M128, оснащенных 128 МБ памяти ST-MRAM. По словам производителя, этого достаточно, чтобы использовать модули в качестве кэш-памяти, буферов и хранилища метаданных. Сама компания Aupera включает их в конфигурацию твердотельных массивов Aup-Litesaber-V2000.

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

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

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

Yaisis wrote:

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

Я уже высказывался на эту тему, как раз там, где обсуждали инструкции для оперирования разделяемыми ячейками. Суть потока - это логическая еденица программирования. Это так же важно как процедуры и функции и точно так же как современное программирование немыслимо без разбиения программ на части в виде отдельных процедур (хотя сплошной код писать есть возможность как и раньше), точно так же потоки или процессы это данность от которой уже не избавиться (возьмите хотя бы две независмые программы в ОС - это уже три процесса/потока глупо было бы сетовать, что можно всё это слепить в одну программу тогда бы это исполнялось эффективней - не будет, потому что это разные программы и архитектура именно такого исполнения имеет огромный смысл в самом создании программ, так же и с потоками). Поэтому априори потоков/процессов будет несколько и те процессоры, которые не будут предоставлять их эффективное взаимодействие не будут интересны в будущем. Соответсвенно, должны быть комманды которые мы обсуждали:
http://multiclet.com/community/boards/3/topics/1032?r=1524#message-1524

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

VaalKIA wrote:

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

Это итак понятно, только непонятно зачем вы мне это пишите ?
Если вы внимательно читали, то должны заметить, что я делаю акцент не на одном потоке.

...поэтому меня и зацепил ваш аргумент "может не эффективно".

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

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

micron_multiclet wrote:

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

Отрадно слышать, что, возможно, у вас большие заказы.
Про очередную оптимизацию компилятора - тоже на сайте заметил уже давно, вообще он у вас очень быстро взлетел, не теряйте темп.
Информацию - вы единственный источник информации, пока ваша платформа не распространилась. Это ардуина и распберипи могут себе позволить выпустить что-то, и об этом сразу же будут трубить все кому не лень, но не вы. Вы на каждый чих должны самостоятельно подробно освещать любую свою работу, это очень хорошо будет влиять на общественност и на уверенность ваших заказчиков при выборе платформы. Впрочем, я давно говорил, что это прямые вложения в ваш бренд, а стоимость бренда это кредиты и благосклонность заказчиков, да и нанять умных специалистов тоже проще. Никакие вложения бабла в рекламные акции не дадут того прироста к стоимости бренда, чем простые технические статьи, на правильных ресурсах о делах компании, пользуйтесь тем, что вы разрабатываете инновационный продукт и просто рассказывая о нём, это - чертовски интересно всем. 4 часа одного сотрудника после работы 1 раз в неделю на освещение событий и, возможно, это даст вам какого-то крупного заказчика в будущем.
Времени прошло - уйма, расскажите подробней про очередную оптимизацию компилятора, про сложности и объёмы заказов (то что не является коммерческой тайной). Если закончился запас процев и планируется новая партия (пара бы уже) хотя бы с исправлениями - про это тоже. Ну нельзя же всё из вас клещами тянуть!?
Развивающийся продукт без новостей, это - мёртвый продукт. Хотя бы раз в две недели отчитывайтесь перед общественностью. Нет новостей, напишите про планы, но должно быть от вас какое-то инфо, отппуска закончились, пора уже мобилизоваться.

VaalKIA wrote:

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

много мелких тоже неплохо.

Ну нельзя же всё из вас клещами тянуть!?

А так тоже можно!? :)

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

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

Одним из основных показателей работоспособности последней версии компилятора LLVM во время его тестирования выступал Wetstone. Совместно с продолжающейся разработкой и тестированием компилятора LLVM также была произведена оптимизация некоторых функций математической библиотеки. В целом это позволило улучшить показатель Wetstone на 15% относительно результата упомянутого в статье, то есть до 84 MWIPS.

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

В целом, в связи с демонстрацией компилятором LLVM на данный момент устойчиво хороших и, главное, стабильных результатов, считаем целесообразным в ближайшее время перевести компилятор в β-версию и полностью отказаться от компилятора LCC для процессора Multiclet R1. Компилятор LCC будет поддерживаться только для процессора Multiclet P1.

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

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

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

Если не видели данной новости, то вот тут можно прочитать: https://yandex.ru/search/?text=логарифмический%20сопроцессор&clid=2207714&lr=10740
Первая ссылка -- там pdf файл с более подробным описанием.

Возможно, это подойдёт для мультиклета.