Qualité du code de LO et AOO

[pierre_c]

Bonjour, allez, j'y vais de ma question pour Paul et Mickey

Je sais bien que je ne suis pas sur un forum en contact avec les développeurs de deux suites, mais il y a tout de même des spécialistes ici.

Tout d'abord, j'aime ma suite libre, elle fait globalement très bien ce que j'attends d'elle. Mais, j'ai remarqué, en utilisant parfois la concurrence payante des différences significatives en terme de performances. Sur deux points en particulier :
- La réactivité de l'affichage, sa fluidité et le calcul un peu lourd sur le tableur.

Je me suis dit peut-être à tort que la qualité du code de la suite libre n'était pas bonne. Ou pour être plus précis que le code n'avait pas pu suivre les évolutions du matériel, c'est à dire, des cartes graphiques plus puissantes, les multicœurs, l'exploitation de ressources mémoires importante.
Ce n'est donc pas réellement un code de mauvaise qualité, mais un code qui n'a pas évolué au même rythme que le matériel. Probablement par manque de moyen et non par manque de compétences.

Suis-je plus ou moins dans le vrai, ou est-ce que j'ai tout faux

Pierre

[Churay]

waoooow le troll....

- La réactivité de l'affichage, sa fluidité et le calcul un peu lourd sur le tableur.

Ah ?

Je me suis dit peut-être à tort que la qualité du code de la suite libre n'était pas bonne.

L'idéal serait plutôt de se palucher le code source : un gros dépoussiérage a été réalisé, mais il reste des trucs à virer ou à réécrire.

Ce n'est donc pas réellement un code de mauvaise qualité

Ouf... je suis rassuré...

Probablement par manque de moyen

Si l'on regarde les stats du wiki du projet LO on dénombre en gros 350 contributeurs.
Pour AOO, je trouve une petite centaine de commits venant de 4 contributeurs (sur +/- un an)

et non par manque de compétences

re ouf... : la communauté a de vrais hackers

[pierre_c]

Merci pour cette contribution remarquable Churay.

Sur mon PC sous Windows, il n'y a pas photo entre la fluidité de M$ et LO. Peut-être que d'autres personnes sous d'autres OS ont des avis différents. Je conviens que c'est très subjectif. Ou bien peut-être est-il sacrilège de le faire remarquer

Je peux me tromper, mais j'imagine que pour faire fonctionner un logiciel utilisant les multiples cœurs maintenant disponibles, il faut le préparer à cela. Est-ce que ce travail a été fait, et en cours, où est inutile car ce sont les compilateurs qui le font ?

je ne vois pas très bien en quoi ma question est grotesque, à moins que le simple fait de sous-entendre que le Code de LO/AOO ne soit pas parfait sois intrinsèquement grotesque.

Si on ne peut que reconnaitre ici la qualité de l'aide apportée, la générosité des bénévoles qui assurent un support, j'ai toujours eu du mal avec le ton condescendant employé

Je me souviens d'un sujet ou je faisais remarquer qu'il était grotesque de garder des options par défaut (quantité de mémoire cache pour les graphiques) qui ne correspondait plus avec la réalité du parc informatique. On m'a répondu qu'il fallait aussi penser à ceux qui avaient une petite configuration. Ce à quoi j'ai répondu qu'on pouvait leur dire ramener cette valeur à un seuil plus bas, mais d'avoir le réglage par défaut qui concerne le plus d'utilisateurs.

