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

k> Ну, а Китай без возможности влиять на развитие RISC-V будет пилить свой форк RISC-X. Первое время конечно они будут на 99.9% похожи, но потенциально всё же не будет одной точки приложения усилий.

RISC-X это чисто юридический форк. На деле будут обеспечивать полную совместимость. Никому обособленный форк не нужен.

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

a> И ещё, у меня впечатление, что ты не знаешь, что технология — это не только нанометры.

Ты говоришь: "на технологии посмотри". На что из "технологий" я могу посмотреть кроме нанометров???

a> Я подозреваю, что для процессора Эппл М4 производилось топологическое проектирование со всеми его оптимизациями,
a> а для Эльбруса просто отдали на фабрику verilog.

МЦСТ говорили, что разрабатывают проц под фабрику. Поэтому они не могут в один момент сменить забанившую их TSMC на, условно, китайскую SMIC.

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

k> Целых 350 материнок собрали на процессорах из 2021 года, а серверы пока только оформляют как отечественные.
k> Звучит как массовое производство, закрывающее потребности отечественного бизнеса.

Курочка по зернышку клюет.

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

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

k> R>Baikal-S, 2021.

k> Уже 4 года процессору, а новые модели на ARM им производить нельзя. Выглядит перспективно, нужно больше в ARM вкладываться, а не в убогий VLIW, который всё ещё можно развивать.

В АРМ уже не нужно, как и в игры со VLIW.

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

k> Может быть, когда-нибудь, но это не точно.

Других вариантов нет. Так что, риску-пять — быть!

k> Хорошо, что про RISC-V ты не переживаешь по поводу правдивости и объективности графиков, веришь на слово.

Ну, проверить-то я не могу Я тебе предлагал проверить, но и ты почему-то не можешь...

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

Да. Это я твой тезис опроверг.

k> По Эльбрусам вот бенчмарки есть, но тебе сразу позитивные бенчи не такие и всё там не так.

А ты считаешь нормальным делать выводы о процессоре по бенчам СХД, когда есть чисто процессорные бенчи? Если да, то давай на этом закончим эту глупую словесную эквилибристику.

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

a>> И ещё, у меня впечатление, что ты не знаешь, что технология — это не только нанометры.

R>Ты говоришь: "на технологии посмотри". На что из "технологий" я могу посмотреть кроме нанометров???

Ну, это твои проблемы, что ты не можешь посмотреть.
Если не можешь посмотреть, значит ты не можешь судить насколько эта архитектура лучше/хуже Интеловской или АРМ-овской.
В такой ситуации лучше бы не вякать.

a>> Я подозреваю, что для процессора Эппл М4 производилось топологическое проектирование со всеми его оптимизациями,
a>> а для Эльбруса просто отдали на фабрику verilog.

R>МЦСТ говорили, что разрабатывают проц под фабрику. Поэтому они не могут в один момент сменить забанившую их TSMC на, условно, китайскую SMIC.

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

Здравствуйте, ·, Вы писали:
V>>В Disruptor операции просто над буфером байт, т.е. вся типизация происходит "в уме" — просто по смещениям читают и пишут данные как в ассемблере, когда пишут и читают в сырую нетипизированную память.
·>Надеюсь тебя не затруднит привести конкретную строчку где есть "операции просто над буфером байт"? Вот тут исходники, если ты их ещё не видел: https://github.com/LMAX-Exchange/disruptor/tree/master/src/main/java
Да не будет он читать. И раньше-то не читал. Иначе бы сразу поймал меня на "там нет следов ручной разметки памяти", потому что они там есть

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

S>Да не будет он читать. И раньше-то не читал. Иначе бы сразу поймал меня на "там нет следов ручной разметки памяти", потому что они там есть

Эта тема уже давно переросла в мерянье пиписьками.

