Невже марний System.nanoTime ()?

Як задокументовано в публікації блогу Остерігайтеся System.nanoTime () на Java , у системах x86 Java System.nanoTime () повертає значення часу за допомогою лічильника процесора . Тепер розглянемо такий випадок, який я використовую для вимірювання часу дзвінка:

long time1= System.nanoTime();
foo();
long time2 = System.nanoTime();
long timeSpent = time2-time1;

Тепер у багатоядерній системі може бути, що після вимірювання часу1 потік заплановано на інший процесор, лічильник якого менший, ніж у попереднього процесора. Таким чином, ми могли б отримати значення в часі2, яке менше часу1 . Таким чином, ми отримали б негативне значення в timeSpent.

Враховуючи цей випадок, чи не так це, що System.nanotime наразі є майже марним?

Я знаю, що зміна системного часу не впливає на нано-час. Це не проблема, яку я описав вище. Проблема полягає в тому, що кожен процесор буде зберігати інший лічильник з моменту його ввімкнення. Цей лічильник може бути нижчим для другого процесора порівняно з першим процесором. Оскільки потік може бути призначений ОС для другого процесора після отримання часу1, значення timeSpent може бути неправильним і навіть негативним.

Ця відповідь була написана в 2011 році з точки зору того, що насправді робив Sun JDK часу, що працює на операційних системах того часу. Це було давно! Відповідь Левентова пропонує більш сучасну перспективу.

Цей пост невірний і nanoTimeбезпечний. Там є коментар до посту, який посилається на допис у блозі Девіда Холмса , реального часу та одночасного хлопця Sun. Він говорить:

System.nanoTime () реалізується за допомогою API QueryPerformanceCounter / QueryPerformanceFrequency [...] Механізм за замовчуванням, який використовується QPC, визначається рівнем апаратної абстракції (HAL) [...] Цей за замовчуванням змінюється не лише на апаратному забезпеченні, але й у всій ОС версії. Наприклад, Windows XP Service Pack 2 змінив речі, щоб використовувати таймер управління енергією (PMTimer), а не лічильник часових міток процесора (TSC) через проблеми з синхронізацією TSC на різних процесорах в системах SMP, і через те, що його частота може змінюватись (а отже, і її відношення до минулого часу) залежно від налаштувань управління енергією.

Отже, в Windows це було проблемою до WinXP SP2, але це не зараз.

Я не можу знайти частину II (або більше), яка розповідає про інші платформи, але ця стаття містить зауваження про те, що Linux зіткнувся і вирішив ту саму проблему таким же чином, посилаючись на посилаючись поширені запитання для clock_gettime (CLOCK_REALTIME) , який говорить:

1. Чи погоджено тактовий час (CLOCK_REALTIME) у всіх процесорах / ядрах? (Чи має значення арка? Наприклад, ppc, arm, x86, amd64, sparc).

Це повинен або вважається баггі.

Однак на x86 / x86_64 можна побачити, що несинхронізовані або змінні частотні ТСК викликають невідповідність часу. 2.4 ядра справді не мали захисту від цього, і ранні 2.6 ядра теж не дуже добре справились. З 2.6.18 і вище логіка виявлення цього краще, і ми зазвичай повертаємося до безпечного тактового ресурсу.

ppc завжди має синхронізовану базу часу, тому це не повинно бути проблемою.

Отже, якщо посилання Холмса можна прочитати як те, що означає, що це nanoTimeдзвінкиclock_gettime(CLOCK_REALTIME) , то це безпечно як від ядра 2.6.18 на x86, так і завжди на PowerPC (адже IBM і Motorola, на відміну від Intel, насправді знають, як створити мікропроцесори).

На жаль, згадки про SPARC чи Solaris, на жаль. І звичайно, ми не маємо уявлення про те, що роблять JVM IBM. Але Sun JVM на сучасних Windows і Linux це правильно.

EDIT: Ця відповідь ґрунтується на джерелах, які вона цитує. Але я все одно переживаю, що це насправді може бути абсолютно неправильним. Дещо більше актуальної інформації було б дійсно цінним. Щойно я натрапив на посилання на чотирирічну нову статтю про годинники Linux, яка може бути корисною.

Я трохи пошукав і виявив, що якщо хтось веде педантичний, то так, це може вважатися марним ... в конкретних ситуаціях ... це залежить від того, наскільки залежать від ваших вимог ...

Ознайомтеся з цією цитатою на сайті Java Sun:

Годинники в режимі реального часу та System.nanoTime () базуються на одній і тій же системній виклику і, отже, однакові.

Завдяки Java RTS усі API на основі часу (наприклад, Таймери, Періодичні потоки, Моніторинг терміну та ін.) Базуються на таймері високої роздільної здатності. І разом з пріоритетами в режимі реального часу вони можуть забезпечити виконання відповідного коду в потрібний час для обмежень у режимі реального часу. На відміну від цього, звичайні API Java SE пропонують лише декілька методів, здатних керувати часом високої роздільної здатності, без гарантії виконання в даний момент часу. Використання System.nanoTime () між різними точками коду для проведення вимірювань минулого часу завжди повинно бути точним.