Plusieurs années plus tard, ce paramètre reste inchangé (vous n'y êtes pour rien... quoique) les capacités mémoires des utilisateurs sont encore plus grandes, et sur un autre fil, je vois que la première chose à faire est de mettre ce paramètre au maximum. Et je crois que ce sont les mêmes qui écrivaient dans les deux fils

L'idéal serait plutôt de se palucher le code source : un gros dépoussiérage a été réalisé, mais il reste des trucs à virer ou à réécrire.

Je vois bien que beaucoup de travail est fait sur la qualité du code. En particulier avec les outils d'analyse statique de ce code, je peux me tromper, mais je ne crois pas que ces outils permettent un réorganisation du code pour créer des taches indépendantes, les affecter à des ressources différentes.

Cela me parait être un travail très lourd si le code n'a pas été prévu au début pour cela.

Il n'y a pas de vision, de communication sur le devenir de la suite sur le fond, ou alors, je ne l'ai pas trouvé. On voit bien ce qui est fait à chaque version (cf les notes "under the hood" des versions de LO). Il y a bien eu quelques communications à la création de LO mais je crois bien que c’était justement de la com

Si l'on regarde les stats du wiki du projet LO on dénombre en gros 350 contributeurs.
Pour AOO, je trouve une petite centaine de commits venant de 4 contributeurs (sur +/- un an)

350 contributeurs, c'est très impressionnant dans l'absolu, mais en vrai, ça fait combien e développeurs équivalents à temps plein ? 20 ? 50 ? 100 ? 350 ?

Et depuis combien de temps ?

Combien de temps à mis M$ pour faire évoluer son code qui lui aussi n'était pas prévu pour le multithread ? Avec combien de développeurs. Est-ce une tâche gigantesque ? Inutile ?

[bm92]

Bonjour,

Si l'on regarde les stats du wiki du projet LO on dénombre en gros 350 contributeurs.
Pour AOO, je trouve une petite centaine de commits venant de 4 contributeurs (sur +/- un an)

350 contributeurs, c'est très impressionnant dans l'absolu, mais en vrai, ça fait combien e développeurs équivalents à temps plein ? 20 ? 50 ? 100 ? 350 ?

Et depuis combien de temps ?

Depuis l'abandon de l'encadrement du projet par Sun, l'essentiel de la différence est là : d'un côté une entreprise avec des moyens énormes, qui peut payer à temps plein de nombreux développeurs et les amener à collaborer dans des projets décidés par la Direction; de l'autre côté des volontaires à temps partiel, non payés, qui font essentiellement ce qui les intéressent, et peuvent s'arrêter du jour au lendemain.

Autre aspect : OpenOffice est une application fonctionnant sur divers systèmes d'exploitation, alors que MS-Office fonctionne essentiellement sur un système d'exploitation produit par la même maison. Ça simplifie.

Sur mon PC sous Windows, il n'y a pas photo entre la fluidité de M$ et LO. Peut-être que d'autres personnes sous d'autres OS ont des avis différents. Je conviens que c'est très subjectif.

Je suis sûrement le seul à ne pas observer de lenteur gênante dans mon utilisation d'OpenOffice sous Windows.
Il est vrai que je ne fais pas des usines à gaz avec Calc ou des présentations Impress pleines de photos.

[gerard24]

Bonjour,

Autre aspect : OpenOffice est une application fonctionnant sur divers systèmes d'exploitation, alors que MS-Office fonctionne essentiellement sur un système d'exploitation produit par la même maison. Ça simplifie.

C'est, je pense, la principale raison.
Gérer l'affichage à la fois sous Win, Mac et les différentes versions Linux (GTK.. etc) rend forcément le code plus lourd.

[OlivierR]

Bonjour,

Le mode de rendu de l’affichage est en cours de refonte chez LO. Pas mal de patchs sur ce point ces derniers temps. Ça devrait arriver avec la 5.0.2 ou 5.0.3, s’ils n’ont pas trop de retard.
https://linuxfr.org/news/libreoffice-5-0-sous-le-capot

Sinon, oui, il a été dit plusieurs fois que VCL, le toolkit graphique de OO/LO, est extrêmement vieux et a besoin d’être mis à jour, ce qui arrive, semble-t-il, enfin. On verra peut-être une différence prochainement.

[pierre_c]

Depuis l'abandon de l'encadrement du projet par Sun, l'essentiel de la différence est là : d'un côté une entreprise avec des moyens énormes, qui peut payer à temps plein de nombreux développeurs et les amener à collaborer dans des projets décidés par la Direction; de l'autre côté des volontaires à temps partiel, non payés, qui font essentiellement ce qui les intéressent, et peuvent s'arrêter du jour au lendemain.

je trouve cela fascinant de voir un ensemble hétérogène de personnes travaillant autour d'un code complexe, pour faire évoluer la suite, et tout cela sans trop d'accros. Ça fonctionne plutôt bien.

Autre aspect : OpenOffice est une application fonctionnant sur divers systèmes d'exploitation, alors que MS Office fonctionne essentiellement sur un système d'exploitation produit par la même maison. Ça simplifie.

Oui, mais tous les appareils gèrent les multiprocesseurs maintenant, peut être que les façons de l'implémenter sont très différentes d'un OS à l'autre ? Cela limite sans doute, niveau auquel on peut se rapprocher du matériel, mais la gestion des taches parallèles me semble être plutôt de l'ordre de l'organisation du code que du type de matériel

Code : Tout sélectionner

Le mode de rendu de l’affichage est en cours de refonte chez LO. Pas mal de patchs sur ce point ces derniers temps. Ça devrait arriver avec la 5.0.2 ou 5.0.3, s’ils n’ont pas trop de retard.

Oui, j'ai vu cela, je n'ai pas remarqué de différences sensibles avec la 5.0.2.2. Si j'ai bien compris, OpenGL est un ensemble de fonctions graphiques, qui permettent d'utiliser les ressources du GPU. Cet ensemble est disponible, sous Linux, MS Windows et Androïde. Il est probablement moins performant que DirectX sous Windows, mais bien plus performant que de se passer du GPU. Un travail a aussi été fait avec OpenCL. Je n'ai pas très bien compris si OpenCL utilisait les possibilités de calcul des GPU exclusivement ou s'il pouvait aussi exploiter les multiples cœurs des processeurs actuels.

En fait ma question reste. J'imagine que le code hérité d'OpenOffice était linéaire et non parallèle. Passer de l'un à l'autre. C'est simple ? Sans intérêt pour ce type de logiciel ? Extrêmement complexe et demande une grosse réécriture de l'ensemble du code et donc ça n'arrivera jamais pour AOO/LO ? C'est en cours, mais ça prendra des années...

Le problème de LO (si on peut parler de problème, ce n'est pas le terme approprié) c'est que les évolutions se font petit à petit. Or comme on s’habitue rapidement à une meilleure réactivité lorsque l'évolution est progressive, il est difficile de la sentir. D'autant qu'en 5 ans de LO, ma machine a évolué en puissance elle aussi. Il faudrait se remettre sur une version 3.3 pendant 6 moins et passer à la dernière version.

[Churay]

Yeap

Je peux me tromper, mais j'imagine que pour faire fonctionner un logiciel utilisant les multiples cœurs maintenant disponibles, il faut le préparer à cela. Est-ce que ce travail a été fait, et en cours, où est inutile car ce sont les compilateurs qui le font ?

Cela relève avant tout de l'ordonnancement et de la gestion des caches, donc cela relève au départ de l'OS. Avec les multi-cores, les OS (la plupart) offrent deux options de configuration : espace mémoire unique partagé par tous les coeurs ou espace mémoire réservé pour chaque coeur.
Le soucis est que la tendance actuelle va vers 1 cœur = 1 processeur séparé (qui partage ou non un espace mémoire). Or, ce choix empêche par exemple le partage d’informations entre les caches des cœurs : ce qui induit forcément une non-utilisation des possibilités offertes.

Par ailleurs, si on veut tirer profit (dans le codage) des multi-coeurs, il faut penser parallélisme : donc se poser la question tel algo est-il parallélisable ? et, si oui, est-ce que la parallélisation va vraiment optimiser le schmilblick ?
Dans une galaxie de type AOO|LO, tout (AMHA) n'est pas parallélisable, un programme comme Gimps (Great Internet Mersenne Prime Search)) conçu dès le départ pour un calcul distribué, donc massivement parallèle, gère bien le multi-core.

Enfin, pour une gestion fine des coeurs sous Windows, il peut-être judicieux de remplacer le gestionnaire des tâches de windows par Bill2's Process Manager.

[OlivierR]

J’ai lu, je ne sais plus où (j’espère ne pas me tromper), que le nouveau moteur graphique n’allait pas être utilisé d’un seul coup par toutes les fenêtres et dialogues, mais que ça allait arriver progressivement aussi. Ce n’est pas parce qu’il y a un nouveau moteur que l’existant s’en sert partout.

Je me demande si LO/OO ne gagnerait pas à utiliser un moteur de rendu graphique comme Gecko ou Webkit (pour le rendu des pages uniquement). Ils semblent clairement plus rapides et ils permettent (via CSS) de faire des choses impossibles à faire avec Writer, comme des ombres multiples avec dégradés autour des caractères.

Je ne pense pas qu’il y ait tant de choses parallélisables dans LO/OO, hormis ce qui tourne toujours en tâche de fond quoi que vous fassiez, comme la correction orthographique et grammaticale.

[Vulcain]

Bonjour,

Personnellement, je trouve que la version 5 de LibreOffice en 64 bits apporte un vrai plus en réactivité. J'ai pas eu le temps de tester sous d'autres OS.

Oui, j'ai vu cela, je n'ai pas remarqué de différences sensibles avec la 5.0.2.2. Si j'ai bien compris, OpenGL est un ensemble de fonctions graphiques, qui permettent d'utiliser les ressources du GPU. Cet ensemble est disponible, sous Linux, MS Windows et Androïde.

OpenGL existe aussi sous Mac OS mais Apple est en retard sur la version d'OpenGL et les drivers OpenGL sous Windows sont de moindre qualité que les drivers DirectX.

[pierre_c]

Bonjour,
Personnellement, je trouve que la version 5 de LibreOffice en 64 bits apporte un vrai plus en réactivité. J'ai pas eu le temps de tester sous d'autres OS.

Bof, je n'ai pas remarqué de différence sensible. Il faut dire que j'ai une machine puissante maintenant, je ne me rends probablement pas compte des gains apportés.

J'ai refait des tests de que j'avais fait il y a quelques années en comparant LO et MSO. Simplement en faisant défiler une feuille de calcul avec plein de calculs et de courbes diverses. ça mettait le processeur à plat, et il y a avait des gels d'écran avec LO, alors que le même fichier, sous MSO restait très fluide. Aujourd'hui avec LO 5, il n'y a pas de gel d'écran, et le processeur garde de la marge.

J'ai aussi remarqué que si je lançais writer et calc, il semble que ce soit le même cœur qui est sollicité, mais si j'ai bien compris Churay, c'est plutôt à mettre sur le dos de l'OS.

[pierre_c]

Je viens de regarder cela :

http://people.gnome.org/~michael/data/2 ... labora.pdf

Threaded ZIP export
Threaded image scaling

Ce à quoi on ajoute le support d'OpenCL et OpenGL

On peut donc dire, oui, c'est en cours, progressivement, le code est adapté aux processeurs actuels

Désolé pour le trollage Churay

[pierre_c]

Pour compléter plus précisément mon propos sur les lenteurs observées d'OpenOffice/LibreOffice

Dans l'éditeur d'équation, la zone de texte est particulièrement peu réactive. Si on veut se déplacer dans ses formules avec le curseur, c'est très lent

Dans Impress, quand on ordonne des animations personnalisées, qu'on en monte une ou en descend une, c'est très lent aussi

La réactivité des suggestions d'orthographe est parfois aussi très longue (ça dépend des mots mal orthographiés)

Merci d'arrêter votre monologue.
Si vous devez ajouter un complément d'information, le bouton "Editer" à la droite du message permet d'y remédier.