System.nanoTime () est-il complètement inutile?

Comme documenté dans le billet de blog Attention à System.nanoTime () en Java , sur les systèmes x86, System.nanoTime () de Java renvoie la valeur de temps en utilisant un compteur spécifique au processeur . Considérons maintenant le cas suivant que j'utilise pour mesurer le temps d'un appel:

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

Or, dans un système multicœur, il se pourrait qu'après la mesure du temps1, le thread soit planifié sur un processeur différent dont le compteur est inférieur à celui de la CPU précédente. Ainsi, nous pourrions obtenir une valeur dans time2 qui est inférieure à time1. Ainsi, nous aurions une valeur négative en timeSpent.

Compte tenu de ce cas, n'est-ce pas que System.nanotime est pratiquement inutile pour le moment?

Je sais que la modification de l'heure du système n'affecte pas le nanotime. Ce n'est pas le problème que je décris ci-dessus. Le problème est que chaque CPU conservera un compteur différent depuis sa mise sous tension. Ce compteur peut être inférieur sur la deuxième CPU par rapport à la première CPU. Étant donné que le thread peut être planifié par le système d'exploitation sur le deuxième processeur après avoir obtenu time1, la valeur de timeSpent peut être incorrecte et même négative.

Cette réponse a été écrite en 2011 du point de vue de ce que faisait réellement le Sun JDK de l'époque fonctionnant sur les systèmes d'exploitation de l'époque. C'était il y a très longtemps! La réponse de leventov offre une perspective plus actuelle.

Ce message est faux et nanoTimeest sûr. Il y a un commentaire sur l'article qui renvoie à un article de blog de David Holmes , un gars du temps réel et de la concurrence chez Sun. Ça dit:

System.nanoTime () est implémenté à l'aide de l'API QueryPerformanceCounter / QueryPerformanceFrequency [...] Le mécanisme par défaut utilisé par QPC est déterminé par la couche d'abstraction matérielle (HAL) [...] Cette valeur par défaut change non seulement à travers le matériel, mais aussi à travers le système d'exploitation versions. Par exemple, Windows XP Service Pack 2 a changé les choses pour utiliser la minuterie de gestion de l'alimentation (PMTimer) plutôt que le compteur d'horodatage du processeur (TSC) en raison de problèmes avec le TSC non synchronisé sur différents processeurs dans les systèmes SMP, et en raison de sa fréquence peut varier (et donc sa relation avec le temps écoulé) en fonction des paramètres de gestion de l'alimentation.

Donc, sous Windows, c'était un problème jusqu'à WinXP SP2, mais ce n'est pas le cas maintenant.

Je ne trouve pas de partie II (ou plus) qui parle d'autres plates-formes, mais cet article comprend une remarque que Linux a rencontré et résolu le même problème de la même manière, avec un lien vers la FAQ pour clock_gettime (CLOCK_REALTIME) , qui dit:

1. Clock_gettime (CLOCK_REALTIME) est-il cohérent sur tous les processeurs / cœurs? (L'arc est-il important? Par exemple, ppc, arm, x86, amd64, sparc)

Il devrait ou c'est considéré comme un buggy.

Cependant, sur x86 / x86_64, il est possible de voir des TSC à fréquence variable ou non synchronisés provoquer des incohérences temporelles. Les noyaux 2.4 n'avaient vraiment aucune protection contre cela, et les premiers noyaux 2.6 ne fonctionnaient pas très bien ici non plus. À partir de 2.6.18 et plus, la logique de détection est meilleure et nous reviendrons généralement à une source d'horloge sûre.

ppc a toujours une base de temps synchronisée, donc cela ne devrait pas être un problème.

Donc, si le lien de Holmes peut être lu comme impliquant des nanoTimeappels clock_gettime(CLOCK_REALTIME), alors c'est sûr à partir du noyau 2.6.18 sur x86, et toujours sur PowerPC (car IBM et Motorola, contrairement à Intel, savent en fait comment concevoir des microprocesseurs).

Il n'y a malheureusement aucune mention de SPARC ou de Solaris. Et bien sûr, nous n'avons aucune idée de ce que font les JVM IBM. Mais les JVM Sun sur Windows et Linux modernes réussissent parfaitement.

EDIT: Cette réponse est basée sur les sources qu'elle cite. Mais je crains toujours que cela soit complètement faux. Des informations plus récentes seraient vraiment précieuses. Je viens de tomber sur un lien vers un article plus récent de quatre ans sur les horloges de Linux qui pourrait être utile.

J'ai fait un peu de recherche et j'ai trouvé que si quelqu'un est pédant, alors oui, cela pourrait être considéré comme inutile ... dans des situations particulières ... cela dépend de la sensibilité temporelle de vos exigences ...

Consultez cette citation du site Java Sun:

L'horloge temps réel et System.nanoTime () sont tous deux basés sur le même appel système et donc sur la même horloge.

Avec Java RTS, toutes les API basées sur le temps (par exemple, les minuteurs, les threads périodiques, la surveillance des délais, etc.) sont basées sur le minuteur haute résolution. Et, avec les priorités en temps réel, ils peuvent garantir que le code approprié sera exécuté au bon moment pour les contraintes en temps réel. En revanche, les API Java SE ordinaires ne proposent que quelques méthodes capables de gérer des temps de haute résolution, sans aucune garantie d'exécution à un moment donné. L'utilisation de System.nanoTime () entre différents points du code pour effectuer des mesures de temps écoulé doit toujours être précise.

Java a également une mise en garde pour la méthode nanoTime () :

Cette méthode ne peut être utilisée que pour mesurer le temps écoulé et n'est liée à aucune autre notion de temps système ou d'horloge murale. La valeur renvoyée représente les nanosecondes depuis un certain temps fixe mais arbitraire (peut-être dans le futur, les valeurs peuvent donc être négatives). Cette méthode fournit une précision nanoseconde, mais pas nécessairement une précision nanoseconde. Aucune garantie n'est donnée sur la fréquence à laquelle les valeurs changent. Les différences dans les appels successifs qui s'étalent sur plus d'environ 292,3 ans (2 ⁶³ nanosecondes) ne permettront pas de calculer avec précision le temps écoulé en raison d'un dépassement numérique.

Il semblerait que la seule conclusion qui puisse être tirée est que nanoTime () ne peut pas être considéré comme une valeur précise. En tant que telle, si vous n'avez pas besoin de mesurer des temps séparés par de simples nanosecondes, cette méthode est suffisante même si la valeur renvoyée résultante est négative. Cependant, si vous avez besoin d'une précision plus élevée, ils semblent vous recommander d'utiliser JAVA RTS.

Donc, pour répondre à votre question ... aucun nanoTime () n'est pas inutile ... ce n'est tout simplement pas la méthode la plus prudente à utiliser dans toutes les situations.

Pas besoin de débattre, utilisez simplement la source. Ici, SE 6 pour Linux, faites vos propres conclusions:

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;
  }
}

