Здравствуйте, ·, Вы писали:

·>Справедливости ради стоит заметить, что в шарпе пришлось унизительно расставлять unsafe да ещё какие-то прагмы для инлайнинга. А в src/Disruptor/Util/InternalUtil.cs вообще какие-то магические коды, почти ассемблерные вставки; правда лень разбираться для чего это.

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

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


·>Такое ощущение, что писать на шарпе high performance можно только из любви к искусству...

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

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

Здравствуйте, Sinclair, Вы писали:

S>Да, там кокие-то чудеса. На первый взгляд выглядит совершенно как обычный ансейф-код обращения к массиву, минуя проверки диапазона.
S>Зачем они это навертели, вместо простых и понятных манипуляций с указателями в unsafe — х.з.

Чтобы не делать пин при преобразовании к указателю в блоке fixed().
Да, этот пин условно бесплатен для клиентского GC, но не всегда бесплатен для серверного, выполняющего GC в фоне постоянно.


S>И вообще, там много непонятного кода.

Это надо смотреть на сценарии использования.
В аналогичных случаях мне удавалось обходиться без unsafe-блоков кода через библиотечные Unsafe.As<>/Unsafe.Add<>, т.е. через обычные ref int/long/etc ссылки.
Код выглядит как достаточно тупой порт на C# на сегодня.


S>Такое впечатление, что вся эта ансейф-магия в дотнетном дисрупторе нужна для покрытия тех случаев, который джавовский дисруптор не умеет в принципе: когда евенты в очереди лежат не по ссылке, а по значению.

Кстате, раз уж ты дал ссылку на дотнетную реализацию, то там есть, в том числе, реализация поверх unamanaged-буфера. ))
Но опять всё сделано максимально по-нубски, бо можно было сразу хранить типизированный указатель, а не пользовать SafeHandle, т.к. это опять очень внутренний код, т.е. можно было сделать надёжную финализацию в объектах более высокого уровня, наследуя их от CriticalFinalizerObject, а не получать штраф на лишнюю косвенность. Разрабы этого говнокода явно не понимают, что в отсутствии необходимости вызовов DangerousAddRef/DangerousRelease у объекта SafeHanlde тот не нужен вовсе. ))

И заодно куча ручной разметки:

public abstract class UnmanagedRingBuffer : ICursored
{
    // padding: DefaultPadding

    [FieldOffset(DefaultPadding)]
    protected IntPtr _entries;

    [FieldOffset(DefaultPadding + 8)]
    protected long _indexMask;

    [FieldOffset(DefaultPadding + 16)]
    protected int _eventSize;

    [FieldOffset(DefaultPadding + 20)]
    protected int _bufferSize;

    [FieldOffset(DefaultPadding + 24)]

Что тоже нубство, бо можно было просто описать структуру Padding и пометить класс через LayoutKind.Sequential.

DefaultPadding у них равен 64-8=56, что тоже странно, бо на современных серверных процах бывает размер линейки кеша 128 байт, т.е. эта константа из прошлого.

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

Забейте вы уже на этот Dusruptor, это действительно плохой пример, аминь.

Здравствуйте, Sinclair, Вы писали:

S>Примерно как пытаться делать HTTP-сервер на честных аппаратных потоках, создаваемых на каждый сокет.

А, да.
Про кооперативную многозадачность я упомянул по той причине, что потоки эти не аппаратные, конечно, а логические уровня ОС.
Т.е., прикладные потоки всегда логические, ес-но, а вопросом выделения потокам/задачам машинного времени занимается некая внешняя система.

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

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

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

В кавычках определение кривое, понятно, этому еще предстоит изобрести более короткий термин.

Здравствуйте, vdimas, Вы писали:

V>·>Справедливости ради стоит заметить, что в шарпе пришлось унизительно расставлять unsafe да ещё какие-то прагмы для инлайнинга. А в src/Disruptor/Util/InternalUtil.cs вообще какие-то магические коды, почти ассемблерные вставки; правда лень разбираться для чего это.
V>Это как раз то, что ты просил показать — чтение из нетипизированной памяти массива байт.
Я это просил показать в lmax disruptor. Ты так и не смог.

V>Ты чудесно повторил подвиг Синклера — сам себе ответил на свои же донельзя яростные возражения.
Ты подменяешь контекст.

V>Просто в Джаве эти ср-ва идут изкаробки, бгг...
Какие? Давай точную строчку кода. Или господин соврамши?

V>И да, в дотнете эти ср-ва тоже идут изкаробки, просто этот код написан разработчиками Disruptor, кои в моих глазах недосамоучки, что и показывает твоя ссылка.
Ты опять соврал. Этот код не написан разработчиками Disruptor. Разработчики — Martin Thompson и Mike Barker, может ещё пара.

V>·>Такое ощущение, что писать на шарпе high performance можно только из любви к искусству...
V>Как и на Джаве.
Факты говорят о другом.

V>Но это ты сильно себе польстил, конечно, насчёт любви к искусству... ))
V>На этих языках окучивают несвойственные этим языкам ниши из-за пресловутой "планки входа", более никаких причин происходящего нет.
Фактические причины я уже тут описывал — компромисс между безопасностью и перформансом.

