Openoffice.org 1.1 RC3

Posté par  . Modéré par Mouns.
Étiquettes :
0
18
août
2003
Bureautique
Depuis le 14 août, OOo RC3 est disponible au téléchargement. C'est la fin de la ligne droite pour cette nouvelle version qui apporte de réels progrès comme : l'export pdf et flash, l'utilisation "sans souris", l'écriture verticale, l'enregistrement des macros, et bien sûr MS Office compatibility enhancements et "The splash screen now has a progress bar". 1.1 RC3 disponible en version fr !

Aller plus loin

  • # Re: Openoffice.org RC3

    Posté par  . Évalué à 5.

    /progrets/progrès/
  • # Re: Openoffice.org RC3

    Posté par  . Évalué à 5.

    Les réels progrès existaient déjà dans OOo RC1 non ? Ils étaient renseignés dans cette dépèche : http://linuxfr.org/2003/07/16/13280.html(...)

    Quelles sont les réels ajouts de OOo RC3 ?
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 6.

      RC pour Release Candidate : aucun ajout de fonctionnalité n'est fait entre les différentes RC.
      C'est essentiellement de la correction de bogues.
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 2.

      je pense qu'il voulait dire que les réels progrès sont dans la version 1.1, et que la RC3 est la fin de la ligne droite pour cette version
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 1.

      Il ne dit pas par rapport aux RCs entre elles mais plutôt par rapport à la précédente version stable.
      • [^] # Re: Openoffice.org RC3

        Posté par  . Évalué à -1.

        Ben oui, c'est ça que je dit !

        Je note quand même que la version française est disponible, et que l'export pdf peut se faire en 3 qualités différentes choses qui (mais je ne suis pas sur) ne pouvaient pas se faire avec la RC1.
  • # Re: Openoffice.org RC3

    Posté par  (site Web personnel) . Évalué à 2.

    Etes vous sur que la RC3 soit en français ? Parce que je ne la trouve pas... ce que je trouve ce sont des mirroirs en france... nuance !

    En général, l'équipe de traduction a un peu de retard (ce sont des perfectionnistes et je ne saurais que trop saluer leur excellent travail !)

    Axel
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 3.

      Oui, oui, je l'ai depuis la fin de la semaine dernière. Il faut regarder dans le rep contrib:
      Exemple:
      http://ftp.club-internet.fr/pub/OpenOffice/contrib/rc/1.1rc3/(...)
      • [^] # Re: Openoffice.org RC3

        Posté par  . Évalué à 2.

        trop kool !
        tank U !!

        je m'interroge, quelle va être l'excuse des administartions françaises pour garder MSOffice ?

        nous le sauront au prochain épisode.....

        (ça m'énerve de savoir qu'une partie des impôts vont dans la poche à billou)

        moinssez ! moinssez ! c'est l'époque de la moisson !!
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 2.

          heu... la moisson est finie depuis au moins 3 semaines !
          Ah ces citadins coupés de leurs racines ...
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à 4.

            <blockquote>Ah ces citadins coupés de leurs racines ...</blockquote>
            Bein forcement qu'il sont coupés de leurs racines si ils ont été moissonés y'a trois semaines.

            ...
            ....
            ->[]
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à 4.

            A leur décharge, elles ont eu lieu plus tôt cette année à cause de l'ensoleillement et de la sécheresse... Et en ville, on a beau essayer de se tenir au courant en consultant un calendrier...
            Pour ma part, j'habite à côté d'un silo à grain... Je peux dire exactement les jours de moisson... C'est quand je peux dormir de 4 à 6 h du mat avec des boules quiès :-)
            • [^] # Re: Openoffice.org RC3

              Posté par  (site Web personnel) . Évalué à 1.

              « C'est quand je peux dormir de 4 à 6 h du mat avec des boules quiès :-) »

              Manque pas une négation ou un "seulement" dedans ? sinon avec un tel raisonement demain est potentiellement un jour de moisson.
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à -1.

            Pétainiste !
          • [^] # Re: Openoffice.org RC3

            Posté par  . Évalué à 1.

            bah ! je ne peux pas être agriculteur et élever du pingu...
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 2.

          L'administration française utilise de plus en plus OO en remplacement de MS-Office (exemple : Bercy ).

          Le problème (ou "l'excuse" selon ta terminologie), c'est la compatibilité des documents existants au format MS avec OO.

          Parce que même si 99% des documents MS ne posent pas de problème de récupération sous OO, je te laisse imaginer la masse que représente les 1% restant dans une administration comme Bercy...
          • [^] # Re: Openoffice.org RC3

            Posté par  . Évalué à 1.

            Bercy ? tu peux me donner quelques preuves ?
            car pour moi Bercy --> DREE et donc full microsoft (et je sais de koi je parles, je suis en plein dedan)

            donc une preuve m'aiderais dans mon lobbying pro-linux.
            • [^] # Re: Openoffice.org RC3

              Posté par  . Évalué à 1.

              non, non.. je t'assure que Bercy change petit à petit....
              OOo à la DGDDI c'est en cours. (cf mon post plus bas).

              Des formations seront même assurée aux nouvelles promos d'agents....
            • [^] # Re: Openoffice.org RC3

              Posté par  . Évalué à 1.

              Ma «preuve» est le témoignage direct d'un des responsables informatique.

              Depuis 6-8 mois à peu près, il se passe des choses «souterraines» dans l'administration. Quand je dis souterraines, je veux dire qu'ils mette de plus en plus de libre (suite à des instructions qui viennent «d'en haut»), mais aucune publicité n'est faite là dessus. J'ai même entendu parler de cas où ils continuaient à payer les licences microsoft. Je n'ai pas vraiment de certitudes, c'est soit par incompétence (c'est possible) voire comme le prétendent d'autre «pour pas que cela se sache».

              On pourrait croire que l'administration essaye en catimini d'atteindre une masse critique avant de frapper fort. C'est une supposition de ma part, mais quelques témoignages directs que j'ai reçus me le font croire.

              Un exemple : Bull présentait à la Linux Expo des solutions «clef en main» de serveur sous linux avec Apache, PHP, MySQL, Sendmail, SPIP etc.
              Les gars de Bull avec qui j'ai discutait m'ont dit que ces produits avait été créés afin de répondre à des directives ministérielles adressées à des administrations...
          • [^] # Re: Openoffice.org RC3

            Posté par  . Évalué à 1.

            Je suis pour OOo mais je suis surtout pour qu'un export de fichier excel ne me crée pas une surtaxation par erreur... à cause d'un signe ou d'un chiffre transcrit de travers... :o)

            Donc, c'est pas forcemment aux impôts que j'aurai installé OOo en premier lieu...
        • [^] # Re: Openoffice.org RC3

          Posté par  (site Web personnel) . Évalué à 3.

          [TROLL class="droite"]
          Fais bouger un fonctionnaire de la bureaucratie pour voir... ah ben oui, en dehors d'une manif.
          [TROLL]

          Dites, M. Raffarin, on gagnerait combien à mettre dix chercheurs à plein temps sur OOo et résilier toutes les licences Windows/MSOffice de la fnction publique ?
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à 3.

            Rétablissons l'équilibre (ou rajoutons un appel au troll, c'est selon).

            <blockquote>Dites, M. Raffarin, on gagnerait combien à mettre dix chercheurs à plein temps sur OOo et résilier toutes les licences Windows/MSOffice de la fnction publique ?</blockquote>

            [TROLL class="gauche"]
            Trop cher: la peuve, les budgets de la recherche et de l'éducation ont été sacrifiés sur l'autel de la démago sécuritaire.

            Ceci dit, c'est clair qu'il est plus facile de faire bouger un élu de droite qu'un fonctionaire : il suffit de lui graisser la patte (t'as entendu parler des appels d'offres de la mairie de Paris?).
            [TROLL]
          • [^] # Re: Openoffice.org RC3

            Posté par  . Évalué à 1.

            lol c'est pas une question de temps mais une question d'argent. "Si c'est gratuit c'est pas bon, si c'est trés cher alors c'est trés bon."
            Question de crédibilité par rapport aux décideurs à la mentalité étriquée et à l'égo surdimensionné.
            Pfff ca m'enerve !
            • [^] # Re: Openoffice.org RC3

              Posté par  . Évalué à 1.

              Et donc :

              Plus je suis payé, plus je suis efficace. Donc je suis trés efficace... ( se dit le decideur...)

              Donc 80% des français sont vraiment inefficaces... :o(
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 1.

          en cours de migration pour la douane selon des sources fiables.
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 3.

          Pour travailler depuis peu dans une mairie, je peux te dire que rien ne fait plus peur aux fonctionnaires que de changer d'habitudes (d'ailleurs, pour extrapoler, je comprends mieux les manifs à chaque fois qu'un gouvernement veut changer quelque chose....).

          Par contre, je reste persuadé qu'avec un bon travail de communication auprès des gens, on peut changer les choses. Par exemple, j'ai commencé par donner le choix aux utilisateurs entre MS Office et OO.o, et bien j'ai été surpris de voir que certains à qui j'avais bien expliqué la différence entre le format propriétaire et un format libre utilisaient déjà OO.o quand il le pouvait.

          2ème exemple, la personne qui s'occupe des ressources humaines m'avait demandé un logiciel pour gérer les heures du personnel. N'ayant pas trop de temps à accorder à ce type de demande, j'ai commencé par essayer de bricoler une feuille sous excel, "pour lui simplifier la vie...". En fait, j'ai jamais pu avoir des additions d'heures correctes sous excel (quand je dépsassait 24:00, j'obtenais 02/01/1900 00:00 ..). J'ai donc recommencé sous le spreadsheet de OO.o, et comme ca marche, ma RH fonctionne sous OO.o !

          Et de fil en aiguille, sans vouloir forcer les gens à tout de suite passer à linux, on fait progresser le schmilblick.....

          Et prime, je me suis renseigné auprés du fournisseur de la suite de logiciels compta, paie, facturation, etc..., et on m'a assuré que ca fonctionnait sous linux (non, je ne donnerais pas de nom !). Donc je pense que d'ici 2 à 3 ans, j'aurais réussi une transition en douceur vers plus de liberté.

          Pour me répeter, et même si c'est difficile voire lassant, je suis persuadé qu'on peut réussir à changer les choses avec un bon travail de communication.
          • [^] # Re: Openoffice.org RC3

            Posté par  . Évalué à 1.

            Et prime, je me suis renseigné auprés du fournisseur de la suite de logiciels compta, paie, facturation, etc..., et on m'a assuré que ca fonctionnait sous linux (non, je ne donnerais pas de nom !).

            Ca serait pas Ciel par hasard? Ca m'arrangerait bien :)
  • # Re: Openoffice.org RC3

    Posté par  (site Web personnel) . Évalué à 3.

    The splash screen now has a progress bar

    \o/ si je ne me trompe même MS-Office n'a pas cette fonctionalité !!
    • [^] # Re: Openoffice.org RC3

      Posté par  (site Web personnel) . Évalué à 4.

      Si : le démarrage de Windows, puisque les bibliothèques de MS Office se chargent à ce moment-là (d'où les lourdeurs ou des réactions très surprenantes comme par exemple chercher un fichier sur disque dur qui requiert une mise à jour d'Office! )
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 1.

      Les bétas de Sun StarOffice 6.1 l'avaient déjà en tout cas
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 1.

      J'aurais prefere qu'ils le suppriment, cette p****n de splash screen. S'ils veulent en ajouter un, que ce ne soit pas par defaut, parce que la, faut le chercher pour le supprimer. Du coup, par defaut sur un 233, tu ne peux pas utiliser ton ordinateur pendant quasiment 1minute.
      • [^] # Re: Openoffice.org RC3

        Posté par  . Évalué à 1.

        Pour moi, là, le splash screen est en route mais le multitâche est préservé. C'est pas grave. je peut faire autre chose. C'est fou le multitâche.

        (PS: sur 225Mhz!)
      • [^] # Re: Openoffice.org RC3

        Posté par  . Évalué à 2.

        démarre avec -nologo si tu ne veux pas le splash screen.
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # Re: Openoffice.org RC3

    Posté par  . Évalué à 2.

    J'ai vraiment hate que OO soit rapide à demarrer. De mon point de vue, ce sera un des coups de fouet qui fera refléchir les décideurs dans les entreprises.

    Bien que je me serve de OO tout les jours en lieu et place de MS Office, je trouve ce point noir vraiment chiant. Je ne sais pas à quoi cela est dû et si quelqu'un pouvait me l'expliquer ou bien me diriger vers des discussions sur ce sujet, j'en serai reconnaissant.
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 2.

      OO 1.1 est bcp plus rapide à démarrer que 1.0 surtout si tu utilise prelink.

      pourquoi ms office est plus rapide à démarrer ? parce que ms office utilise principalement des librairies dynamiques deja chargées en mémoire par windows. oo quand à lui a ses propre librairies meme d'interface utilisateur.
      • [^] # Re: Openoffice.org RC3

        Posté par  (site Web personnel) . Évalué à 1.

        20 secds avant de voir la progressbar
        50 secds avant qu'OOo soit utilisable

        ca reste long

        (j'ai fait prelink -a avant ... si j'ai bien compris l'utilisation de prelink je l'utilise :/)
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 2.

          J'utilise la 1.1rc2 et calc démarre en 4 secondes et est utilisable de suite.
          Ça me convient et de toute façon, je ne peux pas comparer avec office, j'ai pas vu de machine windown deuis deux ans, même jamais vu XP.

          De plus, je ne remarque pas de différence notable entre les binaires officiels et ceux compilés avec les options aux petits oignons pour ma machine. Mes exécutables sont juste un peu plus gros. Par exemple:
          soffice.bin officiel 385108 bytes
          ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), stripped

          soffice.bin compilé à la maison 393764 bytes
          ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), stripped

          Temps de compilation : 7h15

          Pour les curieux:
          # emerge info
          Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1)
          =================================================================
          System uname: 2.4.20-hardened-r2 i686 AMD Athlon(tm) MP 1900+
          GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo(...) http://www.ibiblio.org/pub/Linux/distributions/gentoo(...)"
          CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config"
          CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d"
          PORTDIR="/usr/portage"
          DISTDIR="/usr/portage/distfiles"
          PKGDIR="/usr/portage/packages"
          PORTAGE_TMPDIR="/var/tmp"
          PORTDIR_OVERLAY=""
          USE="x86 3dnow apm foomaticdb libg++ mad mikmod gdbm berkdb slang arts aalib tcltk guile postgres gpm pam esd gtk motif gphoto2 scanner X alsa apache2 altivec avi bindist bonobo cdr crypt cups curl dga dnd doc dvd encode faad gb gif gnome gnomedb gtk2 gtkhtml imap imlib innodb java jpeg kde lcms libwww maildir mmx mozaccess mozcalendar mozilla mozsvg mozxmlterm mpeg music mysql ncurses nls oggvorbis opengl oss pdflib perl png python qt quicktime readline ruby sdl spell sse ssl tcpd tetex tiff truetype type1 usb wmf wxwindows xml2 xmms xv xvid zlib -mozinterfaceinfo moznoirc moznocompose -svga"
          COMPILER="gcc3"
          CHOST="i686-pc-linux-gnu"
          CFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math -z combreloc -m3dnow -msse -mmmx -frerun-cse-after-loop -frerun-loop-opt -funroll-loops"
          CXXFLAGS="-march=athlon-mp -O3 -pipe -fomit-frame-pointer -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -ffast-math -z combreloc -m3dnow -msse -mmmx -frerun-cse-after-loop -frerun-loop-opt -funroll-loops"
          ACCEPT_KEYWORDS="x86 ~x86"
          MAKEOPTS="-j 6"
          AUTOCLEAN="yes"
          SYNC="rsync://pol/portage"
          FEATURES="sandbox ccache distcc"
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à 2.

            A mon avis, pour la taille, c'est plutôt un "du -S /opt/OpenOffice.org1.0.3/program/" qu'il faudrait faire (132 591 ko dans mon cas , mon soffice.bin fait 242 572o).
            Et franchement, avec les CFLAGS de tueur que t'as, plus KDE et des logiciels de bureautique ça sert pas à grand chose d'avoir une hardened Gentoo -_^.

            Sinon, j'aurais voulu savoir un truc: est-ce que toi aussi tu as un lien invalide "/opt/OpenOffice.org1.0.3/program/libstdc++.so" ? (je vais faire un joli rapport de bug je crois)
            • [^] # Re: Openoffice.org RC3

              Posté par  . Évalué à 1.

              Pour info:
              132M OpenOffice.org1.1_rc/program
              138M OpenOffice.org1.1RC/program

              Ça fait pas grande différence.
              Je n'ai pas ton problème de lien invalide et je ne l'avais pas avec la version 1.0.3 non plus.

              KDE, je ne l'utilise pas. Je l'essaie de temps en temps au fur et à mesure des sorties, mais je lui préfère gnome2.2 ou xfce4 (les égouts et les couleuvres...)

              Pour ce qui est du kernel, j'avais cru qu'une 2.4.20-hardened était mieux qu'une vanilla et je ne change plus. J'évite les noyaux Gentoo (trop de soucis), le 2.4.21, les 2.5.* et 2.6.* à cause de problèmes USB (mon imprimante Dymo turbowriter disparaît)
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à 2.

            Houla ! le "-ffast-math" pour compiler un programme qui contient beaucoup de lignes de code et qui contient un tableur, ça me fait frémir ! (beaucoup de lignes de code=plus grand risque d'avoir laissé une instruction qui ne digerrera pas les simplifications de fast-math; tableur=usage de fonctions qui risquent de ne pas supporter le fast-math)

            Enfin d'un autre coté, c'est un bon test pour voir si OpenOffice est programmé proprement, avec la ceinture et les bretelles ou si il y a quelques points faibles !
            ;-)

            Mathias
            • [^] # Re: Openoffice.org RC3

              Posté par  (site Web personnel) . Évalué à 2.

              L'ebuild d'OpenOffice (le package Gentoo) ne laisse passer que les flags suivants:
              "-O -O1 -O2 -Os -mcpu -march -pipe"

              D'ailleurs, pour avoir essayé sur une LFS, je peut te dire qu'OpenOffice a tendance à être _très_ récalcitrant au moment de se faire compiler.
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à 1.

            nous n'avons certainement pas la meme machine. 50 secds c bcp trop en production ... Lorsqu'on me demande de tapé une lettre qu'on me dicte et que j'attends ce tps la ... le collegue s'impatiente :/

            abiword est donc mon ami ... et ca fait pas de la bonne pub pour OOo
        • [^] # Re: Openoffice.org RC3

          Posté par  (site Web personnel) . Évalué à 1.

          Pour le prelink fait gaffe: par défaut les fichiers de config de Gentoo contiennent pas Oo. Pour ce qui est des distribs binaires, je sais pas si la version précompilée d'OpenOffice l'est avec l'option de GCC permettant le prelink.

          Et sinon, la manière conseillée de l'invoquer c'est "prelink -afmR" ("man prelink" pour plus d'info).
      • [^] # Re: Openoffice.org RC3

        Posté par  . Évalué à 4.

        OO meme version version 1.1 reste beaucoup plus long a charger que Abiword !

        Je sais c'est pas la meme chose mais d'un point de vue utilisateur (pas d'un point de vue entreprise), Abiword possede tout ce qu'il faut ou presque pour travailler avec des perf bien meilleures (pour le temps de chargement c'est le jour et la nuit !).

        Les dev de OO sont au courant et vont continuer a travailler dessus pour la prochaine version :

        http://tools.openoffice.org/releases/q-concept.html(...)

        On parle notamment d'un systeme de gestion des polices specifique a OO qui fait doublon avec fontconfig et qui penalise serieusement OO au demarrage.
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 2.

          La compatibilité avec MS Office n'est pas du même niveau entre OOo et Abiword, et ça, c'est vraiment très important pour des gens comme moi qui travaillent dans un environnement où MS Office est la suite officielle. Et avec la version 1.1, je dois dire que je suis comblé, notamment avec ces putains de listes à puce qui ne passaient pas correctement de l'un à l'autre.
          D'autre part, Abiword <=> MS Word, mais il te manque les Excels, Powerpoint,..., surtout sous Windows car je ne crois pas qu'il existe de version Windows de Gnumeric.

          Quand à l'export PDF, c'est un argument suffisant pour que plein de mes collègues installent OOo sur leur poste Windows.

          Moi je dis bravo et merci à l'équipe OOo
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 1.

      C'est peut-être bien le même problème que le temps de démarrage des applications KDE : Le compilateur utilisé.
      • [^] # Re: Openoffice.org RC3

        Posté par  . Évalué à 1.

        quoi, on m'aurait menti gcc n'est pas le meilleur compilo au monde ??
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 2.

          Pas pour le C++ mon fils.
          • [^] # Re: Openoffice.org RC3

            Posté par  . Évalué à 2.

            ICC est bien mieux je crois dans pas mal de cas.
            • [^] # Re: Openoffice.org RC3

              Posté par  . Évalué à 2.

              ça n'a rien à voir puisque ICC est mono-plateforme.
              Dans le même genre, le compilateur d'IBM produit du bien meilleurs code PowerPC que ne le fait GCC. Pourtant les employés d'IBM qui bossent sur le compilateur "maison", participent aussi à l'amélioration du code powerPC produit par GCC, mais de leur propre aveux, la structure multi-plateforme de GCC empêche certaines optimisations poussées.

              GCC est sans doute le meilleur compilateur multi-plateforme.

              Le problème vient du langage. En C++, gcc produit un code peu performant à cause de son système de v-tables (d'où le fameux objprelink ), mais en C gcc produit un binaire tout à fait correct (même si les compilateurs spécifiques à une plateforme conçus par les fondeurs de microprocesseurs sont un peu meilleurs).
              • [^] # Re: Openoffice.org RC3

                Posté par  . Évalué à 2.

                Qyuand je dis que c'est un problème de langage, il faut comprendre un problème qu'a ce compilateur avec ce langage.

                Le problème n'est pas le C++, mais la façon dont GCC le traite.
                • [^] # Re: Openoffice.org RC3

                  Posté par  (site Web personnel) . Évalué à 5.

                  En fait, si, c'est un peu de la faute de C++ aussi. Il est plus difficilement prédictible à cause des bouts de C et d'assembleur qu'il contient (donc plus difficile à analyser) et il possède des spécificités bien compliqués a compiler efficacement. Le dernier point est qu'il hérite des notions des bibliothèques de C qui ne sont pas addaptés aux langages à onjets (l'éditeur de liens et chargeur à beaucoup de travail en plus).

                  À l'époque il fut pensé de façon à optimiser les performances même si cela devait nuire aux concepts objets (les fonctions pas virtuelles par défaut, héritage répété par défaut, types primitifs non objet, contravairance, etc.). Malheureusement de nos jours les techniques ont fait beaucoup de progrès et on a à un résultat inverse : on arrive mieux à prédire un langage qui a un modèle de représentation mieu foutu.
                  OCaml et SmartEiffel génèrent souvent du code bien plus rapide que l'équivalent C++.

                  Mais bon, il ne faut pas confondre langage et compilateur. Des compilos Eiffel qui rââment on en trouve aussi :)
                  • [^] # Re: Openoffice.org RC3

                    Posté par  . Évalué à 1.

                    Des compilos Eiffel qui rââment on en trouve aussi

                    Les deux compilos Eiffel les plus courants, le libre et même GPL SmartEiffel ainsi que le propriétaire EiffelStudio ne rament pas. Les autres (VisualEiffel, Halstenbach), c'est le silence radio...
      • [^] # Re: Openoffice.org RC3

        Posté par  (site Web personnel) . Évalué à 1.

        Weuh... y'a aussi hdparm et prelink qui ont un rôle à jouer.
        Et pis troller c'est mal© de toutes manières.
        • [^] # Re: Openoffice.org RC3

          Posté par  . Évalué à 2.

          Et c'est quoi prelink, ça sert à quoi, pourquoi le compilateur et l'éditeur de lien ne font pas le boulot ? :-)
          • [^] # Re: Openoffice.org RC3

            Posté par  (site Web personnel) . Évalué à 3.

            L'éditeur de lien il fait son boulot, mais il a beaucoup de boulot. Et prelink c'est justement un cache pour ce pauvre petit éditeur surchargé qui en a ras le c*l des applications en c++ (si j'ai bien compris, il s'arrange pour que chaque librairie soit présente à un endroit défini de la mèmoire, de manière à gagner du temps).
            Ça à rien à voir avec le compilo.

            Pour en revenir au compilo, et comme beaucoup l'ont dit: les perfs c'est bien, mais faut voir si c'est stable. Je suis sûr qu'avec les options tueuses de GCC on peut arriver à faire quelque chose du niveau de icc. Personnelement, je ne les emploie pas, parceque la fiablité est plus importante à mes yeux.
            D'ailleurs, il semble que ce qui fasse la réputation de gcc aujourd'hui, c'est la conjugaison de performances satisfaisantes et d'une excelente fiabilité.

            (et puis oo c'est déjà la merde pour lui faire admettre ton désir de le compiler, alors si en plus il faut le faire avec un compilateur non standard...)
            • [^] # Re: Openoffice.org RC3

              Posté par  . Évalué à 1.

              c'est du binding direct en fait ?

              que valent les variables d'env qui influencent le comportement de ld.so ??? (du style LD_BIND_NOW) ?
              • [^] # Re: Openoffice.org RC3

                Posté par  (site Web personnel) . Évalué à 1.

                Si j'ai bien compris, LD_BIND_NOW charge les librairies au démarrage du programe au lieu de le faire quand ce dernier appelle une fonction contenue dans une des librairies.
                À mon humble avis, c'est plutôt un moyen de gaspiller de la RAM qu'autre chose.

                Alors qu'une librairie prelinké, elle, est chargée seulement après qu'on ait essayé de l'utiliser. Mais ensuite (si j'ai bien compris), ld se fait pas chier à la localiser parce qu'elle est à un emplacement predéfini de la mèmoire (cf. la page de manuel).
                • [^] # Re: Openoffice.org RC3

                  Posté par  . Évalué à 8.

                  Non, le problème n'est pas du tout là.

                  Dans ce débat, il faut d'abord admettre un constat qui fait mal : Une application C++ qui utilise QT (par exemple) et compilée avec VC++ sous Windows démarrera beaucoup plus vite que la même appli sous linux compilée avec GCC.

                  Comme c'est pas politiquement correct de dire ça, vous allez être des dizaines à «moinsser» ou a dire «on s'en fout paske ce qui n'est pas libre c'est pas bo» etc. Mais cela ne changera rien au fait qu'un appli C++ sous linux compilée avec GCC ramera au démarrage alors que la même appli compilée avec un autre compilo sur une autre plateforme démarrera aussi vite qu'une appli «pure C».

                  Il y a deux explications à cela :

                  1) Les V-Tables. Ce sont des tables qui permettent de résoudre dynamiquement les appels à des méthodes. En POO ces tables sont nécessaires afin de résoudre lors de l'exécution les appels polymorphes. GCC ne fait pas d'optimisation à ce niveau, du coup le linker dynamique doit créer une entrée dans la table pour chacune des fois où une même méthode est héritée. Si vous avez un objet Ancetre qui a une méthode getInfo(), que cet objet est hérité par 200 autres classes, et bien la V-Table contiendra 200 entrées pour cette méthode même si ladite méthode n'est jamais surchargée par un des descendants.
                  Et donc, contrairement à ce que tu dis, le prelink va non seulement accélerer les choses, mais également économiser de la RAM en évitant toutes ces entrées inutiles.

                  2) Le C++ permettant des résolutions dynamiques, GCC et l'éditeur de liens ne s'emmerdent pas : ils ne résolvent aucun appel. Les symboles seront résolus dynamiquement au démarrage de l'application. (c'est une simplification, mais c'est l'idée générale). Alors que lors de la compilation, il est possible de résoudre l'essentiel des appels aux librairies partagées. Le format de binaires ELF permet en effet de faire un"table d'équivalence" des appels déjà résolus sur une librairie partagée, puisque cette même librairie partagée possède déjà une table de ses symboles. Donc en fait, prelink fait du boulot que l'éditeur de lien (ld) ne veut pas faire... on se demande bien pourquoi.

                  Depuis que le «problème» a été identifié, un certain nombres de choses ont été faites par l'équipe de dev de GCC (depuis la V3), mais on est encore loin du compte. Faut pas leur en vouloir, c'est seulement que quand on fait ce genre de modifs dans un compilo, il est préférable d'avancer prudemment ;-)

                  Pour info, voici ci-dessous l'analyse qu'avait faite WB à l'époque où il s'était penché sur le problème (analyse qui a donné naissance au prelink). Mais comme ça parle de KDE, C++ et surtout que ça ose supposer que le sacro-saint GNU-CC n'est pas l'ultime perfection de la galaxie (42), ce post sera sans aucun doute qualifié de «immonde troll» (ce qui est souvent bien pratique) ;-)

                  Aegir.

                  Making C++ ready for the desktop.
                  =================================

                  Author: Waldo Bastian <bastian@kde.org>
                  Date: May 9, 2001
                  Version: 1.2 (See bottom for change history)

                  In this paper I would like to bring the attention to an important performance
                  bottleneck in the ld.so linker on GNU/Linux systems wrt C++ programs. I will
                  try to offer some suggestions for improvement and hope that this paper will
                  lead to a discussion in the GNU/Linux community that eventually will lead to
                  a solution that addresses this problem.

                  It should also be noted that ld.so currently does a fine job for the things
                  it was designed. The problem is that it wasn't designed for todays Linux
                  Desktop.

                  This paper is based on gcc 2.95, many of the issues described here have been
                  fixed in gcc 3.1.

                  1. The symptoms
                  ===============

                  Starting a KDE application from the command line is slow. Slow is a very
                  subjective term, but when it comes to a graphical user interface, things
                  are typically perceived as slow when there is a latency of more than 0.3 secs.
                  between action and reaction. So if I click on a button, it should bring up a
                  window on my screen within 0.3 secs. If it takes longer, users tend to perceive
                  the system as slow.

                  KDE is slow. Since I am very concerned about KDE I have been looking into the
                  reason why KDE is slow. Obviously there are a number of factors that contribute
                  to the problem. What we are interested in is the startup-performance which I
                  would like to define as the time it takes between the moment the binary image
                  is being executed and the moment the first visual feedback appears on the
                  screen.

                  There are 4 major contributors to the startup-performance in a KDE application.
                  1) Time spent by the linker (ld.so) before main() is called.
                  2) Initialisation of the X server connection and Qt toolkit.
                  3) Overhead by the KDE framework
                  4) Overhead by the application

                  Since the goal is to bring the startup-performance within 0.3 secs, each
                  contributor may spent on average 75ms.

                  I mention 2), 3) and 4) to make clear that the startup-performance is not tied
                  to a single element. However, each of these contributors places a limit on
                  the best achievable performance. I will continue to refer to 2), 3) and 4)
                  wrt performance for reference, but apart from that they are beyond the scope
                  of this paper.

                  As an example I have split up the startup times of the 'kedit' application
                  into 1), 2), 3) and 4), times are measured on a Pentium III running at 500Mhz.
                  All data is assumed to be already in memory so disk access should not play a
                  role.


                  Table1:

                  Activity Time Spent
                  Linking 0.65 sec
                  Qt app. constructor 0.13 sec
                  KDE app. constructor 0.11 sec
                  KEdit specific init 0.48 sec
                  ---------------------------------------------
                  Total 1.37 sec

                  This illustrates that run-time link performance is the major bottleneck when
                  it comes to providing a "fast" desktop environment.

                  2. Run-time linking investigated.
                  =================================

                  The task of the runtime linker is to link an application to the shared libraries
                  it needs. There are several steps involved in this process. These steps involve:

                  1) Finding the shared libraries that are needed
                  2) Loading the shared libraries into the address space of the process.
                  3) Relocating addresses in the library to reflect the location in the address
                  space the library was loaded to.
                  4) Resolving undefined symbols in a library and/or the executable by searching
                  for these symbols in the other libraries.

                  All these steps, with exception of step 3, are optimized. It is step 3 that is
                  causing the problems:

                  1) Finding shared libraries is optimized by means of the /etc/ld.so.cache. The
                  ldconfig utility builds an index of all libraries found in the default library
                  locations and stores this index information in /etc/ld.so.cache. This cache
                  allows the linker to lookup libraries faster than if it had to search the file
                  system itself when looking for a certain library. If a library is not found in
                  the cache, the linker has to search the filesystem anyway.

                  2) Loading of shared libraries is cached by the Linux kernel. Only the first
                  application that needs a certain library needs to actually load the library
                  from disk. Subsequent processes that need the library will make use of the same
                  copy that already resides in memory.

                  This is further optimized by the fact that the Linux kernel only loads parts of
                  the library (on a page by page basis) when these parts are actually used.

                  4) Not all symbols are resolved at startup. Only when a symbol is used it is
                  being resolved. This is called lazy binding. By specifying "LD_BIND_NOW=t"
                  before starting an application, we can instruct the linker not to use lazy
                  binding and to resolve all symbols at startup. The following table shows
                  the results of lazy binding for the startup time of KEdit.

                  Table 2:

                  Lazy Binding Time needed for linking
                  On 0.65 sec
                  Off 1.17 sec

                  Symbol lookup is further optimized by the use of hash tables which makes the
                  lookup of symbols very efficient.

                  Lets now have a closer look at what happens in step 3)

                  Every library that is needed by an application gets loaded to an address that
                  is unique within that process. This address may vary each time the library is
                  loaded. Code that references addresses in the library must be adjusted for the
                  address the library is loaded to, this is called relocation. As mentioned before,
                  libraries are shared between different applications and processes. However,
                  the relocation performed can be different from process to process, as such,
                  those parts of the library that need to be relocated are not shared.

                  Let's now have a look at some numbers. When we compile and link the following
                  very simple application:
                  main(int argc, char *argv[]) { return 0; }
                  we will see that the startup time is determined by the number of libraries
                  this code is linked against. More accurately formulated, the startup time is
                  largely determined by the number of relocations that have to be performed.

                  The number of relocations can be counted by setting "LD_DEBUG=statistics".
                  The number of relocations and the start up time is measured independently
                  in case measuring the number of relocations slows down the relocation process.

                  LD_DEBUG=staticstics only counts the number of relocations that require a symbol
                  lookup.

                  In the following table, the startup time is listed as a function of the
                  libraries linked. Since the libraries depend on each other, each line also
                  implies the libraries listed above it. E.g. all data is cummulative.

                  Table 3:

                  Lazy Binding Bind all on startup
                  Libraries Relocations Time Relocations Time
                  C++ 945 0.01 1754 0.01
                  Qt *) 22176 0.12 32892 0.20
                  DCOP 22407 0.14 33669 0.24
                  kdecore **) 25095 0.20 39911 0.37
                  kdeui 42157 0.34 61586 0.60
                  kio ***) 43739 0.44 64978 0.78
                  kfile ****) 48915 0.60 73848 1.10
                  kspell 49366 0.66 74707 1.22

                  *) implies Xext, X11, SM, ICE, Xft, png, z, jpeg, Xrender
                  **) implies kdefakes, dl
                  ***) implies kdesu, fam
                  ****) implies ksycoca

                  Not only does the relocation take CPU time, it also uses up memory.

                  Table 4:

                  Lazy Binding Bind all on startup
                  Libraries Dirty Pages *) Dirty Pages
                  C++ 28 28
                  Qt 135 135
                  DCOP 137 137
                  kdecore 162 162
                  kdeui 189 189
                  kio 197 197
                  kfile 211 211
                  kspell 213 213

                  *) The last field of /proc//statm. (Linux 2.2.18)

                  Memory usage seems to be mostly caused by the .data sections of the libraries
                  which contain the vtables, and to a lesser extend by the .got section.

                  The following table shows the memory usage split by section. The table lists the 4
                  biggest libraries. Listed as "kedit" is the sum for all libraries (as well as the kedit
                  executable itself)


                  Table 4a:
                  .got .data .bss
                  libqt 44Kb 131Kb 19Kb
                  libkdecore 15Kb 17Kb 7Kb
                  libkdeui 24Kb 76Kb 4Kb
                  libXft 1Kb 5Kb 72Kb
                  kedit 129Kb 308Kb 160Kb


                  The next table shows the number of relocations per relocation type.
                  Relocations in the .got section are of type R_386_JUMP_SLOT and R_386_GLOB_DAT.
                  Relocations in the .data section are of type R_386_32 and R_386_RELATIVE.

                  Relocations of type R_386_32, R_386_JUMP_SLOT, R_386_GLOB require a symbol
                  lookup.
                  Relocations of type R_386_JUMP_SLOT are delayed until needed, unless
                  "LD_BIND_NOW" is specified.


                  Table 4b:

                  R_386_REL R_386_32 R_386_JUMP_SLOT R_386_GLOB_DAT
                  libqt 5124 17090 8515 2688
                  libkdecore 813 1719 3331 499
                  libkdeui 684 15547 4687 1529
                  libXft 2074 46 189 34
                  kedit 21021 43311 25866 7160

                  Since each relocation modifies 4 bytes of memory, so we can tranlate the above number
                  to Kb of memory affected:

                  Table 4c:
                  R_386_REL R_386_32 R_386_JUMP_SLOT R_386_GLOB_DAT
                  libqt 20Kb 67Kb 33Kb 10Kb
                  libkdecore 3Kb 7Kb 13Kb 2Kb
                  libkdeui 3Kb 61Kb 18Kb 6Kb
                  libXft 8Kb 0Kb 1Kb 0Kb
                  kedit 82Kb 169Kb 101Kb 28Kb

                  This shows that on average 100% of the .got section is affected by R_386_JUMP_SLOT
                  and R_386_GLOB_DAT relocations and 81% of the .data section is affected by R_386_REL
                  and R_386_32 relocations.

                  It is interesting to note that multiple R_386_32 entries can point to the same
                  symbol:

                  The following table lists the number of total R_386_32 entries per library as
                  well as the number of unique symbols referenced.

                  Table 4d:

                  R_386_32 Unique Symbols
                  libqt 17090 4377
                  libkdecore 1719 806
                  libkdeui 15547 2518
                  libXft 46 30

                  Caching symbol lookups related to R_386_32 relocations might give considerable savings.


                  Is this a KDE specific problem?
                  ===============================

                  That depends on how you look at it. The problem of long startup times is caused
                  by the linker needing to do many relocations. In the case of KDE, these
                  relocations are for a great deal caused by vtable entries. KDE and Qt make
                  liberal use of virtual functions and inheritance. In general every class that
                  inherits from a base class with virtual functions will need to provide a vtable
                  that covers at least the virtual functions of this base class. It seems that
                  each vtable entry causes a relocation, and worse, a relocation that can not be
                  done lazy.

                  An example:
                  A class 'base' that defines 10 virtual functions will define a vtable for these
                  10 functions. All these functions need to be relocated at startup resulting in
                  10 relocations.

                  When I now define a class "derive" that inherits "base" and that overrides a
                  single virtual function, I will get a second vtable. I now need 20 relocations.

                  Qt is based on two fundamental classes, QObject and QWidget. QObject defines
                  about 8 virtual functions. QWidget about another 80.

                  As a test the following (dummy) class was added to a KDE library, the class
                  overrides an existing virtual function. The class was not used in any way.
                  By adding this class the number of relocations on startup increased with
                  110.

                  class TestClass : public QWidget
                  {
                  public:
                  TestClass() : QWidget() { }
                  virtual void initMetaObject() { QWidget::initMetaObjet(); }
                  };

                  Now it becomes clear why linking kdeui, a library that mostly defines widgets
                  who all inherit from QWidget, introduces 17000 additional relocations.

                  So to come back to the question, is this issue specific for KDE? Maybe.
                  As for a comparison. The GNOME 'gedit' application requires 2043 relocations
                  with lazy binding versus 9755 relocations with complete binding. It seems
                  that this application, written in C, takes more advantage of lazy binding
                  than applications in the KDE framework.

                  The following code was placed into a library as a test case:
                  #include <qwidget.h>

                  template<int T> class testclass : public QWidget
                  {
                  public:
                  virtual void setSizeIncrement(int w, int h) { QWidget::setSizeIncrement(w+T, h+T); }
                  };

                  template class testclass<1>;
                  ...
                  template class testclass;

                  Note that these classes are not being used in any way. They only get defined.
                  In the table below the runtime startup performance versus the number of
                  classes is shown:

                  Table 5:

                  Number of Lazy Binding Delta Delta
                  Classes Relocations Time Relocations Time
                  1 23128 0.19 0 0.00
                  2 23237 0.19 109 0.00
                  3 23346 0.20 218 0.01
                  5 23564 0.20 436 0.01
                  10 24109 0.20 981 0.01
                  20 25199 0.21 2071 0.02
                  30 26289 0.22 3161 0.03
                  50 28469 0.23 5341 0.04
                  100 33919 0.28 10791 0.09
                  200 44819 0.36 21691 0.17

                  Each extra class introduces an extra 109 relocations and such a relocation
                  takes on average 8e-6 sec (CPU dependent).

                  4. A dirty hack: kdeinit
                  ========================

                  Within KDE we have been looking for a solution to this problem. We found a
                  workable solution ("hack") which addresses the problem but think that a more
                  generic, fundamental and clean solution is in place.

                  The kdeinit solution is based on the notion that instead of launching
                  applications from scratch, we start a process that links against all important
                  KDE libraries. We then keep this process around in this "preloaded" state and
                  when we need to start an application, we let this process fork() and start the
                  application by dlopen'ing the application.

                  Their are 3 problems with this approach:
                  1) It is specific for KDE and KDE libraries
                  2) The application needs to be build as an ELF shared object instead of as a
                  ELF executable.
                  3) All your processes are called 'kdeinit'.

                  The two main advantages are worth this trouble though:
                  1) Application startup performance is improved with 0.65 sec on average.
                  (On 500Mhz PIII, this number is highly CPU bound)
                  2) Memory usage is reduced with about 800kb per process.


                  5. Suggestions
                  ==============

                  There are two routes to improvement.


                  1) Improving efficiency of C++ vtable linking

                  One solution could be to make run-time
                  linking of vtables more efficient. If the linking/relocation of vtables could
                  be postponed till the first object of that class gets constructed, I expect that
                  the number of relocations during startup will drop dramatically if lazy binding
                  is enabled. KDE applications show a ratio of about 2:3 between
                  lazy and non lazy binding. The gedit example had a ratio of 1:5. If lazy binding
                  of KDE applications can be improved to a ratio of 1:5 the number of relocations
                  during startup would drop from 49366 to about 15000, which would result in the
                  link time dropping from 0.65 sec to 0.20 secs if we assume a linear relation.

                  2) pre-relocation/linking of libraries.

                  Another solution would be to add support for pre-relocating/linking libraries
                  in the linker. This solutions is IMO a more correct approach since it solves
                  the problem in a more fundamental way. The fundamental problem is that we are
                  doing a large number of relocations, over and over again (each time a KDE
                  application is started) basically we have a problem and solve that problem
                  over and over again. If we would solve the problem once and then reuse the
                  result we can save a lot CPU cycles instead of postponing the use of those
                  CPU cycles as we would do with solution 1.

                  There are a few decisions one can make when pre-relocating libraries.
                  Who will pre-relocate/link and when? Are the results stored on disk or in
                  memory? Are the results shared between different users?

                  When linking a library (and to a smaller degree when relocating) the result
                  is dependent on the other libraries. That means that the validity of a
                  pre-relocated/linked library depends on the other libraries that it depends on.

                  With kdeinit this problem is solved in an easy but crude way. When kdeinit
                  starts the libraries that are to be used are fixated, changes made to a library,
                  like upgrades, will not take effect until kdeinit is restarted. This way
                  the pre-relocated/lnked set of libraries will always remain in a consistent
                  state.

                  Although I consider this a crude way, it should be noted that most of the time,
                  especially if the owner of the system is not a KDE developer him or herself,
                  libraries do not change. Assuming that someone updates his system once a month,
                  that means that 29 out of 30 days his libraries remain the same.


                  6. Interesting papers
                  =====================

                  Dynamic Linking and Loading
                  http://iecc.com/linker/linker10.html(...)

                  Cross-Address Space Dynamic Linking
                  http://www.sun.com/research/techrep/1992/smli_tr-92-2.pdf(...)

                  High Performance Dynamic Linking Through Caching
                  http://www.usenix.org/publications/library/proceedings/cinci93/full(...)

                  Neutrino (R) System Architecture Guide -
                  Dynamic Linking in Neutrino
                  http://www.qnx.com/literature/nto_sysarch/dll.html(...)

                  Linker and Libraries Guide
                  http://docsun.cso.uiuc.edu:80/cgi-bin/nph-dweb/ab2/coll.45.5/LLM/@A(...))#CHAPTER6-35405?

                  M. Franz. Dynamic linking of software components.
                  IEEE Computer, vol 30, no 3, pp 74-81, March 1997.

                  SGI's IRIX "rebases" libraries which eleviates the need for actual
                  relocations, as descried by Shankar Unni in the following mail:
                  http://www.suse.de/~bastian/Export/linking_sgi.msg(...)

                  7. Change History
                  =================

                  Version 1.0:

                  Initial version


                  Version 1.1:

                  Added Change History
                  Added Table numbering
                  Added Table 5

                  Version 1.2:

                  Added Table 4a, 4b and 4c.
                  Added note that LD_DEBUG=staticstics only counts the number of relocations that
                  require a symbol lookup.
                  Added suggestion to cache symbol lookups related to R_386_32 relocations (Table 4d)

                  Version 1.3:

                  Added note that this paper describes gcc 2.95.
                  Added reference to SGI's IRIX.
                  • [^] # Re: Openoffice.org RC3

                    Posté par  . Évalué à 4.

                    Bravo, tu viens d'utiliser deux techniques d'augmentation de XP qui nous rapproche chaque jour un peu plus de slashdot...
                    - D'abord le "je vais me faire modérer vers le bas mais...." (à deux reprises, félicitations!). Je comprends pas que cette technique fonctionne encore...
                    - Puis le fait de recopier un mail au lieu de le linker (mail qui avait déjà été linké maintes fois à l'époque où on avait "découvert" l'objprelink pour KDE)...

                    2 points /. !


                    Allez, comme tu n'as pas trop du lire ce que tu as recopié, je te préviens que "This paper is based on gcc 2.95, many of the issues described here have been fixed in gcc 3.1", donc comme critique de GCC, bof...
                    • [^] # Re: Openoffice.org RC3

                      Posté par  . Évalué à 1.

                      1) Les Xp je ne sais même pas à quoi ils peuvent servir dans le nouveau LinuxFR..

                      2) donc comme critique de GCC, bof... , merci d'illustrer par l'exemple ce que je disais : toute critique de GCC est "intégristement incorrecte".

                      Malgré les amélioration de GCC, plus de 90% du temps de démarrage d'une appli c++ vient des relocations, et le prelinkage permet de diviser par 2 ce nombre de relocations.

                      Pensais-tu que les développeurs de OO étaient stupides au point d'utiliser un prelink inutile ?
                      • [^] # Re: Openoffice.org RC3

                        Posté par  . Évalué à 1.

                        Rassure moi, tu le fais expres ou tu n'as juste pas lu ce que j'ai posté ?

                        Remarquer qu'un argument est obsolète, c'est intégriste... eh beh...

                        Et pourquoi prétends tu que je dis du mal de prelink ?

                        Allez hop: ceux qui exprimeront une opinion contraire à ce poste sont intégristes.
                        • [^] # Re: Openoffice.org RC3

                          Posté par  . Évalué à 2.

                          Parce que justement l'argument n'est pas obsolète. Le prelink a toujours une utilité, ce qui est bien la preuve que GCC est encore loin de faire tout le boulot.

                          Ensuite, une appli C++ sous linux compilée avec GCC rame au démarrage, alors que ce n'est pas le cas sur les autres plateformes avec d'autres compilateurs.

                          J'ai toujours écrit que les choses s'amélioraient (depuis que WB a fait l'analyse initiale), mais nous sommes encore très loin du compte. De plus, GCC a ce problème en C++ mais pas en C.

                          Donc, oui, je critique GCC, et cette critique est toujours d'actualité.

                          Les choses se sont améliorées, et vont encore s'améliorer, je le sais, et je l'ai toujours dit.

                          Mon principal message est d'expliquer à ceux qui disent :

                          - OO c'est nul parce que ça rame au démarrage.
                          - KDE c'est nul parce que les applis mettent du temps à démarrer.
                          - C++ c'est nul parce que les applis rament.

                          Et bien en fait ces gens là ce trompent. Le problème vient du compilateur. Avec d'autres compilateurs, la donne change complètement. Le compilateur s'améliore, et en attendant qu'il se soit suffisamment amélioré, on a des moyens de substitution telles que les bidouilles du prelink, mais aujourd'hui cela reste quand même un problème.

                          Aujourd'hui, GCC est un mauvais compilateur C++.

                          C'est pas grave, on fait avec, et ça va changer progressivement.
                          • [^] # Re: Openoffice.org RC3

                            Posté par  . Évalué à 0.

                            Oui, gcc est un mauvais compilo g++...
                            Et ? Le fait de ne pas dire que c'est un mauvais compilo tout court, ca fait de moi un intégriste ? Perso, si tu me trouves un meilleur compilo, je prends.. J'ai besoin d'un compilateur tournant sous Linux et BSD, permettant de faire tourner mes programmes C et C++ sur Linux et BSD x86, Linux PPC, et Linux Arm (Zaurus), tourner et cibler MSWin et MacOSX serait un petit plus...

                            Gcc est mauvais en C++... super, on le savait depuis l'affaire objprelink de kde... ca valait le coup d'insulter par deux fois les lecteurs... et de traiter d'intégriste ceux qui remarquent les posts vieux de deux ans..
                • [^] # Re: Openoffice.org RC3

                  Posté par  . Évalué à 2.

                  Oups, excuses, je t'avais lu trop rapidement, j'avais cru que tu disais que le prelink gaspillait de la RAM. Désolé pour la remarque dans mon post précédent ;-)
                  • [^] # Re: Openoffice.org RC3

                    Posté par  (site Web personnel) . Évalué à 2.

                    Bah, la qualitée de ton post m'interdit toute critique ^_^.
                    (Et merci pour les infos au fait, ça m'eviteras de raconter/croire des conneries plus longtemps)

                    Par contre, j'ai lu nulle part que prelink réduisait la redondance des v-tables ou diminuait la taille en mèmoire des binaires (ce qui est sûr c'est qu'il augmente la taille occupée sur le disque).
                    D'ailleurs, et si j'ai bien compris, réduire ces v-tables ne pourrais se faire qu'à la compilation parce que je vois pas comment savoir qui hérite de quoi à partir du binaire.
                    En plus, dans le cas où l'emplacement réservé à la librairie n'était pas disponible, ld fait son boulot normalement. Est-ce que ça suppose que les sections redondantes du binaire restent intactes ?
                    • [^] # Re: Openoffice.org RC3

                      Posté par  . Évalué à 3.

                      Actuellement, je ne sais pas comment fonctionnent les dernières versions de prelink, mais la première version faisait une immonde bidouille. Il y avait toujours n entrées dans la V-Tables, mais les entrées identiques pointaient sur un index, qui lui-même pointait sur l'adresse de la fonction.

                      Ainsi au démarrage, l'adresse n'est calculée (et stockée) qu'une seule fois, au lieu de n fois.

                      Mais tout le monde est tout à fait d'accord : on peut largement améliorer les choses en intervenant directement sur le compilateur et l'éditeur de lien. Desz choses ont déjà été faites en ce sens, mais il reste encore bcp à faire.
  • # Re: Openoffice.org RC3

    Posté par  (site Web personnel) . Évalué à -2.

    Non la version 1.1RC3 n'est pas en FR
    la dernière version FR est la 1.0.3
    • [^] # Re: Openoffice.org RC3

      Posté par  . Évalué à 2.

      c'est faux.

      j'ai la RC 2 de la 1.1 et elle est en français. Dispo sur le mirroirs francophones.

      Il est bon de se renseigner avant d'être aussi catégorique.
  • # Re: Openoffice.org 1.1 RC3

    Posté par  . Évalué à 1.

    Y'a t-il un quelconque correcteur grammatical disponible sous Linux qqpart? Le correcteur 101 n'est plus publié sous cet OS et c'est la seule chose qui manque à OOo pour ma petite personne... J'ai envoyé un mail à Documens pour savoir s'ils comptaient republier le Correcteur 101 sous Linux mais pas de réponse... Si tout le monde si met qui sait, peut-être leur politique changera... info@documens.com

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.