En fait, la table que vous citez est fausse pour QueryPerformanceCounter. QPC (pour faire court) est implémenté en termes de 3 sources de temporisation possibles, à savoir 1: HPET, 2: MPI timer minuterie, 3: RDTSC. la décision est prise par heuristique en fonction des conditions, des options de démarrage du noyau, des bogues dans le BIOS et des bogues dans le code ACPI fourni par le chipset. Tous ces bogues sont découverts sur une base matérielle dans les laboratoires Microsoft. Les programmeurs Linux et BSD doivent trouver eux-mêmes la solution et doivent généralement réécrire le code ACPI pour éviter les chutes. La communauté Linux a fini par détester le RDTSC et beaucoup l'ACPI pour différentes raisons. Mais quoi qu'il en soit ...
Le paramètre timeReadTime est différent de GetTickCount car pour des raisons de stabilité, en fonction de la manière dont la documentation spécifiée par GetTickCount a été créée, son comportement n'a pas pu être modifié. Toutefois, les fenêtres nécessaires pour obtenir une meilleure résolution Tick dans certains cas pour permettre de meilleures fonctions de minuterie. (la minuterie fonctionne avec les messages envoyés à la fonction GetMessage ou PeekMessage de l'application, puis se branche dans le bon rappel pour gérer le minuteur) Ceci est nécessaire pour le multimédia comme la synchronisation audio/son.
De toute évidence, la programmation en jeu ou en temps réel nécessite une meilleure précision même parfois et ne peut pas utiliser de minuterie. Au lieu de cela, ils utilisent l'attente occupée, ou ils ne dorment qu'une seule fois: le VSync via un appel à OpenGL ou DirectX uppon backbuffer/frontbuffer swapping. Le pilote vidéo réveillera le signal d'attente VSync du fil d'attente en provenance de l'écran lui-même. Qui est un sommeil basé sur un événement, comme une minuterie, mais pas basé sur une interruption de minuterie.
Il est à noter que les noyaux modernes ont un ticking dynamique (noyau tickless, à partir de windows 8 ou linux 2.6.18). La fréquence d'interruption de tique la plus fine ne peut pas être inférieure à 1 ms pour éviter de s'étouffer, mais il n'y a pas de limite supérieure. Si aucune application n'est en cours d'exécution et ne stocke l'événement de temporisation, la machine peut rester en veille indéfiniment, ce qui permet au processeur de passer à l'état de veille le plus profond (état Intel Enhanced Speed Step C7). Après quoi, l'événement de réveil suivant, la plupart du temps, se produit à cause d'une interruption de l'appareil, principalement USB. (déplacement de la souris ou autre)
Lecture connexe: http://blogs.msdn.com/b/larryosterman/archive/2009/09/02/what-s-the-difference-between-gettickcount-and-timegettime .aspx –
Je ne comprends pas, pourquoi diable voudriez-vous que deux fonctions * winapi * différentes * se comportent de la même façon? Si c'était * conçu * pour être le même que bien sûr, il n'aurait pas été nécessaire d'ajouter une fonction séparée. –
@CodyGray merci pour votre information. Comme l'auteur l'a mentionné: "KeGetTickCount obtient le nombre de ticks, KeQueryInterruptTime obtient le compte de temps d'interruption". Quelle est la différence entre le nombre de tiques et le nombre de temps d'interruption? Je suis perplexe que combien de minuterie basée utilise Windows? – ajaxhe