V>я последние лет 12 как раз этим занимаюсь — выжиманием максимума из дотнета,
Приношу свои соболезнования. Но тебе ещё повезло, что не из вижуалбасика.

Здравствуйте, ·, Вы писали:

V>>·>Справедливости ради стоит заметить, что в шарпе пришлось унизительно расставлять unsafe да ещё какие-то прагмы для инлайнинга. А в src/Disruptor/Util/InternalUtil.cs вообще какие-то магические коды, почти ассемблерные вставки; правда лень разбираться для чего это.
V>>Это как раз то, что ты просил показать — чтение из нетипизированной памяти массива байт.
·>Я это просил показать в lmax disruptor. Ты так и не смог.

Самому поискать по ByteBuffer не судьба?


V>>Ты чудесно повторил подвиг Синклера — сам себе ответил на свои же донельзя яростные возражения.
·>Ты подменяешь контекст.

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

Невменяемый шлак, кароч.
Это просто несерьёзно, извините.


V>>И да, в дотнете эти ср-ва тоже идут изкаробки, просто этот код написан разработчиками Disruptor, кои в моих глазах недосамоучки, что и показывает твоя ссылка.
·>Ты опять соврал. Этот код не написан разработчиками Disruptor. Разработчики — Martin Thompson и Mike Barker, может ещё пара.

Многовато людей для такой задачи.
Хотя, если прикола ради сугубо для опенсорса...


V>>·>Такое ощущение, что писать на шарпе high performance можно только из любви к искусству...
V>>Как и на Джаве.
·>Факты говорят о другом.

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


V>>На этих языках окучивают несвойственные этим языкам ниши из-за пресловутой "планки входа", более никаких причин происходящего нет.
·>Фактические причины я уже тут описывал — компромисс между безопасностью и перформансом.

Это оно и есть.
Потому что безопасность требуется вовсе не на уровне реализации Disruptor — это небольшая по объёму кода библиотека, в которой можно обеспечить безопасность относительно задешево...
Безопасность требуется в прикладных колбэках, т.е. в клиентском коде.

Ведь Disruptor вещь не сама в себе, это мидлварь. ))
Т.е. это всегда позиционирование на некий рынок разрабов, увы и ах.
Поэтому, бесполезно пытаться замазать суть происходящего.


V>>я последние лет 12 как раз этим занимаюсь — выжиманием максимума из дотнета,
·>Приношу свои соболезнования. Но тебе ещё повезло, что не из вижуалбасика.

Дык, причины те же, что и в джаве — существование этого рынка.
И этот рынок стал нехило расти с появлением .Net Core (сейчас опять просто .Net называется).

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

И результат тоже несравним, конечно — в Джаве многое физически невозможно...
Ну или начать оперировать сугубо бестиповыми массивами байт вместо типизированных объектов. ))
Или как в Disruptor — разносить поля объектов по разным массивам (см MultipleProducer), получая несколько круговых буферов вместо одного, из-за отсутствия value-type в языке.

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

Здравствуйте, vdimas, Вы писали:

V>·>Я это просил показать в lmax disruptor. Ты так и не смог.
V>Самому поискать по ByteBuffer не судьба?
Поищи. Доложи о результатах. И извинись за враньё. Дальше разговор продолжать не вижу смысла. Ты полностью игнорируешь реальность.

