Если вы хотите чтобы кэш процессора "вымывался", то стоит вызывать что-то другое, не работающее с I/O.

На этих бенчмарках вызов printf() не удалялся

Таким образом Вы опять измеряете производительность операционной системы, а не своего алгоритма.

Хочу видеть результат без printf(). :-)

c 32 килобайтами средний размер процедуры будет только 21 байт, что уже несколько стесняет, даже если мы будем расширять большие процедуры за счет тех что меньше среднего размера.

Не понял, откуда такие цифры ? 32768 / 128 = 256 сервисных функций по 128 байт. Помоему это овердохрена. Сервисные функции длиной более 128 байт поделить на четыре отдельных опкода, но таких функций быть вообще-то не должно!

trampoline_table:
    jmp srv_Break
    .byte 0x90, 0x90, 0x90
    jmp srv_Nop
    .byte 0x90, 0x90, 0x90
    jmp srv_Halt
    .byte 0x90, 0x90, 0x90
    <....>
    jmp sr_Pick
    .byte 0x90, 0x90, 0x90

на старте ее адрес загружается в %rdi

dispatch теперь стал таким:

.macro DISPATCH
    lea    (%rdi, opcode64, 8), opcode64
    jmp    *opcode64
.endm

Вот результаты бенчмарка с размером задачи 100000 (как в оригинале). Интересующий нас столбец - asmtrm

В результате мы экономим пространство за счет времени исполнения (в asmexp все функции выровнены на 0x80, а в asmtrm - на 0x10). На моей машине L1 кэш инструкций составляет 704 килобайта, поэтому имеет смысл использовать трамплины для того чтобы иметь несколько наборов кода - пока мы попадаем в кэш.

Можно попробовать оценить, сколько можно иметь кодовых наборов. За образец можно взять виртуальную машину WASM, у нее однобайтовый опкод, на текущий момент занято где-то 200 команд, но можно брать по максимуму - 255.

Даже если кешировать три элемента стека (а не два, как сейчас) и мы хотим варианты наборов процедур для всех перестановок, нам нужно 6 вариантов. Тогда мы попадаем в этот кэш при среднем размере процедуры в 471 байт (что довольно много).

На практике не все опкоды из этих 255 работают со стеком, так что можно чувствовать себя еще свободнее. Но на машине @checkpoint c 32 килобайтами средний размер процедуры будет только 21 байт, что уже несколько стесняет, даже если мы будем расширять большие процедуры за счет тех что меньше среднего размера.

На этих бенчмарках вызов printf() не удалялся

Судя по ассемблерному коду который привел пользователь @e2k_sid в своей ответной статье, явовскому JIT компилятору (и JVM) до оптимума еще как до Китая пешим драпом. Честно говоря я был неприятно удивлен.

atakua@localhost:~$ cat no-stack-frame.c 

register long long a asm("%rbp");
int main() {
    return (int)a;
};

atakua@localhost:~$ gcc no-stack-frame.c 
no-stack-frame.c: In function ‘main’:
no-stack-frame.c:4:5: error: frame pointer required, but reserved
    4 | int main() {
      |     ^~~~
no-stack-frame.c:1:20: note: for ‘a’
    1 | register long long a asm("%rbp");
      |                    ^

atakua@localhost:~$ gcc -fomit-frame-pointer no-stack-frame.c 
# OK

У меня есть один комментарий по поводу следующего утверждения из статьи:

Рекомендация компилятору привязать одну глобальную переменную к регистру - это только рекомендация, и компилятор может ее проигнорировать.

В случае с GCC и расширения asm("reg-name") это не так. Компилятор действительно перестаёт использовать указанный регистр для своих целей. Фактически, за модификации в ABI после этого отвечает сам программист.
Можно даже поставить компилятор в тупик и заставить его отказаться от компиляции кода, в котором важные для ABI регистры были у него "забраны". Например, если прибить RBP на x86-64, то компиляция с --coverage становится невозможной. GCC хочет использовать RBP для stack frame, который необходим для инструментации покрытия кода.

Мне почему-то кажется, что лишний jump испортит картину.

public class Main {
    public static void main(String[] args) {
	int res = 0;
        for (int i = 2; i < 300000; i++) {
            boolean isPrime = true;
            for (int divisor = 2; divisor < i; divisor++) {
                if (i % divisor == 0) {
                    isPrime = false;
                    break;
                }
            }
            if (isPrime)
                res = res + i; //System.out.printf("[%d]\n", i);
        }
    }
}

В asmexp убран вызов библиотечной функции, сам опкод для печати остается, но он ничего не делает. Это равносильно суммированию в Java коде.

В конце концов, интерпретатор является предельным частным случаем компилятора, в котором вся работа переложена на библиотеку времени выполнения.

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

if (isPrime) System.out.printf("[%d]\n", i);

убирая соответствующие байткоды, а в отключенном asmexp убирается только сам вызов функции, судя по патчу, накладные расходы остаются

rz@butterfly:~/rigidus/interpreters-comparison % time ./asmexp > /dev/null
24.809u 0.000s 0:24.81 99.9%	848+2896k 0+8io 0pf+0w

rz@butterfly:~/rigidus/interpreters-comparison % time ./asmopt > /dev/null
36.961u 0.015s 0:36.97 100.0%	843+2896k 0+8io 0pf+0w

Это выборка из нескольких прогонов, с минимальным значением.

Моя машина - ноут Lenovo Ideapad Gaming:

Update:

На моей машне Java без printf на задаче в 300000 чисел дает такой результат:

rz@butterfly:~/interpreters-comparison % time java -Xint Main
31.386u 0.055s 0:31.43 100.0%	5+167k 0+4io 0pf+0w

rz@butterfly:~/interpreters-comparison % time java Main
5.340u 0.031s 0:05.36 100.1%	17+171k 0+4io 0pf+0w

JIT вариант ожидаемо дает результат близкий к native, а вот JVM существенно проигрывает asmexp (22s) и близок к asmopt (32s). Хочу увидеть эти же тесты на других машинах. Есть основания полагать, что вариант предложенный автором + моя идея с вычислимым адресом, несколько более эффективен. Но результат сильно зависит от конкретной модели микропроцессора.

В моём репозитории для способов native, asmopt и asmexp отключен вызов printf, а задача увеличена до 300000 числе. Это делает эксперимент более точным.

Кстати, 6.7 s на openjdk - это меньше, чем 7.7 s на asmopt.

$ time ./asmopt > /dev/null
real 0m7,739s

$ time ./asmexp > /dev/null
real 0m8,787s

$ time ./native > /dev/null
real 0m1,253s

«А мне тут вообще всё не нравится».

Это про меня. :)

$ time java Main > /dev/null

real 0m6,139s

$ time java -Xint Main > /dev/null

real 0m22,493s

Эти результаты, кстати, очень хорошо перекликаются с тем, что выдают варианты native и asmexp. Попробуйте запустить тест native, asmopt и asmexp из моего репозитория (ветка noprintf), интересно какие будут абсолютные цифры на Вашей машине. Сравним их JVM и JIT.

преобразование одной в другую сожрет существенную часть производительности

Только jit будет нести расходы на несоответстие vm и архитектуры в compile-time, а интерпретатор - в run-time.

Дайте мне свой код, я прогоню его на моей машине.

У меня вот такие результаты.