J'en avais déjà parlé dans les commentaires de la dépêche de l'an dernier, SamWang a mis un lien vers mes réponses de l'époque dans un de ses commentaires.
Ce n'est pas évident de corréler mon ressenti avec des explications concrètes sur ce qu'il se passe vraiment (surtout sur les systèmes Linux et Windows, que je connaît moins bien).
Dans les faits, si on fait un benchmark, on verra que dans la plupart des cas, Haiku met plus de temps à faire les choses. Cela s'explique par plusieurs raisons, dont les plus évidentes:
- L'utilisation de gcc2 là où un compilateur plus récent optimiserait mieux (sauf sur la version 64bits de Haiku, qui utilise un compilateur à jour),
- Le fait que l'on privilégie la lisibilité et la clarté du code, sans forcément pousser très loin la recherche de performance (on a pas les mêmes besoins qu'un Linux qui doit gérer des serveurs avec plusieurs milliers d'utilisateurs connectés, et on a pas assez de développeurs pour faire ce genre de choses non plus)
- Le fait que les versions actuellement diffusées de Haiku ont un noyau en mode "paranoïaque", c'est à dire qu'il effectue des opérations coûteuses pour simplifier le débugage (par exemple, effacer la mémoire avant de la libérer pour avoir plus de chances de détecter un accès après libération).
Mais malgré tout, à l'utilisation, Haiku réagit toujours immédiatement quand on clique sur un bouton, et ce même sur les machines les plus modestes (on a encore quelques utilisateurs avec des CPUs dépassant péniblement les 400MHz).
La raison tient principalement à la conception de l'API de Haiku, dans laquelle chaque fenêtre affichée à l'écran possède deux threads dédiés (un dans l'application, un dans le serveur graphique) et indépendants du thread principal de l'application. Avec ce modèle, une fenêtre n'est jamais bloquée en attente d'un quelconque évènement, et elle réagit toujours quand on la manipule. Même si c'est pour afficher une barre de progression et dire que le traitement en cours va prendre un moment.
Aussi bien sous Linux que sous Windows, j'ai en permanence un indicateur de la charge CPU et de l'activité du disque dur. C'est souvent le seul moyen que j'ai de savoir que l'ordinateur est en train de réfléchir, après avoir appuyé sur un bouton. À force d'utiliser Haiku, j'ai peu de tolérance aux applications qui mettent plus d'une seconde à se lancer, par exemple.
J'ai pourtant essayé d'alléger mon Linux autant que possible. J'utilise IceWM, un environnement de bureau très peu gourmand avec aucun service en arrière plan. Cependant j'ai toujours l'impression de devoir attendre que l'ordinateur réagisse dès que je fais quelque chose.
Voilà, je n'ai qu'un ressenti et quelques pistes pour tenter de l'expliquer. Et je préfère investir mon temps à rendre Haiku encore plus rapide qu'à essayer de comprendre pourquoi les autres sont à la traîne.
[^] # Re: Réécrire l'histoire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
J'en avais déjà parlé dans les commentaires de la dépêche de l'an dernier, SamWang a mis un lien vers mes réponses de l'époque dans un de ses commentaires.
Ce n'est pas évident de corréler mon ressenti avec des explications concrètes sur ce qu'il se passe vraiment (surtout sur les systèmes Linux et Windows, que je connaît moins bien).
Dans les faits, si on fait un benchmark, on verra que dans la plupart des cas, Haiku met plus de temps à faire les choses. Cela s'explique par plusieurs raisons, dont les plus évidentes:
- L'utilisation de gcc2 là où un compilateur plus récent optimiserait mieux (sauf sur la version 64bits de Haiku, qui utilise un compilateur à jour),
- Le fait que l'on privilégie la lisibilité et la clarté du code, sans forcément pousser très loin la recherche de performance (on a pas les mêmes besoins qu'un Linux qui doit gérer des serveurs avec plusieurs milliers d'utilisateurs connectés, et on a pas assez de développeurs pour faire ce genre de choses non plus)
- Le fait que les versions actuellement diffusées de Haiku ont un noyau en mode "paranoïaque", c'est à dire qu'il effectue des opérations coûteuses pour simplifier le débugage (par exemple, effacer la mémoire avant de la libérer pour avoir plus de chances de détecter un accès après libération).
Mais malgré tout, à l'utilisation, Haiku réagit toujours immédiatement quand on clique sur un bouton, et ce même sur les machines les plus modestes (on a encore quelques utilisateurs avec des CPUs dépassant péniblement les 400MHz).
La raison tient principalement à la conception de l'API de Haiku, dans laquelle chaque fenêtre affichée à l'écran possède deux threads dédiés (un dans l'application, un dans le serveur graphique) et indépendants du thread principal de l'application. Avec ce modèle, une fenêtre n'est jamais bloquée en attente d'un quelconque évènement, et elle réagit toujours quand on la manipule. Même si c'est pour afficher une barre de progression et dire que le traitement en cours va prendre un moment.
Aussi bien sous Linux que sous Windows, j'ai en permanence un indicateur de la charge CPU et de l'activité du disque dur. C'est souvent le seul moyen que j'ai de savoir que l'ordinateur est en train de réfléchir, après avoir appuyé sur un bouton. À force d'utiliser Haiku, j'ai peu de tolérance aux applications qui mettent plus d'une seconde à se lancer, par exemple.
J'ai pourtant essayé d'alléger mon Linux autant que possible. J'utilise IceWM, un environnement de bureau très peu gourmand avec aucun service en arrière plan. Cependant j'ai toujours l'impression de devoir attendre que l'ordinateur réagisse dès que je fais quelque chose.
Voilà, je n'ai qu'un ressenti et quelques pistes pour tenter de l'expliquer. Et je préfère investir mon temps à rendre Haiku encore plus rapide qu'à essayer de comprendre pourquoi les autres sont à la traîne.