А касательно именно false-sharing, то я за более чем 15 лет опыта всего несколько раз столкнулся с ним — всё ооочень сильно зависит от того, что пишешь. Абсолютное большинство здесь присутствующих мало и редко пишет мидлвари, библиотеки и фрэймворки, соответственно и false-sharing либо не видели вообще, либо видели крайне редко. И я даже сомневаюсь, что тут есть люди, которые такие проблемы умеют выявлять — профилирование такое в большинстве случаев не покажет: профиляторы не показывают такие проблема, и к тому же вмешиваются в работу софтины. Более того, в большинстве месть где возможен false-sharing теоретически, практически его эффект минимален из-за того, что в ПРАКТИЧЕСКОМ коде часто встречается использование (даже неявное) объектов синхронизациии и прочих объектов ядра (файлы, пайпы, мэйлслоты и прочее), либо используются объекты которые приводят к сисколлам, со всеми вытекающими. Насколько мне известно, большие вычисления и системный софт тут мало кто пишет...

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

Ф>А касательно именно false-sharing, то я за более чем 15 лет опыта всего несколько раз столкнулся с ним — всё ооочень сильно зависит от того, что пишешь. Абсолютное большинство здесь присутствующих мало и редко пишет мидлвари, библиотеки и фрэймворки, соответственно и false-sharing либо не видели вообще, либо видели крайне редко. И я даже сомневаюсь, что тут есть люди, которые такие проблемы умеют выявлять — профилирование такое в большинстве случаев не покажет: профиляторы не показывают такие проблема, и к тому же вмешиваются в работу софтины. Более того, в большинстве месть где возможен false-sharing теоретически, практически его эффект минимален из-за того, что в ПРАКТИЧЕСКОМ коде часто встречается использование (даже неявное) объектов синхронизациии и прочих объектов ядра (файлы, пайпы, мэйлслоты и прочее), либо используются объекты которые приводят к сисколлам, со всеми вытекающими. Насколько мне известно, большие вычисления и системный софт тут мало кто пишет...
Ну так и непонятно, в чём именно плач Ярославны. Во всём Disruptor есть ровно два места, где разработчикам пришлось пошаманить с паддингом для предотвращения false sharing.
Прикладному разработчику, который пишет свою систему с использованием Disruptor, вообще не нужно об этом думать.
То есть вся идея улучшений — это какой-то магией помочь системным разработчикам писать их 0.00005% кода. В надежде на то, что эта магия внезапно поднимет общую производительность в 30-200 раз.
Прикол-то в том, что если изначально идти по пути "давайте просто будем складывать объекты в однопоточную queue, а доступ к самой очереди и к данным лежащих в ней объектов рулить при помощи примитивов синхронизации", то никакие выравнивания не помогут. И никакие аппаратные улучшения тоже не помогут. Этот подход порочен изначально. Примерно как пытаться делать HTTP-сервер на честных аппаратных потоках, создаваемых на каждый сокет.

И отдельно хочется отметить, что унизительный код Disruptor с выравниваниями связан с особенностями именно Java — дотнет предоставляет гораздо более прямые и лаконичные возможности по управлению выравниванием, см. https://github.com/disruptor-net/Disruptor-net/blob/master/src/Disruptor/Sequence.cs

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

S>И отдельно хочется отметить, что унизительный код Disruptor с выравниваниями связан с особенностями именно Java — дотнет предоставляет гораздо более прямые и лаконичные возможности по управлению выравниванием, см. https://github.com/disruptor-net/Disruptor-net/blob/master/src/Disruptor/Sequence.cs

