meynaf a écrit 8 commentaires

M'ouais, ça veut dire que la réactivité est dépendante du timer système.

C'est à dire que quand un process (ou un thread) devient idle, le reste de sa "time slice" est tout bonnement perdu.

Pourquoi ne pas passer à un autre process directement et relancer une nouvelle tranche de temps à partir de là ? C'est à dire, reset du timer ? Au lieu de perdre son temps à ne rien faire en attendant la prochaine interruption...


Au fait, petite info rigolote.
Un vieux 68000 à 8 Mhz comme il y en a dans un Atari St de 1985 est capable de monter à 16000 ints/sec et plus. Soit une interruption tous les 500 cycles d'horloge.
Les PC actuels sont sensés être combien de fois plus rapides ?

Hardcodée dans Linux, le 1000 ? Peut-être. N'empêche que 10000 marcherait aussi bien sur une machine actuelle, non ?
On devrait multiplier cette valeur par 10 à chaque fois que la vitesse des machines est multipliée par 10. Or c'est loin d'être le cas, il me semble ?

Et une microseconde sur une machine à 3Ghz, c'est tout de même 3000 cycles d'horloge. S'il faut tout ça pour changer de process, c'est qu'il y a un truc qui ne va pas quelque part.

De plus, entre une microseconde et une milliseconde, il y a un facteur de 1 à 1000, on a de la marge...

...et c'est bien pour ça qu'il faut lancer le test avec le moins de process possibles qui tournent (bien qu'en théorie un process en attente ne prend rien du tout).

S'il plafonne à 1000... eh bien c'est dommage, parce que quand on a une bécane à 3 Ghz, ça fait 3 millions de cycles d'horloge entre deux changements de process, ce qui est tout bonnement énorme.

Peut-être aussi que la limite vient de l'architecture x86, pas fichue de dépasser le kilohertz.

Je vais mettre tout ça sur mon site (l'url est dans mon message plus haut). Ça devrait être en ligne ce lundi.

Apparamment, le dernier kernel low latency fait toute la différence... en tous cas je suppose que le facteur de *10 vient de là.

Ce que je mesure en fait, c'est le temps mis par le système à redonner le processeur à une application qui vient de le perdre (par un appel sleep() volontaire).

Je fais donc des appels usleep() avec des durées de plus en plus grandes, vérifiant que mon thread a pris le cpu. Si tel n'est pas le cas, le test n'est pas bon, sinon je prends la durée réellement écoulée.
Même en cas de réussite, je continue le test, prenant à l'arrivée le meilleur résultat.

Je ne sais pas si mon source est bien clair à ce sujet...

On dirait que la réactivité dépend assez peu de la vitesse du processeur, et beaucoup de la politique d'ordonnancement du système.

A titre d'exemple, un bon vieux Amiga (de 1992 !), muni d'un 68030 à 50 Mhz, sous OS 3.0, arrive sur ce test à une valeur de... 2500 (entre 2470 et 2510).
Quand je vous dis que ça dépend pas de la vitesse du cpu ;-)


J'aimerais bien savoir ce que donnerait un QNX !!!

C'est exactement ça qu'il me faut comme infos, merci !!!

Quand j'aurai plein de résultats comme celui-là, je les mettrai sur la page :
http://meynaf.free.fr/testeu/(...)

(quand j'en aurai 5 ou 6, je fais la page et je la mets en ligne, un peu de patience...)

C'est vrai que : gcc bench.c pf_linux.c suivi de : ./a.out c'est vachement plus compliqué qu'un makefile dans un tar.gz. En fait j'ai plus l'habitude des environnements de développement que des makefile. (ouh la honte je sais :) J'aurai bientôt les binaires en téléchargement sur mon site, ça sera plus simple que d'avoir à compiler.

Mon code doit compiler sous Linux, oui.

Mais je n'ai PAS de Linux (ni de Windows, d'ailleurs).
Ce que je demande ici, c'est pas qu'on me mâche le travail, c'est de l'aide pour ce que je ne peux pas faire tout seul.

1) Ok, mais c'est si vite fait pour qqn qui a la machine et qui la connaît... Je risque de faire des grosses bourdes sans le savoir.

2) Non parce que ces choses-là ne sont pas trop portables, et j'ai déjà assez de spécifique comme ça dans mon code.

3) Joli site web, je sais pas faire, mais il est clair que quand j'aurai quelques résultats, je ferai le site web avec les binaires et les sources en libre download.


Un CD, pour un petit programme de quelques ko ?
C'est pas un peu le char d'assaut pour aller faire les courses ?


Enfin, merci pour ton humble contribution.

J'ai lu vos commentaires avec la plus vive attention, merci pour la tonne d'encouragements.

Bon, d'accord, je me suis embrouillé avec les licences, j'ai été un peu vif sur certaines affirmations, mais bon...

Se taper tout ce boulot pour lire ça ensuite, franchement c'est désolant.
Est-ce que vous réalisez le travail que c'est, de créer un processeur ?
D'autant que personne n'a fait mieux qu'une critique destructive.

J'ai peut-être utilisé un ton péremptoire, mais le vôtre ici est encore pire.

Au lieu de me dire que je me suis planté, dites plutôt comment ça pourrait être mieux.
Ce serait vachement plus utile !