У Java також є застереження для nanoTime () методу :

Цей метод може використовуватися лише для вимірювання минулого часу і не пов'язаний з будь-яким іншим поняттям системи або часу настінного годинника. Повернене значення являє собою наносекунд з деякого фіксованого, але довільного часу (можливо, у майбутньому, тому значення можуть бути негативними). Цей спосіб забезпечує наносекундну точність, але не обов'язково наносекундну точність. Не дається гарантій щодо того, як часто змінюються значення. Відмінності в послідовних викликах, що тривають більше, ніж приблизно 292,3 року (2 ⁶³ наносекунди), не будуть точно обчислювати минулий час через чисельне переповнення.

Здавалося б, єдиний висновок, який можна зробити, - це те, що nanoTime () не може покладатися на точне значення. Таким чином, якщо вам не потрібно вимірювати час, який є просто наносекундами, то цей спосіб досить хороший, навіть якщо отримане повернене значення негативне. Однак якщо вам потрібна більш висока точність, вони, як видається, рекомендують використовувати JAVA RTS.

Тож, щоб відповісти на ваше запитання ... жоден nanoTime () не є марним .... його просто не самий розумний метод використовувати у будь-якій ситуації.

Не потрібно дискутувати, просто використовуйте джерело. Ось, SE 6 для Linux, зробіть власні висновки:

jlong os::javaTimeMillis() {
  timeval time;
  int status = gettimeofday(&time, NULL);
  assert(status != -1, "linux error");
  return jlong(time.tv_sec) * 1000  +  jlong(time.tv_usec / 1000);
}


jlong os::javaTimeNanos() {
  if (Linux::supports_monotonic_clock()) {
    struct timespec tp;
    int status = Linux::clock_gettime(CLOCK_MONOTONIC, &tp);
    assert(status == 0, "gettime error");
    jlong result = jlong(tp.tv_sec) * (1000 * 1000 * 1000) + jlong(tp.tv_nsec);
    return result;
  } else {
    timeval time;
    int status = gettimeofday(&time, NULL);
    assert(status != -1, "linux error");
    jlong usecs = jlong(time.tv_sec) * (1000 * 1000) + jlong(time.tv_usec);
    return 1000 * usecs;
  }
}

Оскільки Java 7 System.nanoTime()гарантована в безпеці за специфікаціями JDK. System.nanoTime()Javadoc дає зрозуміти, що всі спостережувані виклики в межах JVM (тобто в усіх потоках) є монотонними:

Повернене значення являє собою наносекунд, оскільки деякий фіксований, але довільний час початку (можливо, у майбутньому, тому значення можуть бути негативними). Те саме походження використовується всіма викликами цього методу в екземплярі віртуальної машини Java; інші екземпляри віртуальної машини, ймовірно, використовують інше походження.

Реалізація JVM / JDK несе відповідальність за виправлення невідповідностей, які могли бути помічені під час виклику базових утиліт ОС (наприклад, зазначених у відповіді Тома Андерсона ).

Більшість інших старих відповідей на це питання (написане у 2009–2012 рр.) Виражають FUD, що, ймовірно, стосується Java 5 або Java 6, але більше не стосується сучасних версій Java.

Однак варто зазначити, що, незважаючи на гарантію nanoTime()безпеки JDK, у OpenJDK було кілька помилок, завдяки чому вона не підтримувала цю гарантію на певних платформах або за певних обставин (наприклад, JDK-8040140 , JDK-8184271 ). У OpenJDK wrt немає відкритих (відомих) помилокnanoTime() , але виявлення нової такої помилки чи регресія в новій версії OpenJDK нікого не повинно шокувати.

Зважаючи на це, код, який використовується nanoTime()для блокування приуроченого часу, інтервального очікування, тайм-аутів тощо, бажано вважати негативними різницями у часі (таймаутами) як нулі, а не викидами. Ця практика також є кращою , оскільки він узгоджується з поведінкою всіх синхронізованих методів очікування у всіх класах в java.util.concurrent.*, наприклад Semaphore.tryAcquire(), Lock.tryLock(),BlockingQueue.poll() і т.д.

Тим не менш, nanoTime()все ж слід віддавати перевагу впровадженню тимчасового блокування, інтервального очікування, тайм-аутів тощо, currentTimeMillis()оскільки останні є предметом явища "час, що йде назад" (наприклад, через корекцію часу на сервері), тобто currentTimeMillis()не підходить для вимірювання часових інтервалів. зовсім. Дивіться цю відповідь для отримання додаткової інформації.

Замість використання nanoTime() для вимірювання часу виконання коду безпосередньо, спеціалізовані бенчмаркінг структури і профайлери переважно повинні бути використані, наприклад , JMH і асинхронної-Profiler в режимі профілювання на стіні годинник .

Відмова: Я розробник цієї бібліотеки

Вам це може сподобатися краще:

http://juliusdavies.ca/nanotime/

