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

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

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

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

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

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

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

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