[StructLayout(LayoutKind.Explicit

Сдаётся мне, что придумано для взаимодействия с сишными API (для PInvoke) — я это использовал именно так. То, что таким способом можно в кэш-линии попадать, это случайность. Сам по себе атрибут StructLayout появился, когда false-sharing ещё не мог быть проблемой ни в каком виде: в серверах 2002 года обычно было 1–2 процессора.

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

S>И отдельно хочется отметить, что унизительный код Disruptor с выравниваниями связан с особенностями именно Java — дотнет предоставляет гораздо более прямые и лаконичные возможности по управлению выравниванием, см. https://github.com/disruptor-net/Disruptor-net/blob/master/src/Disruptor/Sequence.cs
Справедливости ради стоит заметить, что в шарпе пришлось унизительно расставлять unsafe да ещё какие-то прагмы для инлайнинга. А в src/Disruptor/Util/InternalUtil.cs вообще какие-то магические коды, почти ассемблерные вставки; правда лень разбираться для чего это.
Такое ощущение, что писать на шарпе high performance можно только из любви к искусству...

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

Ф>Сдаётся мне, что придумано для взаимодействия с сишными API (для PInvoke) — я это использовал именно так. То, что таким способом можно в кэш-линии попадать, это случайность. Сам по себе атрибут StructLayout появился, когда false-sharing ещё не мог быть проблемой ни в каком виде: в серверах 2002 года обычно было 1–2 процессора.
Не очень важно, для чего был придуман исходно (а был придуман для точного контроля над layout) — важно, что его достаточно. Неспроста вдимас сдулся сразу же, как его спросили о том, как должны выглядеть доработки в компилятор, которые он хотел бы сделать (да ему комитет не даёт).

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

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

Для high performance есть Native AOT, ReadyToRun . Для Interop есть StructLayout, FieldOffset.
Для подсказки компилятору есть MethodImpl

Все зависит от задач и бутылочного горлышка. Инструментов достаточно.

Здравствуйте, ·, Вы писали:
·>Справедливости ради стоит заметить, что в шарпе пришлось унизительно расставлять unsafe да ещё какие-то прагмы для инлайнинга.
Там надо ещё посмотреть, "пришлось" или "удалось". Я не видел сравнительных бенчей .Net версии супротив Java.
·>А в src/Disruptor/Util/InternalUtil.cs вообще какие-то магические коды, почти ассемблерные вставки; правда лень разбираться для чего это.
Да, там кокие-то чудеса. На первый взгляд выглядит совершенно как обычный ансейф-код обращения к массиву, минуя проверки диапазона.
Зачем они это навертели, вместо простых и понятных манипуляций с указателями в unsafe — х.з. И вообще, там много непонятного кода.

·>Такое ощущение, что писать на шарпе high performance можно только из любви к искусству...
Я с вами согласен, но акценты расставил бы по-другому: писать high performance из любви к искусству лучше таки на шарпе.
Немножко пообщался с коллегами, которые пилят JVM, и они, в целом, не вполне довольны процессом оптимизации перформанса приложений.
Потому что JIT в джаве живёт весьма своей жизнью; поэтому приходится много шаманить в поисках способа заставить его сделать что-то предсказуемое.
И это всё ещё может сломаться на следующей сборке JVM. В дотнете тоже есть такие места (интересны комменты в исходниках типа decimal), но в целом он даёт больше контроля над перформансом.

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

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

S>·>Справедливости ради стоит заметить, что в шарпе пришлось унизительно расставлять unsafe да ещё какие-то прагмы для инлайнинга.
S>Там надо ещё посмотреть, "пришлось" или "удалось". Я не видел сравнительных бенчей .Net версии супротив Java.
Я тоже. Но почему-то уверен, что значительной разницы быть не должно. Может десятки процентов. Упирается уже всё в железо по максимуму.

S> И вообще, там много непонятного кода.
В этом и мой поинт. На java всё тупо и просто. И работает быстро, и безопасно.

S>·>Такое ощущение, что писать на шарпе high performance можно только из любви к искусству...
S>Я с вами согласен, но акценты расставил бы по-другому: писать high performance из любви к искусству лучше таки на шарпе.
Но зачем? Когда уже совсем битовыжимательство идёт, то уж тогда взять натив или вообще fpga/etc и не мучить сову. А в нише компромисса безопасно+производительно — лучше подойдёт java.

S>Немножко пообщался с коллегами, которые пилят JVM, и они, в целом, не вполне довольны процессом оптимизации перформанса приложений.
А кто доволен-то?

S>Потому что JIT в джаве живёт весьма своей жизнью; поэтому приходится много шаманить в поисках способа заставить его сделать что-то предсказуемое.
А где не так с оптимизацией перформанса?

S>И это всё ещё может сломаться на следующей сборке JVM. В дотнете тоже есть такие места (интересны комменты в исходниках типа decimal), но в целом он даёт больше контроля над перформансом.
Вот только контроль не над перформансом, а над компилятором. Ведь "воткнём тут прагму force inline" — это лишь значит, что компилятор заинлайнит тут функцию. Но будет ли такой код действительно выполняться быстрее — неизвестно!

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

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

a> R>Ты говоришь: "на технологии посмотри". На что из "технологий" я могу посмотреть кроме нанометров???

a> Ну, это твои проблемы, что ты не можешь посмотреть.

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

a> Если не можешь посмотреть, значит ты не можешь судить насколько эта архитектура лучше/хуже Интеловской или АРМ-овской.

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

a> В такой ситуации лучше бы не вякать.

Кому бы не вякать, тут еще два раза посмотреть нужно.

Здравствуйте, ·, Вы писали:
·>Я тоже. Но почему-то уверен, что значительной разницы быть не должно. Может десятки процентов. Упирается уже всё в железо по максимуму.
Не совсем.

·>В этом и мой поинт. На java всё тупо и просто. И работает быстро, и безопасно.
КМК есть риск запустить то же приложение на другой JVM или на той же JVM с другими ключиками командной строки, и неожиданно получить просад производительности.
Но я не настоящий джавщик, поэтому с пеной у рта защищать этот тезис не буду.

·>Но зачем? Когда уже совсем битовыжимательство идёт, то уж тогда взять натив или вообще fpga/etc и не мучить сову. А в нише компромисса безопасно+производительно — лучше подойдёт java.
Натив плох тем, что тянет за собой натив. Вызовы из менеджед в натив небесплатны, значит либо придётся мириться с неэффективностью, либо тащить в натив всё приложение.

·>А кто доволен-то?

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

·>Вот только контроль не над перформансом, а над компилятором. Ведь "воткнём тут прагму force inline" — это лишь значит, что компилятор заинлайнит тут функцию. Но будет ли такой код действительно выполняться быстрее — неизвестно!
Не обязательно заинлайнит. И не обязательно не заинлайнит без прагмы.

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

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


A>Ну в зависимости от отношений между копаниями производитель может делиться информацией о слоях.
A>И там довольно широкий диапазон, начиная от того, что просто дают ограничения типа
A>"в таком-то слое расстояние между проводниками должно быть не менее чем..."
A>и до полной информации о толщинах, материалах и диэлектрической проницаемости.
A>Разумеется всё это под НДА.
Первое в рамках PDK выдается абсолютно всем -- DRC, второе(инфу о части слоев) ты в принципе из коэффициентов BSIM вытащишь при большом желании (но это аналоговый PDK, который не нужен никому). В зависимости от отношений у тебя могут принять голый gds или сказать, что раскладку (топологию) они сами сделают за денежку, потому что такому дятлу не доверяют.

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

S>·>Я тоже. Но почему-то уверен, что значительной разницы быть не должно. Может десятки процентов. Упирается уже всё в железо по максимуму.
S>Не совсем.
Без конкретных цифр тут бессмысленно рассуждать.

S>·>В этом и мой поинт. На java всё тупо и просто. И работает быстро, и безопасно.
S>КМК есть риск запустить то же приложение на другой JVM или на той же JVM с другими ключиками командной строки, и неожиданно получить просад производительности.
S>Но я не настоящий джавщик, поэтому с пеной у рта защищать этот тезис не буду.
Это не особенность jvm. Везде так.
Ведь в том .net disruptor всякие #if понатыканы, та же беда.

S>·>Но зачем? Когда уже совсем битовыжимательство идёт, то уж тогда взять натив или вообще fpga/etc и не мучить сову. А в нише компромисса безопасно+производительно — лучше подойдёт java.
S>Натив плох тем, что тянет за собой натив. Вызовы из менеджед в натив небесплатны, значит либо придётся мириться с неэффективностью, либо тащить в натив всё приложение.
Если приходится везде пихать unsafe, то смысл в ненативе пропадает. Теперь ещё и rust есть.

S>Там, где можно напрямую влиять на то, что будет исполняться в рантайме. Например, в дотнете.

S>Не обязательно заинлайнит. И не обязательно не заинлайнит без прагмы.

Противоречивые абзацы детектед.

S>·>Если я правильно понимаю, то в яве это не принципиально, ибо евенты всё равно почти наверняка будут расположены локально. Может и даёт какие-то проценты, но игра в усложнизм уже не стоит свеч.
S>Локальность-локальностью, но двойную косвенность это не убирает. Это примерно как с проверкой выхода за диапазон массива: переход процессором предсказывается верно, но всё рано процессор честно тратит такт на выполнение самой проверки. Так и тут — делается лишнее обращение к памяти.
Повторюсь. Без конкретных цифр тут бессмысленно рассуждать. Ведь даже если посчитать этот один такт, то это доли наносекунды.

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

S>Прикол-то в том, что если изначально идти по пути "давайте просто будем складывать объекты в однопоточную queue, а доступ к самой очереди и к данным лежащих в ней объектов рулить при помощи примитивов синхронизации", то никакие выравнивания не помогут.

Что тоже неверно, т.к. банальный прикладной мьютекс что в WinAPI (CriticalSection) что в Pthreads дергает семафор только в случае конфликтов, а в отсутствии оных всё ограничивается парой CAS: при захвате ресурса и при отпускании. И да, рекурсивный мьютекс чуть дороже, т.к. должен еще прочитать текущий thread id, а нерекурсивный пользует обычные флаги 1-0.


S>И никакие аппаратные улучшения тоже не помогут.

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


S>Этот подход порочен изначально.

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


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

Но это хорошо работает в кооперативной многозадачности. ))