Depuis Java 7, la System.nanoTime()sécurité est garantie par la spécification JDK. System.nanoTime()Javadoc indique clairement que toutes les invocations observées dans une JVM (c'est-à-dire sur tous les threads) sont monotones:

La valeur renvoyée représente des nanosecondes depuis une heure d'origine fixe mais arbitraire (peut-être dans le futur, les valeurs peuvent donc être négatives). La même origine est utilisée par toutes les invocations de cette méthode dans une instance d'une machine virtuelle Java; d'autres instances de machine virtuelle utiliseront probablement une origine différente.

L'implémentation JVM / JDK est responsable de l'aplanissement des incohérences qui pourraient être observées lorsque les utilitaires du système d'exploitation sous-jacents sont appelés (par exemple ceux mentionnés dans la réponse de Tom Anderson ).

La majorité des autres anciennes réponses à cette question (écrites en 2009-2012) expriment un FUD qui était probablement pertinent pour Java 5 ou Java 6 mais qui n'est plus pertinent pour les versions modernes de Java.

Il convient cependant de mentionner que malgré nanoTime()la sécurité des garanties JDK , il y a eu plusieurs bogues dans OpenJDK qui l'empêchent de respecter cette garantie sur certaines plates-formes ou dans certaines circonstances (par exemple JDK-8040140 , JDK-8184271 ). Il n'y a pas de bogue ouvert (connu) dans OpenJDK nanoTime()pour le moment, mais la découverte d'un nouveau bogue ou une régression dans une nouvelle version d'OpenJDK ne devrait choquer personne.

Dans cet esprit, le code qui utilise nanoTime()pour le blocage temporisé, l'attente d'intervalle, les délais d'attente, etc. devrait de préférence traiter les différences de temps négatives (délais d'attente) comme des zéros plutôt que de lever des exceptions. Cette pratique est également préférable , car il est compatible avec le comportement de toutes les méthodes chronométrées d'attente dans toutes les classes java.util.concurrent.*, par exemple Semaphore.tryAcquire(), Lock.tryLock(), BlockingQueue.poll(), etc.

Néanmoins, il nanoTime()faut toujours préférer pour mettre en œuvre le blocage temporisé, l'attente d'intervalle, les délais d'attente, etc. à currentTimeMillis()parce que ce dernier est sujet au phénomène de «retour en arrière» (par exemple en raison de la correction de l'heure du serveur), c'est currentTimeMillis()-à- dire qu'il n'est pas adapté à la mesure des intervalles de temps du tout. Voir cette réponse pour plus d'informations.

Au lieu d'utiliser nanoTime()directement pour les mesures de temps d'exécution du code, des cadres d'analyse comparative et des profileurs spécialisés devraient de préférence être utilisés, par exemple JMH et async-profiler en mode de profilage d'horloge murale .

Avertissement: je suis le développeur de cette bibliothèque

Vous aimerez peut-être mieux ceci:

http://juliusdavies.ca/nanotime/

Mais il copie un fichier DLL ou Unix .so (objet partagé) dans le répertoire personnel de l'utilisateur actuel afin qu'il puisse appeler JNI.

Certaines informations générales sont sur mon site à:

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

