Java и быстродействие

[StepV]

mihaild в сообщении #1500140 писал(а):

System.nanoTime возвращает время в наносекундах, прошедшее с какой-то фиксированной временной точки. Разность при двух вызовах, соответственно, равна времени в наносекундах между этими вызовами. Как это связано с JVM - непонятно.

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

[B@R5uk]

StepV в сообщении #1500147 писал(а):

программа не чувствует, что выполняется в некоей виртуальной среде, ей имитируется полностью весь внешний интерфейс

Однако, это не значит, что после JIT-компиляции программа выполняется виртуальным процессором в виртуальном мире. Это уже вполне конкретный программный код, который дёргает реальные регистры процессора. Да, он может быть значительно менее оптимальным, чем код, который генерирует какой-нибудь современный gcc, но это всё равно процессорный код. А время выполнения вообще всегда реально, что у интерпретируемой программы, что у скомпилированной. Я бы, кстати, хотел иметь возможность измерять время работы чисто кода JVM, без всяких временных добавок, которые возникают от прерываний на системные вызовы или переключение процессора на другие программы. Просто чтобы знать как различные вариации алгоритма влияют на время работы. Только вот, хотеть не вредно.

-- 10.01.2021, 21:58 --

mihaild в сообщении #1500136 писал(а):

На моем i7-6600U получается 4-5 итераций за такт.

[StepV]

B@R5uk в сообщении #1500149 писал(а):

это не значит, что после JIT-компиляции программа выполняется виртуальным процессором в виртуальном мире. Это уже вполне конкретный программный код, который дёргает реальные регистры процессора.

Если человек верит, то его могут переубедить только факты, а их у меня нет.
Поэтому просто имейте ввиду то, что я сообщил, может когда и пригодится.

[B@R5uk]

mihaild в сообщении #1500102 писал(а):

а есть какая-то возможность посмотреть, какой в итоге ассемблер получается?

Нашёл на стэк-оверфлоу соответствующий запрос. Он правда 11-летней давности, и что-то может быть не актуально (например, версии Джавы младше 1.8 официально выпилили из общего доступа в вопреки ранее придерживавшейся политике). Пишут, что ассемблер посмотреть таки можно (или можно было какое-то время назад), но нужно устанавливать дополнительные библиотеки. Пока разбираюсь. Одна статья, другая книжка.

[mihaild]

StepV в сообщении #1500147 писал(а):

поэтому у кодов фактически идентичных CPP и Java будет большое различие во времени исполнения, именно из-за системных издержек

Как это связано с

StepV в сообщении #1500138 писал(а):

Т.е если для реально работающей OS время выполнения куска вашей программы составило 10 мс, то вы, считав регистры виртуального процессора, делаете вывод, что уложились, к примеру, в 100 микросекунд

?
Вообще, что значит последнее утверждение? ТС измеряет время работы своих функций в наносекундах, в каком еще смысле можно воспринимать эти данные?

B@R5uk в сообщении #1500149 писал(а):

Это уже вполне конкретный программный код, который дёргает реальные регистры процессора. Да, он может быть значительно менее оптимальным, чем код, который генерирует какой-нибудь современный gcc, но это всё равно процессорный код.

На самом деле даже бинарный код непосредственно не исполняется, а транслируется в микрокод.

B@R5uk в сообщении #1500149 писал(а):

А что вас удивляет? На skylake инструкция _mm256_add_epi8, складывающая два 32-х элементных байтовых вектора, имеет latency 0.33 - то есть теоретически за один такт можно обработать 96 байт (потом нужно будет еще горизонтально всё сложить, но это делается один раз в конце).

[B@R5uk]

mihaild в сообщении #1500173 писал(а):

На самом деле даже бинарный код непосредственно не исполняется, а транслируется в микрокод.

Это тоже JIT-компиляция, почитайте последнюю мою ссылку. Там пишут про несколько уровней компиляции, различающихся скоростью собственно компиляции и скоростью результирующего кода. Один и тот же метод в зависимости от его "нагретости" может быть перекомпилирован несколько раз в процессе работы программы. Я это, кстати, во время экспериментов интуитивно почувствовал, только не совсем понял, что это было. И это всё можно как-то отслеживать. Достаточно где-то достать JVM, которая поддерживает ключ -XX. Вопрос только вот: где?

[mihaild]

B@R5uk в сообщении #1500175 писал(а):

Это тоже JIT-компиляция, почитайте последнюю мою ссылку

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

