Там собственно на форму приглашали сделать получше реализацию для котлин, но дело в том, что сама идея микро-бенчмакрков порочна.

Там последний билд оракловой сборки 16jdk

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

С дефолтными настройками и все еще без JMH. И я повторюсь, это все поверх того, что микро-бенчмарки не показательны вообще, если там разница не на порядок

Ещё обожаю когда в таких тестах нативные и vm языки сравнивают

Именно. Идея микро-бенчмарков в том, что перформанс программы - это линейная сумма перформанса ее кусков, но это совершенно не верно, когда речь идет об оптимизирующем компиляторе, а тем более о JIT. Перформанс определяется тем, какие куски НЕ выполняются вообще.

Ну если условия нормальные (основной код выполняется нескольких секунд), почему бы и нет

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

Ну на старт все равно уйдет до пары сотен миллисек

Ну и нормально, всё-таки надо понимать, что JIT не бесплатный

Ну они типа гоняют холостой цикл перед измерением, хотя все равно мутная методология

С ВМ все равно старт будет больше

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

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

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

Не публиковал как раз потому, что любые микро-бенчмарки бесполезны и создают совершенно ненужные обсуждения. Неплохие тесты есть тут: https://www.ojalgo.org/. Но опять, надо помнить, что это не показатель. Лично мои замеры показывают, что простые операции над большими даннами в KMath идут с той же скоростью, что в numpy (там фортран и BLAS под капотом). Но это можно сделать только для очень простых вещей типа сложить две матрицы. Потому что что-то более сложное уже завязано на оптимизацию алгоритма, а не на компилятор. И тут уже вопрос в том, насколько просто написать и поддерживать алогритм.

Если вопрос конкретно с GraalVM, то там все просто, там гораздо лучше escape analysis и он куда лучше работает с агрессивным анбоксингом. Это проявляется в программах, где есть числа в дженериках. Если это оптимизированный код, то разница будет куда меньше

Вот кстати тут какой-то бенчмарк я делал, правда не для математики: https://discuss.kotlinlang.org/t/using-lambda-and-method-reference-differ-significantly-in-performance-with-java-8-streams/19306/13

кста, вопрос про jdk. openJ9 как я понял это почти единственный jdk с апач лицензией. все остальные - это gpl, включая грааль. и тут вопрос как быть, если ты делаешь закрытое коробочное решение и не хочешь никому предоставлять исходники? только j9 что ли, или нанимать юриков, которые будут если что готовы оспаривать, что есть "бинарный дистрибутив" при наличии которого, пользователь может запросить исходники по gpl, типа если это набор докер контйенеров где-то в облаке, то уже не считается.

А кто заставляет делать jdk частью приложения?