Здравствуйте, vdimas, Вы писали:

V>Ты смотрел описание механизма разветвления и схлопывания потоков при выполнении задач в этом гипотетическом Эльбрус-Б?
Где бы я его посмотрел?
V>Попахивает той самой "кооперативной многозадачностью на аппаратном уровне", когда ресурсы автоматом отдаются другим потокам, пока нынешний ожидает.
Поскольку никаких материалов в открытом доступе нет, попахивает распилом обыкновенным, классическим.
А то, что вы описываете, и называется "hyperthreading".

Здравствуйте, Sinclair, Вы писали:

S>А то, что вы описываете, и называется "hyperthreading".

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

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

В гипертрединге Интел поток всегда работает, он не может не работать. ))
Даже если просто сидит в режиме ожидания — нихера он не сидит, на деле, а крутится в цикле, как это делали любые допотопные одноядерные процы, только теперь многоядерные и многопоточные.
Сравни с гетерогенными ядрами Cell или гетерогенными ARM или видеокартейками, где активностью аппаратных потоков исполнения (ядер) можно именно управлять.

В общем, некие черты интеловского гипертрединга во всём этом есть, но на деле там разница шириной примерно в пропасть. ))

Здравствуйте, ·, Вы писали:

V>>·>Я это просил показать в lmax disruptor. Ты так и не смог.
V>>Самому поискать по ByteBuffer не судьба?
·>Поищи. Доложи о результатах. И извинись за враньё. Дальше разговор продолжать не вижу смысла. Ты полностью игнорируешь реальность.

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

А реальность мы обсуждали именно с тобой, что в отсутствии value type в джаве есть всего 2 способа борьбы с этим в случае необходимости хранения массивов данных — или массив представлен как нетипизированный набор байт и вся типизация происходит "в уме" по смещениям, или поля удерживаемого в голове якобы объекта хранятся по разным массивам, т.н. "вертикальное хранение данных". За давностью лет прошлого обсуждения я мог запамятовать, какой способ использован в Disruptor, но помнил, что видел ByteBuffer у них. В самой реализации унутре использован второй подход, ОК, т.е. кол-во круговых очередей более одной для multiple producer. Вот твоя реальность.

Не одно убожество, так второе, пусть даже в профиль (натурально в профиль), и?

И да, ты тоже нагнал там лажи, а я сходу не проверил — нельзя подставить произвольную свою очередь в систему.
А которая есть — она сделана на основе нетипизированного массива object[] в базовом классе, что простые long приходится хранить в обертке.
Впрочем, именно в примерах это хорошо показывается.

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

Здравствуйте, vdimas, Вы писали:

V>Потоков два, а не десятки-сотни.
V>Потоки не могут аппаратно приостанавливаться и продолжаться по некоему условию/флагу, т.е. не могут синхронизироваться.
V>Потоки имеют независимые ОоО, чего не требуется при распараллеливании одного цикла по потокам, например (см реализацию в видеокартейках, где "ядром" называют распараллеливаемый код).
V>И т.д. до бесконечности.
Ну зато эти потоки могут активироваться бесплатно, т.к. весь необходимый контекст лежит прямо в регистрах. Как предполагается переключать сотни потоков? Иметь регистровый банк в несколько тысяч регистров, или восстанавливать все регистры из памяти? Ну, тогда переключение будет на порядок дороже гипертрединга.

V>В общем, ожидаемая схема
Непонятно, откуда взята "ожидаемая схема". В публично доступных источниках я видел только финансовый аспект этой схемы — и он-то как раз сомнений особо не вызывает.

Здравствуйте, vdimas, Вы писали:

V>·>Поищи. Доложи о результатах. И извинись за враньё. Дальше разговор продолжать не вижу смысла. Ты полностью игнорируешь реальность.
V>Посмотрел,
И где извинения?

V> показано практически во всех примерах использования, поставляемых с приблудой.
Где? Ссылку в студию.

Здравствуйте, ·, Вы писали:

V>>·>Поищи. Доложи о результатах. И извинись за враньё. Дальше разговор продолжать не вижу смысла. Ты полностью игнорируешь реальность.
V>>Посмотрел,
·>И где извинения?