Linux corrige les écarts entre les processeurs, mais pas Windows. Je vous suggère de supposer que System.nanoTime () n'est précis qu'à environ 1 micro-seconde. Un moyen simple d'obtenir une durée plus longue est d'appeler foo () 1000 fois ou plus et de diviser le temps par 1000.

Absolument pas inutile. Les amateurs de chronométrage soulignent correctement le problème multicœur, mais dans les applications de mots réels, il est souvent radicalement meilleur que currentTimeMillis ().

Lors du calcul des positions graphiques dans le cadre, les actualisations nanoTime () permettent un mouvement BEAUCOUP plus fluide dans mon programme.

Et je ne teste que sur des machines multicœurs.

J'ai vu un temps écoulé négatif rapporté à l'aide de System.nanoTime (). Pour être clair, le code en question est:

    long startNanos = System.nanoTime();

    Object returnValue = joinPoint.proceed();

    long elapsedNanos = System.nanoTime() - startNanos;

et la variable «elapsedNanos» avait une valeur négative. (Je suis certain que l'appel intermédiaire a également pris moins de 293 ans, ce qui est le point de débordement pour les nanos stockés dans les longs :)

Cela s'est produit avec un matériel IBM v1.5 JRE 64 bits sur IBM P690 (multicœur) exécutant AIX. Je n'ai vu cette erreur se produire qu'une seule fois, elle semble donc extrêmement rare. Je ne connais pas la cause - est-ce un problème spécifique au matériel, un défaut JVM - je ne sais pas. Je ne connais pas non plus les implications pour la précision de nanoTime () en général.

Pour répondre à la question initiale, je ne pense pas que nanoTime soit inutile - il fournit un timing inférieur à la milliseconde, mais il existe un risque réel (pas seulement théorique) qu'il soit inexact que vous devez prendre en compte.

Cela ne semble pas être un problème sur un Core 2 Duo exécutant Windows XP et JRE 1.5.0_06.

Dans un test avec trois threads, je ne vois pas System.nanoTime () revenir en arrière. Les processeurs sont tous les deux occupés et les threads s'endorment parfois pour provoquer des mouvements de threads.

[EDIT] Je suppose que cela n'arrive que sur des processeurs physiquement séparés, c'est-à-dire que les compteurs sont synchronisés pour plusieurs cœurs sur le même die.

Non, ce n'est pas ... Cela dépend juste de votre CPU, vérifiez le Minuteur d'événements de haute précision pour savoir comment / pourquoi les choses sont traitées différemment en fonction du CPU.

En gros, lisez la source de votre Java et vérifiez ce que votre version fait avec la fonction, et si cela fonctionne avec le processeur sur lequel vous l'exécuterez.

IBM vous suggère même de l' utiliser pour l'analyse comparative des performances (un article de 2008, mais mis à jour).

Je fais un lien avec ce qui est essentiellement la même discussion où Peter Lawrey fournit une bonne réponse. Pourquoi j'obtiens un temps écoulé négatif en utilisant System.nanoTime ()?

Beaucoup de gens ont mentionné que dans Java System.nanoTime () pouvait renvoyer un temps négatif. Je m'excuse de répéter ce que d'autres personnes ont déjà dit.

1. nanoTime () n'est pas une horloge mais un compteur de cycles CPU.
2. La valeur de retour est divisée par la fréquence pour ressembler au temps.
3. La fréquence du processeur peut fluctuer.
4. Lorsque votre thread est planifié sur un autre processeur, il y a une chance d'obtenir nanoTime (), ce qui entraîne une différence négative. C'est logique. Les compteurs des CPU ne sont pas synchronisés.
5. Dans de nombreux cas, vous pourriez obtenir des résultats assez trompeurs, mais vous ne pourrez pas le dire car le delta n'est pas négatif. Pensez-y.
6. (non confirmé) Je pense que vous pouvez obtenir un résultat négatif même sur le même processeur si les instructions sont réorganisées. Pour éviter cela, vous devez invoquer une barrière de mémoire sérialisant vos instructions.

Ce serait cool si System.nanoTime () retournait coreID là où il s'exécutait.

Java est multiplateforme et nanoTime dépend de la plate-forme. Si vous utilisez Java - quand n'utilisez pas nanoTime. J'ai trouvé de vrais bugs dans différentes implémentations jvm avec cette fonction.

La documentation Java 5 recommande également d'utiliser cette méthode dans le même but.

Cette méthode ne peut être utilisée que pour mesurer le temps écoulé et n'est liée à aucune autre notion de temps système ou d'horloge murale.

Doc API Java 5

En outre, System.currentTimeMillies()change lorsque vous modifiez l'horloge de votre système, alors que ce System.nanoTime()n'est pas le cas, ce dernier est donc plus sûr pour mesurer les durées.

nanoTimeest extrêmement incertain pour le timing. Je l'ai essayé sur mes algorithmes de test de primalité de base et il a donné des réponses qui étaient littéralement à une seconde d'intervalle pour la même entrée. N'utilisez pas cette méthode ridicule. J'ai besoin de quelque chose qui soit plus précis et précis que le temps millisime, mais pas aussi mauvais que nanoTime.