[B@R5uk]

mihaild в сообщении #1500176 писал(а):

Которую?

Вот эту. Возможно я просто не понял, что вы имеете в виду под микрокодом.

B@R5uk в сообщении #1500175 писал(а):

Достаточно где-то достать JVM, которая поддерживает ключ -XX. Вопрос только вот: где?

Оказывается кое-что доступно из коробки. Запуск JVM с ключами -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation создаёт log-файл XML-формата, в котором записана подробная инфа о том, что происходило в JVM. Правда понять что там записано без подробного гайда вряд ли выйдет. И самое главное, ключ -XX:+PrintOptoAssembly недоступен:

Error: VM option 'PrintOptoAssembly' is notproduct and is available only in debug version of VM.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

[Geen]

mihaild в сообщении #1500140 писал(а):

System.nanoTime возвращает время в наносекундах

Ой ли......

[mihaild]

B@R5uk в сообщении #1500182 писал(а):

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

https://en.wikipedia.org/wiki/Microcode
В данном случае это всё не очень важно, просто хотел упомянуть, что разница между байт-кодом и бинарным меньше, чем кажется (потому что бинарный код тоже на самом деле напрямую не запускается).

-- 11.01.2021, 00:44 --

Geen в сообщении #1500183 писал(а):

Ой ли.

?

[Geen]

mihaild в сообщении #1500184 писал(а):

Geen в сообщении #1500183 писал(а):

Ой ли.

?

1. каково реальное разрешение?
2. каковы накладные расходы?
3. какова точность/воспроизводимость?
4. время чего измеряется?

[B@R5uk]

Geen, если вам действительно интересны подробности, предлагаю почитать статью. Если tl/dr, то гранулярность System .nanoTime () не хуже микросекунд, а время чтения порядка сотни тактов процессора. Впрочем, можно поэкспериментировать. Результат наверняка зависит от железа и операционки. Для моей винды 7 следующая программа:

Используется синтаксис Java

public class Test_NanoTime {
    
    private static final int stopperValue = 0;
    
    private static final int num = 100;
    private static final long [] stamps = new long [num];
    
    public static void main (String [] args) {
        int k, l, m;
        long value;
        
        m = 0;
        for (k = 0; num > k; ++k) {
            for (l = 0; stopperValue > l; ++l) {
                if (0 == (l & 3)) {
                    ++m;
                }
            }
            stamps [k] = System .nanoTime ();
        }
        
        System .out .println (m);
        System .out .println ();
        System .out .println (stamps [0]);
        for (k = 1; num > k; ++k) {
            value = stamps [k];
            System .out .println (value + " " + (value - stamps [k - 1]));
        }
    }
}
 

Выдаёт такой результат:

Используется синтаксис Text

0

657724595953157
657724595954627 1470
657724595956098 1471
657724595957568 1470
657724595958548 980
657724595960018 1470
657724595961489 1471
657724595962469 980
657724595963939 1470
657724595965410 1471
657724595966390 980
657724595967860 1470
657724595969331 1471
657724595970311 980
657724595971781 1470
657724595972761 980
657724595974232 1471
657724595975702 1470
657724595976682 980
657724595978153 1471
657724595979133 980
657724595980603 1470
657724595982074 1471
657724595983054 980
657724595984524 1470
657724595985995 1471
657724595986975 980
657724595988445 1470
657724595989915 1470
657724595990896 981
657724595992366 1470
657724595993346 980
657724595994817 1471
657724595995797 980
657724595997267 1470
657724595998738 1471
657724595999718 980
657724596001188 1470
657724596002659 1471
657724596003639 980
657724596005109 1470
657724596006089 980
657724596007560 1471
657724596009030 1470
657724596010010 980
657724596011971 1961
657724596046769 34798
657724596048239 1470
657724596049220 981
657724596050690 1470
657724596052160 1470
657724596053140 980
657724596054611 1471
657724596056081 1470
657724596057061 980
657724596058532 1471
657724596059512 980
657724596060982 1470
657724596062453 1471
657724596063433 980
657724596064903 1470
657724596066374 1471
657724596067354 980
657724596068824 1470
657724596070294 1470
657724596071275 981
657724596072745 1470
657724596074215 1470
657724596075196 981
657724596076666 1470
657724596078136 1470
657724596079117 981
657724596080587 1470
657724596082057 1470
657724596083037 980
657724596084508 1471
657724596085488 980
657724596086958 1470
657724596088429 1471
657724596089409 980
657724596090879 1470
657724596092350 1471
657724596093330 980
657724596094800 1470
657724596095781 981
657724596097251 1470
657724596098721 1470
657724596099701 980
657724596101172 1471
657724596102642 1470
657724596103622 980
657724596105093 1471
657724596106073 980
657724596107543 1470
657724596109014 1471
657724596109994 980
657724596111464 1470
657724596112935 1471
657724596113915 980
657724596115385 1470
 