А ты уже извинился за свои ошибки?


V>> показано практически во всех примерах использования, поставляемых с приблудой.
·>Где? Ссылку в студию.

Ссылку на Disruptor ты дал, см примеры там же.

Здравствуйте, Sinclair, Вы писали:

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

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


S>Как предполагается переключать сотни потоков?

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

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


S>Иметь регистровый банк в несколько тысяч регистров

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


S>или восстанавливать все регистры из памяти?

В случае переполнения ресурсов — а как же? ))


S>Ну, тогда переключение будет на порядок дороже гипертрединга.

Ну открой в страницах браузера многие десятки динамических 3D-визуализаций даже на самой современной видеокартейке — и начнутся запинания. ))
Никакие ресурсы не бесконечны, конечно.

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


V>>В общем, ожидаемая схема
S>Непонятно, откуда взята "ожидаемая схема". В публично доступных источниках я видел только финансовый аспект этой схемы — и он-то как раз сомнений особо не вызывает.

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

Они не изобретают чего-то нового — попытки реализации в железе (но совсем на другом уровне в прошлые десятилетия) уже были.

Они просто отбросили пресловутый "груз легаси" и пытаются на актуальных кол-вах транзисторов на кристалле воплотить с 0-ля сочетание нескольких уже обкатанных схем.

С Эльбрусом E2k та же история — абсолютно ничего нового не было изобретено, была реализация с 0-ля уже хорошо показавших себя подходов в сигнальных процах, просто довели эти подходы "до абсурда", до практически-достижимого максимума за счёт экстенсивного наращивания кол-ва АЛУ, наиболее мощного механизма спекулятивного исполнения на сегодня и механизма явной предзагрузки памяти (тоже в топах на сегодня, потягаться могут только Cell-процы в видеоприставках). Даже их способ ветвления в одной команде, когда исполняются две ветки, а в память записывается результат исполнения лишь одной по результату вычисления логического выражения — это тоже уже было до них в сигнальных процах. Просто они сделали это чуть качественней, бо сигнальные процы не могли позволить себе быть дорогими, а ЦП может!

Здравствуйте, vdimas, Вы писали:

V>>>·>Поищи. Доложи о результатах. И извинись за враньё. Дальше разговор продолжать не вижу смысла. Ты полностью игнорируешь реальность.
V>>>Посмотрел,
V>·>И где извинения?
V>А ты уже извинился за свои ошибки?
Всё что не соответсвует твоим фантазиям ты считаешь ошибкой. За твои фантазии извиняться должен ты.

V>>> показано практически во всех примерах использования, поставляемых с приблудой.
V>·>Где? Ссылку в студию.
V>Ссылку на Disruptor ты дал, см примеры там же.
Если у тебя есть что показать, то показывай. Если собираешься мне отвечать без ссылок и конкретных кусков кода, то не трудись, я просто это проигнорирую.

Здравствуйте, ·, Вы писали:

V>>>> показано практически во всех примерах использования, поставляемых с приблудой.
V>>·>Где? Ссылку в студию.
V>>Ссылку на Disruptor ты дал, см примеры там же.
·>Если у тебя есть что показать, то показывай. Если собираешься мне отвечать без ссылок и конкретных кусков кода, то не трудись, я просто это проигнорирую.

Отвечать мне надо тезисно или никак.

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

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

Здравствуйте, vdimas, Вы писали:

S>>Как предполагается переключать сотни потоков?
V>Дык, а как сейчас останавливают и запускают логические потоки? — программно.
V>Но я не вижу проблем перенести в железо львиную долю этой логики.

Уже было в 80286. Почему-то к тем "таскам" возвращаться не хотят.

S>>Иметь регистровый банк в несколько тысяч регистров
V>А он де-факто уже есть даже в мейнстримовых архитектурах на уровне кеша 0-го уровня — в этом банке хранятся как "реальные" регистры, куда ОоО совершает отображение-переименование,

Там редко когда аппаратных регистров больше в 10 раз чем архитектурных.

V> так и таблицы разметки виртуальной памяти.

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