S>И отдельно хочется отметить, что унизительный код Disruptor с выравниваниями связан с особенностями именно Java — дотнет предоставляет гораздо более прямые и лаконичные возможности по управлению выравниванием, см. https://github.com/disruptor-net/Disruptor-net/blob/master/src/Disruptor/Sequence.cs

О чём я и говорил, что приходится размечать вручную.

И ты привёл правильную ссылку, показывающую, что "зазор" надо делать с двух сторон в отсутствии возможности выравнивания объекта на границе адреса кеш-линии при выделении памяти под этот объект, т.е. что я и говорил — получаем перерасход памяти. Более того, этот счётчик пришлось сделать как class, т.е. выделить из GC-кучи, опять же по соображениям достоверного выравнивания. А почему так? Наверно, чтобы не возиться с выравниванием аналогичных полей при агрегировании этого счётчика в объекты более высокого уровня. Т.е., повторное использование кода у них облагается штрафом на одну косвенность. Ну тоже детсад, ес-но, потому что это ОЧЕНЬ внутренний код и можно было бы этот счётчик в отдельный класс не выделять, конечно.

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

S>Да не будет он читать. И раньше-то не читал. Иначе бы сразу поймал меня на "там нет следов ручной разметки памяти", потому что они там есть

Для этого надо смотреть версию за прошлые годы, когда обсуждали Disruptor c коллегой "точка":

