Hello,
La sortie d’Enna au début janvier à réveiller des critiques de tous les genres. En principe (faut être honnête) elles ne m’intéressent pas spécialement. Tout d’abord je n’estime pas qu’il y ait de concurrence entre les logiciels libres. Beaucoup de projets s’inspirent d’autres projets et c’est normal. Et si quelqu’un désire une fonctionnalité spécifique il a plusieurs solutions. La première c’est d’utiliser le projet qui offre la fonctionnalité (non?). La seconde c’est de critiquer simplement le projet car une fonctionnalité évidente est absente. Se sont ces critiques là que j’ignore spécialement, car elles n’apportent rien. Après vous avez des gens qui critiquent mais qui aident spontanément et ils sont toujours les bienvenue.
Une des critique facile est de dire qu’Enna ne fonctionne pas sous Windows et qu’XBMC par contre est multi-plateforme. Les gens qui le disent ont tendance à oublier (ou alors à ne pas du tout connaitre, même dans les grandes lignes) l’histoire XBMC. Et oui, à l’origine XBMC ne fonctionnait pas nativement sous Linux. Le port à pris du temps, et c’est le même problème quand il faut porter dans l’autre sens.
Pour en revenir à Enna, je n’ai aucun intérêt personnel à l’avoir sous Windows. Néanmoins il y a eu des progrès pour qu’un jour, Enna puisse fonctionner sous Windows. Pour quand? Je n’en sais rien et ça n’a aucune importance.
Concernant le titre, si j’ai mis POSIX entre guillemets c’est parce que tout n’est pas vraiment du POSIX. Certaines choses sont des extensions du GNU par exemple. Il y a des adaptations à faire aussi entre les systèmes qui se basent sur POSIX. Même entre les noyaux Linux et *BSD, voir même Hurd.
Par exemple libvalhalla fonctionne correctement sous les noyaux Linux et FreeBSD (je pense spécialement à Debian GNU/kFreeBSD), elle fonctionne aussi avec Hurd (testé avec Debian GNU/Hurd) à la différence que les priorités sur les threads ne sont pas gérées correctement. Chaque noyau à sa façon de faire des threads et ça demande de prendre en compte les cas particuliers.
J’ai volontairement omis de mentionner Mac OS X, ou plus précisément Darwin. Bien qu’Apple dit qu’il soit POSIX-compliant, il y a qu’en même au moins un cas particulier dans libvalhalla car ce n’est pas si POSIX que ça.
Le meilleur moyen de réaliser des ports Windows est sans aucun doute MinGW. C’est une base GCC et le compilateur peut être natif Windows ou alors compilé pour une compilation croisée sous GNU/Linux (ou d’autres OS). En principe depuis GNU/Linux on peut cross-compiler aussi bien pour Windows que pour Darwin (c’est ainsi que les différentes versions du générateur d’ISO sont faites). Néanmoins, ça peut paraitre étonnant mais il est plus facile de créer un compilateur croisé pour Windows (merci au projet MinGW) que pour Darwin.
J’ai deux cross-compilateurs binaires pour Darwin8 (PPC et i686). Ils ont été créés il y a maintenant plusieurs années par un ancien membre de GeeXboX. Malheureusement il est parti avec les secrets de fabrication. Je n’ai jamais réussi à les reproduire depuis les sources (et ce n’est pas faute d’avoir essayé). Si quelqu’un à des pistes, elles m’intéressent grandement!
Avant d’espérer Enna sous Windows il faut bien sûr se concentrer sur les dépendances. Et ce qui nous intéresse ici c’est donc libnfo, libplayer et libvalhalla. Au moment où j’écris cet article, libnfo et libvalhalla sont “complètement” supportés sous Windows. Je vais reprendre quelques éléments intéressants qui ont posés des problèmes.
Notez les guillemets, car en ce qui concerne libvalhalla il reste un potentiel problème. Mais néanmoins la bibliothèque est utilisable.
Libvalhalla utilise des temporisations à différents endroits. Celles-ci sont
réalisées à l’aide de variable-conditions/mutex. L’idée est d’avoir des
temporisations interruptibles contrairement à des fonctions du type sleep(),
usleep() ou nanosleep() (attention, je parle bien de temporisations
interruptibles sans l’aide de signaux). La bibliothèque Pthreads de
POSIX offre tout ce dont on a besoin. Ainsi libvalhalla et libplayer reposent
complètement sur celle-ci. Mais ce n’est pas directement de Pthreads que je
désire parler, mais du temps pour pouvoir espérer avoir des temporisations plus
ou moins précises. Les fonctions pthreads utilisent la structure
struct timespec qui en théorie offre un champ à la nanoseconde. Même si la
valeur peut être juste au moment de la lecture de l’horloge, les appels de
fonctions prennent de toutes façon des nanosecondes/microsecondes. Et même pour
un système temps réel dur, c’est très difficile de jouer dans ces ordres de
grandeurs. Les seuls applications pratiques où je me suis vraiment amusé à
compter les nanosecondes c’est lorsque que je faisais du VHDL sur un bon
vieux Xilinx.
Bref.. passons.. Mon but est de pouvoir traiter des temporisations de plusieurs centaines de millisecondes. Ce qui est très facile avec un noyau Linux. La structure timespec évoquée précédemment se présente ainsi.
struct timespec {
time_t sec;
long int nsec;
}
Sous *BSD, Linux et Darwin il est très facile de la peupler. Concernant Mac OS
X et son pseudo POSIX-compliant, le noyau Mach permet de récupérer une
structure relativement semblable avec également des nanosecondes, mais la
fonction POSIX clock_gettime() n’existe pas chez Apple. Que le champ nsec soit
juste ou non ça n’a pas d’importance, pour autant qu’il ne soit pas faux dans
les millisecondes. Finalement ces trois noyaux offrent les fonctions nécessaires
et même plus. Mais on ne peut pas en dire autant de l’API Windows.
Windows met à disposition des fonctions nommées GetSystemTime() et
GetSystemTimeAsFileTime(). Elles sont sensées retourner une résolution à la
milliseconde, respectivement à la centaine de nanoseconde.
GetSystemTimeAsFileTime() est connu comme étant plus rapide que
GetSystemTime(). Par contre cette fonction n’existe pas sous Windows CE et
perd donc de son intérêt (dès le moment qu’on recherche la portabilité).
Voyez plutôt le résultat en pratique avec mon PC.
WinXP GNU/Linux/Wine
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GetSystemTime ()
1266227465.000000000 1266233962.000000000
1266227465.000000000 1266233962.000000000
1266227465.000000000 1266233962.000000000
1266227465.000000000 1266233962.000000000
1266227465.000000000 1266233962.000000000
- wait 1 ms
1266227465.015000000 1266233962.001000000
- wait 2 ms
1266227465.031000000 1266233962.003000000
- wait 3 ms
1266227465.046000000 1266233962.006000000
- wait 4 ms
1266227465.062000000 1266233962.010000000
- wait 5 ms
1266227465.078000000 1266233962.015000000
A gauche il y a donc les résultats directement depuis Windows XP. A droite c’est
le même programme mais exécuté à travers Wine (le même PC est utilisé). Les
attentes de 1 à 5 ms sont réalisées simplement par la fonction Sleep()
également mise à disposition par l’API Windows. Il est intéressant de noter que
Windows n’arrive pas à descendre à la milliseconde avec un Sleep(1). Problème
connu ceci dit…
A noter également que la fonction GetSystemTime() n’est pas des plus
performante. Elle est reconnue comme étant peu propice à offrir réellement 1 ms
de résolution. J’ai fais ainsi une seconde mesure avec 10'000 lectures du
compteur, pour détecter la résolution effective.
Après plus de 8'000 lectures, Windows retourne vraiment 15 ms de plus que la lecture précédente.
1266484241.000000000
1266484241.000000000
... ~8000 fois ...
1266484241.000000000
1266484241.000000000
1266484241.015000000
1266484241.015000000
1266484241.015000000
1266484241.015000000
J’ai donc refais les mêmes mesures mais avec GetSystemTimeAsFileTime() pour
voir si on arrive à des meilleurs résultats. Le MSDN parle de 100 ns, on peut
donc espérer une résolution utilisable à la milliseconde.
WinXP GNU/Linux/Wine
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GetSystemTimeAsFileTime ()
1266227465.078125000 1266233962.015939000
1266227465.078125000 1266233962.015941000
1266227465.078125000 1266233962.015942000
1266227465.078125000 1266233962.015944000
1266227465.078125000 1266233962.015945000
- wait 1 ms
1266227465.093750000 1266233962.017012000
- wait 2 ms
1266227465.109375000 1266233962.019076000
- wait 3 ms
1266227465.125000000 1266233962.022139000
- wait 4 ms
1266227465.140625000 1266233962.026204000
- wait 5 ms
1266227465.156250000 1266233962.031268000
La première chose qui frappe ici, c’est que Windows semble donner que des valeurs multiples de 25. Donc d’une résolution de 25 us. On est encore relativement loin des 100 ns promis par le MSDN. Mais pour tester la vrai résolution, j’ai également fais tourner la lecture 10'000 fois.
On constate que Wine arrive à atteindre la microseconde. Néanmoins on n’a pas non plus la résolution de 100 ns. La raison est que Wine se base sur la fonction
gettimeofday()qui sous les systèmes POSIX, ne donne pas une résolution meilleure que la microseconde. La structure est un timeval au lieu d’un timespec avec un champ usec au lieu de nsec.
Ici aussi, après environ 8'000 lectures, on constate une résolution d’exactement :
$$109.375-93.75=15.625,ms$$
C’est aussi mauvais qu’avant. Les microsecondes n’apportent absolument rien. Au début je me suis fais avoir car je pensais vraiment que les 25 us étaient atteints. Et bien que la fonction est sensée être plus rapide d’après mes recherches, en pratique (sous Windows XP), il n’y a pas de quoi en faire une montagne. Il a fallut presque le même nombre de lecture (un peu plus de 8000) pour environ 15 ms.
1266484241.093750000
1266484241.093750000
... ~8000 fois ...
1266484241.093750000
1266484241.093750000
1266484241.109375000
1266484241.109375000
1266484241.109375000
1266484241.109375000
Je pense qu’elle est considérée comme plus rapide car elle ne peuple pas une
structure relativement complexe comme GetSystemTime (voir SYSTEMTIME).
La structure utilisée avec la seconde fonction est FILETIME.
Finalement, comme première conclusion et pour garder la compatibilité avec
Windows CE on peut utiliser GetSystemTime() sans regret.
Il existe donc un moyen d’avoir une bien meilleur résolution. Le principe est
d’utiliser l’horloge haute résolution (la TSC dans les processeurs x86) afin
d’atteindre la nanoseconde. Pour ce faire, Windows met à disposition deux
fonctions, QueryPerformanceFrequeny() conjointement avec
QueryPerformanceCounter().
Le but final est de simuler la fonction clock_gettime() de POSIX qui permet
d’atteindre une résolution de 1 ns.
La première fonction donne la fréquence de l’horloge haute résolution et la seconde donne le nombre de ticks depuis la mise en route. La fréquence donnée est toujours (à peu de chose près) un multiple de 1'193'182 Hz.
Le principe est donc de retrouver le tick qui correspond à un temps précis depuis EPOCH. Puis de retrouver le temps en divisant simplement le nombre de ticks par la fréquence. L’horloge étant au minimum cadencée à 1'193'182 Hz, on devrait avoir au moins une résolution de :
$$\frac{1}{1193182}=838.10,ns$$
WinXP GNU/Linux/Wine
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Freq: 3579545 Freq: 1193182
1266227465.156298915 1266233962.031381633
1266227465.156301150 1266233962.031384147
1266227465.156302826 1266233962.031385823
1266227465.156304502 1266233962.031387499
1266227465.156306178 1266233962.031389176
- wait 1 ms
1266227465.171900059 1266233962.032571728
- wait 2 ms
1266227465.187522995 1266233962.034622547
- wait 3 ms
1266227465.203157943 1266233962.037689975
- wait 4 ms
1266227465.218764954 1266233962.041754736
- wait 5 ms
1266227465.234392918 1266233962.046825211
A noter que Wine donne toujours la fréquence la plus basse. Cette fréquence
normalement dépend du matériel, mais Wine se base sur Linux pour récupérer le
temps. Ainsi la fréquence peut être arbitraire. Windows XP me donne par contre
une fréquence pas tout à fait correcte. Comme je l’ai dis avant, celle-ci
devrait être un multiple de 1'193'182, pourtant pour que ce multiple soit vrai,
il faudrait alors 3'579'546 au lieu de 3'579'545. Je suppose que la fonction
QueryPerformanceFrequeny() n’arrondit pas la valeur.
On trouve ici un pas de 1676/1677 ns. Aussi bien avec Windows qu’avec Wine. Ce qui est très bon. Le temps perdu vient désormais des appels de fonctions et non plus de l’imprécision des valeurs de temps.
On pourrait crier victoire, mais en réalité il y a encore un problème potentiel. L’horloge haute résolution est indépendante. Ce qui veut dire qu’elle va forcément diverger par rapport à l’horloge qui donne le “vrai” temps. Ainsi sur une longue période, l’erreur entre les deux va s’agrandir linéairement.
Etant donné que la résolution de
GetSystemTimeAsFileTime()est trop imprécise pour de courtes mesures, il est nécessaire de faire des mesures sur plusieurs heures pour avoir des résultats significatifs. Seul la résolution de 15.625 ms peut servir de référence et une telle divergence ne peut pas être détectée sur quelques minutes (à moins queQueryPerformanceCounter()etQueryPerformanceFrequeny()soient complètement faux). Je n’ai donc rien à vous montrer au sujet de ce potentiel problème de divergence.
Bien que je ne connaisse pas encore la divergence entre les horloges, on peu légitimement se poser la question de la resynchronisation.
Le principe est d’utiliser une information qui est fiable. Et donc a priori c’est la seconde. L’idée est de récupérer le tick qui correspond au changement de seconde. Ensuite ce tick est converti en un temps depuis EPOCH (un temps absolu en seconde). On mémorise cette seconde pour toute la durée de vie du programme.
Dès que clock_gettime() est appelé, on regarde la valeur du compteur de
l’horloge haute résolution, puis on la soustrait à la valeur qui correspond aux
secondes du début. On a donc une différence de valeur du compteur. On la divise
par la fréquence du compteur ce qui nous donne la différence de temps. On
additionne ce nouveau temps avec les secondes du départ pour enfin avoir le
temps en nanoseconde depuis EPOCH.
Le potentiel problème avec la synchronisation vient spécialement du fait d’utiliser la seconde comme référence. Si la synchronisation commence au début d’une nouvelle seconde, il faut attendre quasiment une seconde pour terminer la synchronisation. Ainsi actuellement dans le libvalhalla pour Windows, il n’y a pas de resynchronisation. En fonction du décalage entre l’horloge haute résolution et l’horloge du temps, les timers finissent par se rentrer dedans ou alors par devenir de plus en plus écartés. Le fait qu’ils divergent ou convergent dépend du matériel.
Je vois deux solutions pour le moment.
clock_gettime() avec la précédente synchronisation.GetSystemTimeAsFileTime() avec son pas de 15.625 ms. Mais
la compatibilité avec Windows CE est perdue.Il reste aussi à déterminer quand est-ce qu’il faut resynchroniser.
Un autre problème vient des changements de l’heure du système. Si cela arrive, actuellement libvalhalla aura toutes les temporisations faussées sous Windows.
Finalement, on peut se demander si tout cela vaut la peine. Les Pthreads pour
Windows ont été conçus pour fonctionner sur un maximum de versions de Windows.
Ainsi la référence de temps utilisée se fait via GetSystemTime(). Le
clock_gettime() utilisé dans libvalhalla à deux raisons d’être. D’abord il
sert à donner un temps absolu aux fonctions Pthreads, et il sert à faire les
mesures de temps pour les statistiques. L’aberration dans tout ce travail sur un
clock_gettime() pour Windows est simplement que le temps donné aux fonctions
Pthreads est de bien meilleur résolution que la résolution du temps interne au
Pthreads-win32 (il faudrait néanmoins que je vérifie ce point, je n’ai fais que
survoler les sources de Pthreads-win32). Et avoir une résolution à la
nanoseconde pour des statistiques n’apporte rien.
Un des seul intérêt restant c’est donc le petit défi que ça représente.
J’hésite à enlever tout le code relatif à QueryPerformanceCounter() pour
n’utiliser que GetSystemTime() avec sa misérable résolution. Ou alors rajouter
un test sur la fonction GetSystemTimeAsFileTime() pour la préférer à
GetSystemTime() si elle existe. Tout ces problèmes me rappel toujours un peu
plus pourquoi Windows à un noyau qui n’a rien de plus que les autres. Mais qui
au contraire, ne créer que des problèmes supplémentaires.
Je profite de cet article pour présenter les speedhacks (ces logiciels de triches permettant par exemple de se déplacer plus vite dans un jeu, très prisé à l’époque sur Counter-Strike).
Si j’en parle ici c’est qu’ils reposent sur les fonctions de l’horloge haute
résolution, et plus précisément QueryPerformanceCounter(). Il y a un peu plus
d’un an, j’avais écris un article à ce sujet que vous pouvez lire à cette
adresse. J’en ai profité pour y faire deux trois améliorations et
corrections.
A bientôt,
Mathieu SCHROETER