Варьируя переменную stopperValue убеждаемся, что получившиеся разности связаны как с гранулярностью времени, так и с временем вызова функции System .nanoTime (). Возможно, код ещё не сджитился, и эта гранулярность является периодом выполнения байт-кода. В любом случае, она не хуже 490 наносекунд (половина от меньшей разности, треть от большей), чего для моих предыдущих тестов достаточно сверх головы.

Geen в сообщении #1500185 писал(а):

4. время чего измеряется?

На это вопрос лучше всего отвечает документация:

Цитата:

public static long nanoTime()

Returns the current value of the running Java Virtual Machine's high-resolution time source, in nanoseconds.

This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary origin time (perhaps in the future, so values may be negative). The same origin is used by all invocations of this method in an instance of a Java virtual machine; other virtual machine instances are likely to use a different origin.

This method provides nanosecond precision, but not necessarily nanosecond resolution (that is, how frequently the value changes) - no guarantees are made except that the resolution is at least as good as that of currentTimeMillis().

Differences in successive calls that span greater than approximately 292 years ($2^{63}$ nanoseconds) will not correctly compute elapsed time due to numerical overflow.

The values returned by this method become meaningful only when the difference between two such values, obtained within the same instance of a Java virtual machine, is computed.

В дополнение надо заметить, что метод использует наилучший (в смысле разрешения) из доступных в системе таймеров.

StepV в сообщении #1500157 писал(а):

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

По поводу фактов и доказательств. Предлагаю ознакомиться со статьёй. Приведён пример программы и соответствующий ей ассемблерный код.

[StepV]

mihaild в сообщении #1500173 писал(а):

ТС измеряет время работы своих функций в наносекундах, в каком еще смысле можно воспринимать эти данные?

B@R5uk в сообщении #1500188 писал(а):

По поводу фактов и доказательств. Предлагаю ознакомиться со статьёй
.

Поискал в интернете подтверждение моих слов. Нашел не очень складную обзорную статью о симуляции виртуального времени https://habr.com/ru/company/intel/blog/260119/ - это часть вторая, в первой части идет речь о том, сколько разных таймеров, не связанных друг с другом, работают на ПК. В этой же коротко написано о том, о чем писал и я. На виртуальной машине пока она не загружена на CP таймеры стоят. Поэтому замеры с помощью утилит, типа $nanoTime$, дают вроде бы согласованное время, но оно не учитывает времени, на которое были остановки виртуальной машины.
При чем, скорее всего (из моего прошлого опыта), каждый вызов $nanoTime$ приводит к снятию вашей программы с CP. В силу встроенной защиты, ваша программа исполняется на пользовательском уровне, а для получения системной информации и информации с контроллеров требуется системный уровень привилегий. Поэтому возникает прерывание и на CP садится диспетчер, который выполняет в ваших интересах интерфейсную процедуру, а затем просматривает очереди запущенных процессов и, если нет срочной приоритетной работы, то возвращает управление в вашу программу. Поэтому при повышенной загрузке компьютера у вас будут совсем другие цифры задержек, т.к. системная часть времени обслуживания увеличивается. Но по вашему обсуждению точности измерений я вижу, что вы к этому готовы.
Обычно, тех, кто только начал заниматься измерением времен работы программы, их очень раздражает эта плавающая платформа измерений. Хочется, чтобы разбежка была минимальна.
По вашей ссылки статью почитал. Спасибо, интересно.

[mihaild]

StepV в сообщении #1500230 писал(а):

Поэтому замеры с помощью утилит, типа $nanoTime$, дают вроде бы согласованное время, но оно не учитывает времени, на которое были остановки виртуальной машины.

Это легко опровергается посылкой SIGSTOP и позже SIGCONT процессу - время, в течении которого процесс не выполнялся, всё равно учитывается в nanoTime.

[StepV]

mihaild в сообщении #1500234 писал(а):

посылкой SIGSTOP и позже SIGCONT процессу - время, в течении которого процесс не выполнялся, всё равно учитывается в nanoTime.

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