Але він копіює файл DLL або Unix .so (спільний об’єкт) у домашній каталог поточного користувача, щоб він міг викликати JNI.

Довідкова інформація розміщена на моєму сайті за адресою:

http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html

Linux виправляє розбіжності між процесорами, але Windows цього не робить. Я пропоную вам припустити, що System.nanoTime () точний приблизно до 1 мікросекунди. Простий спосіб отримати більш тривалий час - зателефонувати foo () 1000 або більше разів і розділити час на 1000.

Зовсім не марно. Прихильники термінів правильно вказують на багатоядерну проблему, але в програмах із реальною програмою це часто докорінно краще, ніж у currentTimeMillis ().

При обчисленні графічних позицій у кадрі оновлює nanoTime (), що призводить до МНОГО більш плавного руху в моїй програмі.

І я тестую лише на багатоядерних машинах.

Я бачив негативний минулий час, повідомлений про використання System.nanoTime (). Щоб було зрозуміло, йдеться про код:

    long startNanos = System.nanoTime();

    Object returnValue = joinPoint.proceed();

    long elapsedNanos = System.nanoTime() - startNanos;

а змінна 'elapsedNanos' мала негативне значення. (Я впевнений, що проміжний дзвінок також зайняв менше 293 років, що є точкою переповнення нано, що зберігається довгими :)

Це сталося за допомогою IBM v1.5 JRE 64bit 64bit на апаратному забезпеченні IBM P690 (багатоядерне), на якому працює AIX. Я бачив, що ця помилка трапляється один раз, тому здається надзвичайно рідкісною. Я не знаю причини - це проблема, що стосується обладнання, дефект JVM - я не знаю. Я також не знаю наслідків для точності nanoTime () в цілому.

Щоб відповісти на первісне запитання, я не вважаю, що nanoTime є марним - він забезпечує підмілісекундний час, але існує фактичний (не лише теоретичний) ризик його неточності, який потрібно враховувати.

Здається, це не є проблемою для Core 2 Duo з ОС Windows XP та JRE 1.5.0_06.

У тесті з трьома потоками я не бачу System.nanoTime (), що йде назад. Процесори і зайняті, і потоки час від часу сплять, щоб спровокувати переміщення ниток.

[EDIT] Я здогадуюсь, що це відбувається лише на фізично окремих процесорах, тобто лічильники синхронізуються для декількох ядер на одній матриці.

Ні, це не так ... Це просто залежить від вашого процесора, перевірте Таймер подій високої точності для того, як / чому все по-різному трактується відповідно до процесора.

В основному, прочитайте джерело вашої Java і перевірте, що робить ваша версія з функцією, і якщо вона працює проти процесора, ви будете її запускати.

IBM навіть пропонує використовувати його для порівняльного аналізу продуктивності (повідомлення 2008 року, але оновлено).

Я посилаюся на те, що по суті - це та сама дискусія, де Пітер Лоурі дає хорошу відповідь. Чому я отримую мінус минулий час за допомогою System.nanoTime ()?

Багато людей згадували, що в Java System.nanoTime () можна повернути негативний час. Я прошу вибачення за повторення того, що вже сказали інші люди.

1. nanoTime () - це не годинник, а лічильник циклу процесора.
2. Повернене значення ділиться на частоту, щоб виглядати як час.
3. Частота процесора може коливатися.
4. Коли ваш потік запланований на інший процесор, є ймовірність отримати nanoTime (), що призводить до негативної різниці. Це логічно. Лічильники між процесорами не синхронізуються.
5. У багатьох випадках ви можете отримати досить оманливі результати, але ви цього не зможете сказати, оскільки дельта не є негативною. Подумай над цим.
6. (непідтверджено) Я думаю, що ви можете отримати негативний результат навіть у тому самому процесорі, якщо інструкції будуть упорядковані. Щоб цього не допустити, вам доведеться застосувати бар'єр пам'яті, послідовно виконуючи ваші вказівки.

Було б здорово, якби System.nanoTime () повернув coreID туди, де він виконується.

Java є кросплатформою, а nanoTime залежить від платформи. Якщо ви використовуєте Java - коли не використовуєте nanoTime. Я знайшов справжні помилки в різних реалізаціях jvm з цією функцією.

Документація Java 5 також рекомендує використовувати цей метод з тією ж метою.

Цей метод може використовуватися лише для вимірювання минулого часу і не пов'язаний з будь-яким іншим поняттям системи або часу настінного годинника.

Документ API Java 5

Крім того, System.currentTimeMillies()змінюється, коли ви змінюєте годинник системи, тоді як System.nanoTime()цього немає, тому останній безпечніше вимірювати тривалість.

nanoTimeє надзвичайно небезпечним для проведення часу. Я спробував це на своїх основних алгоритмах тестування первинності, і він дав відповіді, які були буквально за одну секунду за один і той же вхід. Не використовуйте цей смішний метод. Мені потрібно щось більш точне і точне, ніж отримувати час на мілі, але не так погано, як nanoTime.