Bonjour,
En réalisant une interface graphique, j'ai réalisé que la partie la plus était la partie de l'affichage à l'écran
SCENARIO:
Réalisation d'une boucle, qui va afficher des variables tout au long de l'existence de cette boucle
Réalisation d'une boucle, affichage des valeurs uniquement une fois sortie de la boucle
Réalisation d'une boucle, qui va "afficher dans /dev/null" des variables tout au long de l'existence de cette boucle
J'obtiens donc respectivement pour la boucle= calcul de pi à 99.9999% (en python) :
2.0secs
0.1secs
0.58secs
Et pour un script shell (un compteur de 1 à 100000):
5.43secs
1.39secs
3.33secs
Voilà donc quelques valeurs (pour le calcul de pi) pour quelques terminaux :
qterminal: 2.0secs
konsole: 2.3 secs
xfce4-terminal = 2.1secs
xterm=2.0 secs
*tty = 20 secs*
Problème de distro, qu'à celà ne tienne, test sur un VM (version kernel différent):
6.9secs sur terminal sous X
*tty = 271 secs *
Problème de kernel? test sous FreeBSD :
*tty = 3.43secs
xterm (over ssh)=15secs
On voit bien que les terminaux graphiques ont des valeurs sensiblement autour de 2.0secs, mais le tty est vraiment à la ramasse sous linux.
Est ce qu'il y a des raisons à ça ?
Pour info , la valeur pi que j'ai trouvé :
./speedpi.py 99.999999 [19-02-05 ]
Launching the App
3.1415926221738673
8.139520645141602
# accélération et divers contrôles de framerate?
Posté par freem . Évalué à 5. Dernière modification le 06 février 2019 à 01:17.
J'étais intrigué, donc j'ai fait un test, plus simple, en bash:
time for i in $(seq 1 10000); do printf "%d" $i;done.Le résultat est environ de 1.84s sur un TTY, sur 5 essais.
Sur urxvt, je suis à environ 0.19s, l'écart est d'un ordre de grandeur de x10.
Sur TTY via ssh, les résultats changent pas mal, mais en moyenne et à vue de nez, dans les 0.25s.
Sur urxvt, via ssh, dans les 0.35s.
À vue de nez, le TTY est en moyenne et à la louche 10x plus lents que les autres solutions.
Le temps mis par les sessions ssh fluctue énormément, ce que j'aurai envie d'associer au réseau et autres usages CPU ponctuels (le chiffrement, ça doit se sentir, il aurait fallu tester telnet, screen ou tmux pour enlever des causes d'interférences), mais sont proches, tout en étant légèrement plus lents que le test sous urxvt seul.
À vue de nez, pour moi, la constante ici c'est: /dev/ttyXX vs /dev/pts/XX. Je m'avance, mais je suppose que /dev/ttyXX accède à l'écran de manière brute, sans cache, en mode caractère, tandis que /dev/pts/XX doit ajouter un cache, qui doit augmenter les performances drastiquement (parce qu'envoyer 10 blocs de 5 octets est plus lents qu'envoyer un seul bloc de 50 octets, moins d'appels systèmes, notamment).
Bon, théorie à confirmer, hein, je n'ai pas fait de vrais bench, y'a pleins d'applications qui tournent sur cette machine et qui parasitent, je n'ai pas non plus fait assez d'essais loggués pour extraire des résultats vraiment précis et surtout, je n'ai pas cherché à caler un petit gperftools derrière tout ça :)
Pour le fun, le même truc codé en C:
* tty, sans SSH: ~0.95s
* tty, via SSH: ~0.005s
* urxvt, sans SSH: ~0.004s
* urxvt, via SSH: ~0.005s
Le ratio change radicalement de catégorie ici (x200?) et l'impact de SSH est négligeable (en fait, je pense que la commande time n'est pas assez précise, il faudrait que j'augmente le nombre d'itérations…).
J'ai envie de dire que ça conforte mon idée: dans le cas des terminaux virtuels, il est probable que les données ne soient envoyées à l'écran qu'avec une certaine fréquence, contrairement au TTY qui doit envoyer dès que la donnée est disponible.
Mais c'est amusant de voir l'écart de performances entre PTS et TTY du coup… je pense que je vais me bricoler un petit bout de code pour coller direct mes shells TTY dans des PTS du coup.
PS: désolé de pas pouvoir aider plus sur la question…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: accélération et divers contrôles de framerate?
Posté par Eh_Dis_Mwan . Évalué à 1.
Comment expliquer que le comportement soit différent sous freeBSD ? Je vais regarder ça
[^] # Re: accélération et divers contrôles de framerate?
Posté par freem . Évalué à 4.
Si c'était le cas, le problème se produirait également avec l'usage de SSH sur un TTY, hors ce n'est pas le cas… Accessoirement,
sttydans urxvt me donne la même vitesse.Et puis, 4.6Kio/s, ça me paraît largement assez pour afficher quelques nombres. J'essaierai ce soir de changer le baudrate pour voir, mais je doute que ça change quoique ce soit.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 06 février 2019 à 15:51.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: accélération et divers contrôles de framerate?
Posté par freem . Évalué à 2. Dernière modification le 06 février 2019 à 18:48.
Oui, mais si la limitation provenait des TTY, alors SSH au-dessus du TTY serait malgré tout limité par l'affichage lui-même, contrairement à une éventuelle accélération produite par les modes graphiques.
[^] # Re: accélération et divers contrôles de framerate?
Posté par gUI (Mastodon) . Évalué à 4.
peut-être un coup de strace dans les différents cas permettrait quelques éclairages ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Framebuffer
Posté par Arthur Accroc . Évalué à 2.
Je soupçonne le mode graphique des consoles texte Linux, dit « framebuffer ».
Quand il a été développé, l’utilisation courante de Linux était plutôt avec X11. Donc la performance n’a sûrement pas été une priorité par rapport à la simplicité, pour la compatibilité (ça doit fonctionner même avec un chip graphique non supporté, en mode VESA), la robustesse, le temps de développement…
À ce qu’il me semble, les *BSD utilisent toujours le mode texte des cartes graphiques pour leurs consoles, ce qui explique la rapidité.
Sous Linux aussi, il était bien plus rapide (au prix d’un affichage plus grossier avec assez peu de colonnes et de lignes de caractères).
Il a longtemps été possible de l’utiliser en ajoutant par exemple vga=80x25 aux paramètres du noyau Linux dans le gestionnaire de démarrage, mais je ne sais pas si ça l’est encore maintenant, à moins de ne pas utiliser X : les consoles sont plus étroitement liées au pilote graphique utilisé pour X.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.