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

Для справки - виртуальные машины пишут на нативном коде (при написании которых можно использовать ВСЕ ЧТО УГОДНО, имеющееся у нативных библиотек).

Для справки - есть такая библиотека OpenMP, которая учитывает "попадания и промахи кешей (не дисковых, разумеется)" - при МНОГОПОТОЧНОЙ работе программы (на общей памяти, в данном случае, а вот MPI этот момент не учитывает).

Для справки - OpenMP очень широко применяется разработчиками Oracle.

Для справки - Oracle является владельцем и основным разработчиком виртуальной машины Java.

Для справки - СУБД Oracle является одной из самых быстродействующей БД в мире (в телекоме стоят сплошь и рядом СУБД Oracle).

Для справки - в 1995г. внутри корпорации Oracle была создана группа производительности систем (SPG), объединившая 85 аналитиков компании.

Для справки - группа SPG была создана в том числе и потому, что изменения размеров буферов в оперативной памяти для отдельных структур экземпляра СУБД Oracle - могла не давать вам никакого выигрыша в производительности.

Для справки - SPG в качестве конечного фактора производительности прежде всего принимала во внимание время отклика приложения.

Для справки - после того как Sun пошел ко дну и Oracle занялась виртуальной машиной Java - ею была выпущена коммерческая версия этой виртуальной машины, ключевой особенностью которой является время отклика приложения.

Для справки - и ДО ЭТОГО ВЫПУСКА в мире существовало и существует десятки тысяч высоконагруженных серверных JEE-приложений, включая и использование в торгах на он-лайн биржах, где время отклика системы, как вы знаете - необычайно важно.

Для справки - большинство бэкендов онлайн-казино - написано на серверной джаве.

Для справки - во фреймворке JSF серверной джавы, использующимся при создании сайтов, порталов и т.п. - за один клик пользователя по формочке сайта - происходит вызов нескольких тысяч строк кода, и это только кода, разрабатываемого разработчиком (помимо вызовов внутри самого фреймворка) - это код И обеспечивающий безопасность (например страницы администратора не должен видеть обычный пользователь), И другие механизмы бизнес-логики приложения (в соответствии, для простоты понимания, с ТЗ). Так вот - я без труда отслеживал и манипулировал этими тысячами строк кода при каждом вызове. Вы можете с такой легкостью манипулировать бизнес-логикой в программе, написанной на Фортране или на С/С++ - ? В том то и дело, что процедурный подход устанавливает верхнюю границу того кода, который вы можете оперативно поддерживать - всего в пару тысяч строк, а ООП позволяет с легкостью манипулировать десятками тысяч и сотнями тысяч строк кода. Поэтому не приводите только один показатель попадания в кэш - этот показатель критически важен только для определенных приложений (напр. 3D-шутеры), да и то профессионалами там зачастую используются ассемблерные вставки, поэтому говорить о "чисто" супер применимости "вашего" ЯП - не верно.