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

_>Java, C# и т.п. никогда не смогут догнать C++, ни при каком оптимизаторе и формате исполняемого файла (есть же компиляторы C# в машинные кода) совсем по другими причинам. И я описывал их в предыдущем сообщение. Ну вот смотри, разберу одну из этих причин на пальцах для примера:

_>Ты же наверняка знаешь, что во всех этих языках все методы являются виртуальными функциями (говоря языком C++).

Вы тут ну очень много написали, но в следующих ста сообщениях я не увидел возражений, поэтому комментирую. Как это получилось, что ты не в курсе, что в Java и C# просто перевёрнуто умолчание объявления метода виртуальным? Там, где в C++ говорится virtual, в Java молчат, а где в C++ не говорится virtual, в Java говорится final (а в C# — sealed), последствия для виртуальности те же. Это чуть упрощая (есть проблемы одноимённых методов и т.п.), но для данных целей сгодится. И видя final — компилятор (пусть JIT) точно так же имеет право рисовать обращение напрямую к нужному методу или инлайнить его.
Вот если кто не пишет этот final на критически важных местах — он ССЗБ.

_> Что это значит с точки зрения оптимизации? Что компилятор (пусть он даже очень сильный и у него есть куча времени) физически не сможет сделать инлайнинг, потому что просто не знает какой конкретно код в реальности будет вызываться — это определяется только в рантайме. В то время как в C++ не только часто употребимы не виртуальные функции, но и для виртуальных компилятор гарантированно осуществляет инлайнинг, если они вызваны от обычной переменной (а не от указателя или ссылки).

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