private volatile long p1 = 7L, p2 = 7L, p3 = 7L, p4 = 7L, p5 = 7L, p6 = 7L, p7 = 7L,
                          value = Sequencer.INITIAL_CURSOR_VALUE,
                          q1 = 7L, q2 = 7L, q3 = 7L, q4 = 7L, q5 = 7L, q6 = 7L, q7 = 7L;

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

И стоило ли тебе спорить с общеизвестным?

====
Насчёт "сразу поймал" — я просто забил на некоторое время на этот топик за бессмысленностью.
И правильно сделал, как видишь — вы и сами прекрасно всё посмотрели, не расходуя моё время.
Ну и ОК.

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

S>Не очень важно, для чего был придуман исходно (а был придуман для точного контроля над layout) — важно, что его достаточно. Неспроста вдимас сдулся сразу же, как его спросили о том, как должны выглядеть доработки в компилятор, которые он хотел бы сделать (да ему комитет не даёт).

ЧТД, твои манеры "честного спора". ))
Хотя, все ответы были даны сразу для исключения ненужного пинг-понга — ручная разметка атрибутами не управляет выравниванием, т.е. ты не можешь расположить объект на границе кеша.

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

По поводу доработок — так они были в виде атрибутов и надстроек.
Попытки развивать плюсы были в прикладные тонкости, но все они были отвергнуты давно.

Вдогонку.
Отвергнуты по понятной причине — из-за роста популярности бесплатного Linux, т.е. вопрос совместимости компиляторов встал во главе угла, понизив приоритеты других вопросов.

Собсно, еще лет 15-20 или больше назад я сетовал, что наступило какое-то "безвременье" в IT из-за опенсорса, коль ему удалось стать важным для индустрии, что теперь вся индустрия вынуждена 20 лет ждать, пока этот опенсорс дорастёт до качества коммерческих продуктов. Еще я предрекал, что в итоге только этот опенсорс и останется в компиляторах, если скорость развития технологий как и прежде будут приносить в жертву совместимости с опенсорсом.

Там ведь банально — коль идёт вынужденное равнение на самое слабое звено, то конкуренция умирает.