alex_kО чем вообще говорить, если в Java нет const :)
auto то хоть появилось?

const и auto для идиотов не положено

Вот вам коллектор и говнонативный буфер - все остальное лучше сделают профи.

Оййй фул гц убил приложение ? Включи мозг идиот !!! Это тебе не нужно

Basil A. Sidorovrdb_devРасскажи-ка, как ты, к примеру, собираешься писать на Java функцию "низкоуровневой либы", использующую инструкцию процессора RDTSCP для чтения инвариантного процессорного TimeStamp Counter?Вот нахрена этот регистр, если "Since 1.5" существует System.nanoTime() ?
Зачем решать задачу, которая вообще не задача, а чья-то тупая прихоть?

P.S.
Да, я читал про "наносекундное разрешение, но не наносекундная точность" и прекрасно понимаю, что это означает.
Тут, опять-таки, всё просто - реальная задача, в которой именно, что требуется считать тики процессора.

P.P.S.
Особо рьяным напоминаю, что Java никогда не позиционировалась как система " гарантированного реального времени".


http://dolzhenko.blogspot.com/2012/11/java-nanotime.html

Basil A. Sidorovsemen.s.semenпропущено...
http://dolzhenko.blogspot.com/2012/11/java-nanotime.html


Т.о. последовательные вызовы nanoTime() корректны не в пределах одной jvm, сколько в пределах одного ядра cpu внутри одной jvm.


Ну и какие можно делать замеры с вашим nanotime ?

semen.s.semenBasil A. Sidorovпропущено...



Т.о. последовательные вызовы nanoTime() корректны не в пределах одной jvm, сколько в пределах одного ядра cpu внутри одной jvm.


Ну и какие можно делать замеры с вашим nanotime ?

Правильно ! В пределах потока.

Да и то есть подозрение что на некоторых платформах поток может сказать между ядрами

rdb_devsemen.s.semen http://dolzhenko.blogspot.com/2012/11/java-nanotime.html Статья сильно устарела, так как ссылается на RDTSC, а не на RDTSCP, между которыми очень большие отличия. Дело в том, что RDTSC действительно читает TSC, реализованные в каждом отдельном ядре, инициализирующиеся не одновременно, тики которых зависят не только от частоты FSB, но и от постоянно меняющегося SpeedStep'ом множителя частоты ядра, тогда как RDTSCP, впервые появившаяся в процессорах на ядре Nehalem, читает инвариантный TSC, единый для всех ядер и зависящий только от номинального (константного) множителя и частоты FSB. Но и тут есть свои подводные камни! Дело в том, что частота FSB тоже не постоянна и может колебаться в пределах -0.2% от номинальной. По этой причине, инвариантный TSC также нельзя использовать для точного определения системного времени, так как определение системного времени через эту фичу от момента первого замера может давать небольшую погрешность в несколько миллисекунд за сутки.

Ну вот поэтому чуваки и запилили jninanos на С.

Итого:

Хотим нормально работать с нативом на больших нагрузка - С/C++.

Хотим измерять латенси - С/C++.

Хотим стабильный отклик - C/C++.

semen.s.semenХотим нормально работать с нативом на больших нагрузка - С/C++.

Хотим стабильный отклик - C/C++.

Да да VarHandles профессионалы заоптимизировали - знаю.