V> Просто требуется этот подход тоже довести до абсурда банально через экстенсивное увеличение размера кеша 0-го уровня и снабдив его огромной ассоциативной схемой отображения,

Как ты думаешь, почему L1 кэши памяти такие маленькие?

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

"Попытки", угу.

V>С Эльбрусом E2k та же история — абсолютно ничего нового не было изобретено, была реализация с 0-ля уже хорошо показавших себя подходов в сигнальных процах, просто довели эти подходы "до абсурда",

Кавычки явно лишние.

Здравствуйте, Sinclair, Вы писали:

S>3. Действительно ли есть способ в 30-200 раз эффективнее использовать транзисторы по сравнению с современными CISC и RISC архитектурами?

А что, Pentium 4 Prescott на частоте 3.8 GHz в 30-200 раз медленнее современных интеловских процессоров?

Здравствуйте, Pzz, Вы писали:

Pzz>А что, Pentium 4 Prescott на частоте 3.8 GHz в 30-200 раз медленнее современных интеловских процессоров?
Нет, раз в 10. А какое отношение этот вопрос имеет к топику?

Здравствуйте, Sinclair, Вы писали:

Pzz>>А что, Pentium 4 Prescott на частоте 3.8 GHz в 30-200 раз медленнее современных интеловских процессоров?
S>Нет, раз в 10. А какое отношение этот вопрос имеет к топику?

Ну потому, что P4 — пример микросхемы, сделанной по технологии 90 nm.

Здравствуйте, netch80, Вы писали:

S>>>Как предполагается переключать сотни потоков?
V>>Дык, а как сейчас останавливают и запускают логические потоки? — программно.
V>>Но я не вижу проблем перенести в железо львиную долю этой логики.
N>Уже было в 80286. Почему-то к тем "таскам" возвращаться не хотят.

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


S>>>Иметь регистровый банк в несколько тысяч регистров
V>>А он де-факто уже есть даже в мейнстримовых архитектурах на уровне кеша 0-го уровня — в этом банке хранятся как "реальные" регистры, куда ОоО совершает отображение-переименование,
N>Там редко когда аппаратных регистров больше в 10 раз чем архитектурных.

А и не будет больше это отношение.
И там не в 10 раз, а поменьше, вроде.
Просто будет больше самих наборов регистров, т.к. будет больше аппаратных потоков.


V>> так и таблицы разметки виртуальной памяти.
N>Кэш совсем не резиновый, а тегирование через PCID эффективно работает максимум на 1 процесс назад. По сути от того идентификатора остаётся только упрощение для ОС.

Это схема показала себя де-факто плохой.
Переключение контекстов дорого в основном из-за "разогрева" таблиц виртуальной памяти.
НизачОт современному мейнстриму, кароч. ))

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


V>> Просто требуется этот подход тоже довести до абсурда банально через экстенсивное увеличение размера кеша 0-го уровня и снабдив его огромной ассоциативной схемой отображения,
N>Как ты думаешь, почему L1 кэши памяти такие маленькие?

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

А для L0 эта схема очень простая — каждый поток имеет свой участок в кеше L0, т.е. "отображение" с большой вероятностью будет заключаться в старших битах адреса обращения к этому кешу, где значения этих бит константны для каждого потока. Динамическое отображение потребуется только для OoO и спекулятивного исполнения. И то... Возможно будет "дешевле" просто взять статической памяти с запасом, чем наверчивать динамическое аппаратное распределение этой памяти. ))


V>>И я уже видел не раз эти схемы ранее (не связанные конкретно с Эльбрус-Б) и почитывал обсуждения способов решения проблематики.
V>>Они не изобретают чего-то нового — попытки реализации в железе (но совсем на другом уровне в прошлые десятилетия) уже были.
N>"Попытки", угу.

Ну так и векторные процессоры были уже в 70-е, но выстрелили только в конце 90-х в первых 3D-видюхах, когда кол-во АЛУ взяли на порядок больше.
Т.е., количество иногда переходит совсем в новое качество. ))


V>>С Эльбрусом E2k та же история — абсолютно ничего нового не было изобретено, была реализация с 0-ля уже хорошо показавших себя подходов в сигнальных процах, просто довели эти подходы "до абсурда",
N>Кавычки явно лишние.

))

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