Heure

• [^]Re: Heure

  Posté par Tennis Prono (page perso, ) le 28/10/2005 à 14:29. (lien). Évalué à 7.

  heure métropolitaine, pardon aux français d'Outre-Mer :-)

  --
  Pas de bureau 3d libre sans drivers libres!

  • [^]Re: Heure

    Posté par Narmer () le 28/10/2005 à 18:03. (lien). Évalué à 7.

    C'est marrant quand je suis en Guyane ce sont les Français en "France hexagonale" qui sont "d'outre-mer" ... Question de point de vue ;)

    • [^]Re: Heure

      Posté par boris (page perso, ) le 28/10/2005 à 18:40. (lien). Évalué à 7.

      Objectivement tu as raison, mais sans conventions c'est le bowdel.

Attention : message sans intérêt

• [^]Re: Attention : message sans intérêt

  Posté par liberforce (Jabber id, page perso, ) le 28/10/2005 à 14:42. (lien). Évalué à 6.

  Personnellement, je ne pense pas que sa sobriété soit un défaut... Et il a de grandes possiblités de personnalisation, donc... Et je préfère la sobriété pour travailler à un Windows XP ou KDE, beaucoup plus chargés et plus fatiguant à la longue (avis personnel). Après le look dépend aussi de ton distributeur.
  
  Quand à tes thin clients, il me semble que les bibliothèques sont chargées en mémoire sur tes serveurs, donc chargées une seule fois pour tous les clients. GNOME ou pas, je crois que cela n'a pas de rapport.

  • [^]Re: Attention : message sans intérêt

    Posté par Guillaume Knispel () le 28/10/2005 à 15:41. (lien). Évalué à 4.

    Les données des logiciels et bibliothèques ne sont bien évidemment pas partagées entre tous les clients. Je doute que quand Gnome utilise X Mo de RAM, il s'agit de X Mo de code... (le code est loin d'être majoritaire à mon avis).

    • [^]Re: Attention : message sans intérêt

      Posté par liberforce (Jabber id, page perso, ) le 28/10/2005 à 16:12. (lien). Évalué à 3.

      Tout à fait, c'est pour ça qu'en général ces bécanes sont assez caustaudes en RAM... Il y avait eu un article récemment ici sur un cas concret de mise en oeuvre de thin clients sous debian, mais je sais plus où...

  • [^]Re: Attention : message sans intérêt

    Posté par Obsidian () le 01/11/2005 à 15:10. (lien). Évalué à 2.

    Quand je parlais de sobriété toute relative, je voulais bien entendu parler de sa voracité en RAM et en ressources diverses. Pour les thèmes graphiques, GNOME n'a désormais plus rien à prouver, bien sûr.

  • [^]Re: Attention : message sans intérêt

    Posté par Will Hunting (page perso, ) le 01/11/2005 à 18:49. (lien). Évalué à 2.

    Un Windows XP correctement dégraissé est bien agréable et pas loin de la "sobriété" de Windows 95, mais ce n'est pas livré ainsi par défaut. Quant à KDe, j'ignore si on peut lui faire perdre ses rondeurs dans les mêmes proportions...

    --
    Planète Orange

[GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

• [^]Re: [GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

  Posté par liberforce (Jabber id, page perso, ) le 28/10/2005 à 15:07. (lien). Évalué à 5.

  Oui, c'est le blog de Federico Mena Quintero (un des fondateurs de GNOME, avec Miguel de Icaza), qui se penche en ce moment exclusivement sur les problèmes de performances. Au passage, il est très sympa, très disponible et m'a bien aidé pour le profiling de gedit :
  
  Le bug:
  http://bugzilla.gnome.org/show_bug.cgi?id=160917
  L'analyse:
  http://primates.ximian.com/~federico/news-2005-10.html#gedit(...)

• [^]Re: [GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

  Posté par baud123 (Jabber id, page perso, ) le 28/10/2005 à 15:21. (lien). Évalué à 2.

  Ceux qui ne sont pas au club peuvent tout à fait passer en cooker (à leurs risques et périls, comme d'hab', mais tout n'est jamais vraiment cassé, sauf parfois pas mal de choses ;-) )
  
  Pour ceux qui sont au club ces backports de cooker seront-ils mis à jour (pas de maintenance ok... mais des corrections) ? comment se passeront les mises à jour ? un répertoire update dédié au club ?
  Dans le cas d'une réponse négative, un retour à Gnome 2.10 est-il prévu ?
  
  Ne vaut-il pas mieux - comme fait généralement pour une cooker - y dédier une partition afin de pouvoir revenir sur une version stable ensuite ? (perso c'est ce que je recommanderais : mieux vaut prévenir que guérir, quand il y en aura pleins qui demanderont quand les mises à jour seront là et à qui il faudra annoncer "ah bin dans une 2006.1 qui arrivera bientôt... ou sinon passer en cooker....").
  
  En tout cas, bonne initiative, ça peut permettre de ramener du monde sur le sujet et enlever un peu de lenteur à Gnome.

  • [^]Re: [GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

    Posté par Pascal Terjan (Jabber id, page perso, ) le 28/10/2005 à 19:08. (lien). Évalué à 5.

    Et en plus en passant en Cooker ils auront le package de sysprof tout prêt :-)
    Sinon je pense que celui de cooker s'installe sans pb sur une 2006 (au pire il faut rebuilder le rpm) mais j'ai pas testé.

    • [^]Re: [GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

      Posté par liberforce (Jabber id, page perso, ) le 29/10/2005 à 00:04. (lien). Évalué à 4.

      J'ai testé, il s'installe très bien sur une 2006...

      • [^]Re: [GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

        Posté par liberforce (Jabber id, page perso, ) le 29/10/2005 à 00:07. (lien). Évalué à 2.

        Et puis v'la l'adresse, tiens...
        ftp://mandrake.contactel.cz/Mandrakelinux/devel/cooker/i586/(...)

• [^]Re: [GNOME 2.12 sous 2006.0] dispo pour utilisateurs club Mandriva

  Posté par Bruce Le Nain (Jabber id, page perso, ) le 31/10/2005 à 08:51. (lien). Évalué à 2.

  >>nouveau média crée pour le club qui aura des backports de cooker.
  
  à propos, le media "club contrib", il est stable ou instable ? Qu'y a t-il dedans ?

  --
  Hôdo
  Livingstone

Il y a du travail de fait

• [+] [^]Re: Il y a du travail de fait

  Posté par morphalus (page perso, ) le 30/10/2005 à 23:19. (lien). Évalué à -2.

  \o/

• [^]Re: Il y a du travail de fait

  Posté par liberforce (Jabber id, page perso, ) le 31/10/2005 à 09:47. (lien). Évalué à 3.

  En même temps, il faut se rappeler que ces 17 secondes dépendent de la bécane qui fait tourner GNOME... Ici c'est un Dell Latitude D400:
  

  Processor: Intel Pentium M, 1400 MHz
  Memory: 512 MB 266 MHz DDR SDRAM

  • [^]Re: Il y a du travail de fait

    Posté par ondex () le 31/10/2005 à 11:00. (lien). Évalué à 1.

    Si j'ai bien compris, la principale perte de temps se fait à attendre les données du disque dur.
    
    Ce que propose Colitti, c'est charger les certaines librairies importante (Gtk) entièrement au début plutôt que de le faire petit à petit, c'est aussi de lire toute la conf gconf en une fois et la parser petit à petit, etc...
    
    Donc, je ne pense pas que son processeur ou sa RAM ne joue vraiment. Par contre, son disque dur (Toshiba MK3021GAS 30GB, 4200 RPM hard disk) est vraiment lent. Je ne sais pas combien de temps il est possible de gagner sur un PC de bureau avec un disque dur à 7200RPM.
    
    Mais bon, même 5 ou 10 secondes de gagnés, c'est déjà ça de pris...

    • [^]Re: Il y a du travail de fait

      Posté par liberforce (Jabber id, page perso, ) le 31/10/2005 à 12:02. (lien). Évalué à 2.

      Exact, je m'en suis rendu compte juste après avoir validé mon post, mais j'ai eu la flemme de rajouter la précision. ça m'apprendra ^_^.
      
      Pour gconf, un des problèmes, c'est que c'est fait en plein de petits fichiers, ce qui augmente les temps de lecture. ça fait un petit moment qu'on sait que ce sont les accès disque qui sont le goulot d'étranglement (déjà évoqué lors du GUADEC 2005) par Robert Love:
      A LIRE ABSOLUMENT !
      
      http://rlove.org/talks/rml_guadec_2005.sxi
      
      Ces deux phrases résument le problème :
      

      As processor speeds increase, I/O wait time approaches 100% of total time!

      
      

      Conclusion: Splattering files all over disk is bad; subdirectories are better; all in same directory good; single file best

      
      Ce qui fait que plein de petit fichiers pour gconf entraine des performances catastrophiques...

      • [^]Re: Il y a du travail de fait

        Posté par Yusei (page perso, ) le 01/11/2005 à 09:14. (lien). Évalué à 2.

        Si j'ai bien compris ce que disait le monsieur qui a fait le Summer of Code sur ce sujet, si on n'utilise pas de Gnome <= 2.6, on peut déjà profiter de ce gain en appelant gconf-merge-tree sur /etc/gconf/gconf.xml.defaults.
        
        Je l'ai fait il y a quelques temps, mais je n'ai pas senti de grosse amélioration. Certainement rien de l'ordre des 10 secondes, et pourtant j'ai un disque dur à 4200 rpm. Quelqu'un a essayé et a eu des résultats positifs ?

      • [^]Re: Il y a du travail de fait

        Posté par Victor STINNER (page perso, ) le 01/11/2005 à 20:20. (lien). Évalué à 3.

        Il faut savoir que Enlightenment (17) démarre en moins d'une seconde (si on désactive l'animation de chargement totalement inutile, mais tellement belle ...). Ils ont choisi d'utiliser un format binaire très optimisé justement pour des questions de performance : fichiers plus petits et plus rapide à parser.
        
        Résumé en une phrase :
        

        E17 uses binary config files. They have very little read/write overhead, so there is no no CPU wastage on parsing etc.

        
        Plus d'info ici :
        http://get-e.org/Main/FAQs.html#8
        
        Haypo

        • [^]Re: Il y a du travail de fait

          Posté par imr () le 02/11/2005 à 22:46. (lien). Évalué à 3.

          Ca ne risque pas d'être une horreur à intégrer pour les distros?
          Et les thèmes seront ils faciles à faire ou faudra t il avoir quelques années de programmation dans les pattes?

          • [^]Re: Il y a du travail de fait

            Posté par Victor STINNER (page perso, ) le 02/11/2005 à 23:28. (lien). Évalué à 2.

            Hum, j'ai pas trop compris la question. Il y a des outils et bibliothèques pour éditer les fichiers binaires, donc ça s'automatise aussi bien qu'un format texte (je pense).
            
            Haypo

autre optimisation

• [^]Re: autre optimisation

  Posté par liberforce (Jabber id, page perso, ) le 31/10/2005 à 14:04. (lien). Évalué à 2.

  C'est seulement vrai sur les listes avec beaucoup d'éléments: tu passes plus de temps à parcourir la liste qu'autre chose. Le temps d'accès à un élément dépendra de sa position dans la liste: si c'est le premier ce sera très rapide (plus que les tableaux il me semble), si c'est le dernier ce sera très long. Les tableaux par contre sont assez lents d'accès, mais ce temps d'accès est constant.
  
  <<corrigez moi si je dis une bêtise>>

  • [^]Re: autre optimisation

    Posté par allcolor (Jabber id, page perso, ) le 01/11/2005 à 01:13. (lien). Évalué à 4.

    Tu dis une bétise... en tout les cas pour le C (et aussi java). En C, un tableau c'est le pointeur vers le premier élément... tu fais ++ à ton pointeur et tu es sur le deuxième élément... y a pas plus rapide comme accès.

    --
    All those moments will be lost in time, like tears in the rain.

  • [^]Re: autre optimisation

    Posté par Erwan (page perso, ) le 01/11/2005 à 05:17. (lien). Évalué à 6.

    La difference de base entre un tableau et une liste chainee, c'est que le tableau est une zone contigue de la memoire alloue une seule fois, a la creation du tableau, alors que dans une liste chainee on alloue la memoire quand on en a besoin.
    
    Par consequent, si on veut l'element no 100 d'un tableau, on a juste a incrementer la valeur du pointeur de 100. On sait ou va se trouver l'element dans la memoire. A l'inverse, une liste chainee c'est un ensemble de paire (donnees, pointeur suivant). Donc on est oblige de suivre la liste du debut jusqu'a l'element voulu pour arriver jusqu'a l'element qu'on cherche.
    
    Le probleme des tableaux, c'est que la taille est fixe. Forcement, vu que c'est une zone memoire contigue, si on ecrit des choses derriere on ne peut pas agrandir le tableau.
    
    La solution hybride c'est les tables de hachage. Un gros, c'est un tableau de listes chainees.
    
    Exemple: on veut classer des mots. On fait un tableau de 26 cases avec les lettres de l'alphabet (a, b, c, d, e...). A chaque lettre est associee une liste chainee. Et si on veut classer le mot "troll" (ou le rechercher), on va directement au "t" puis on parcours la liste chainee pour trouver le mot (ou l'inserer par ordre alphabetique).
    
    Bien sur, une telle table de hachage n'est pas tres bonne parce qu'on va avoir beaucoup de collisions (cad: d'elements inseres dans la meme liste chainee). Dans l'ideal on ne doit avoir que quelques elements par liste, pour que l'acces soit plus rapide.

    • [+] [^]Re: autre optimisation

      Posté par d-jo (page perso, ) le 01/11/2005 à 12:47. (lien). Évalué à -1.

      La difference de base entre un tableau et une liste chainee ...
      
      Il me semblait également qu'un tableau permet un acces aléatoire alors qu'une liste chainée ne permet qu'un acces sequentiel ?

      • [^]Re: autre optimisation

        Posté par bluestorm () le 01/11/2005 à 13:16. (lien). Évalué à 3.

        Oui, et d'ailleurs c'est ce qu'il dit dans le paragraphe suivant. :P

        • [^]Re: autre optimisation

          Posté par d-jo (page perso, ) le 01/11/2005 à 16:12. (lien). Évalué à 2.

          au temps pour moi :(

    • [^]Re: autre optimisation

      Posté par liberforce (Jabber id, page perso, ) le 02/11/2005 à 10:23. (lien). Évalué à 2.

      Ok, ça me parraissait étonnant, mais c'était des vieux souvenirs de cours (pas très frais on dirait). Donc si j'ai bien compris pour choisir entre liste chainée, tableau ou table de hachage, c'est surtout une question de compromis entre rapidité et empreinte mémoire, et savoir si ton nombre d'éléments à stocker est variable...

      • [^]Re: autre optimisation

        Posté par Yusei (page perso, ) le 02/11/2005 à 10:55. (lien). Évalué à 4.

        Ça dépend aussi du type d'opérations que tu vas faire sur tes données. Si tu fais beaucoup d'accès aléatoires, un tableau est définitivement plus rapide. Par contre si tu déplaces beaucoup les éléments, la liste chaînée est meilleure:
        
        Imaginons ce tableau, dans lequel je veux déplacer 6 en première place
        1 2 3 4 5 6 7
        Je dois d'abord déplacer 1, 2, 3, 4 et 5 d'un cran vers la droite, puis placer 6 en première place. Si j'avais eu une liste (simplement) chainée, j'aurais juste eu à faire:
        5.suivant = 7
        6.suivant = 1
        liste.premier = 6

        • [^]Re: autre optimisation

          Posté par ham () le 02/11/2005 à 11:37. (lien). Évalué à 1.

          Je pense aue dans le cas des GList trop utilisé, ca peut venir du fait que les gens veulent une liste de taille non fixe.
          
          C'est plus un probleme d'API que de savoir si tel ou tel structure de donné est plus efficace.
          Idealement (glib, java, C#, mono,c++...) je m'attend a avoir un objet de type Liste qui offre une interface simple et clair.
          
          Ensuite il peut y avoir autant de specialisation possible que l'on veut,
          l'implementation par default devrais etre la plus rapide en moyenne.
          Si on ne fait pas de deplacement dans la liste, on prend un truc du genre liste chainé de tableau, arbre de tableau , ...
          
          dans le cas de la Glib et d'apres les commentaires des gens qui ont regardé le mauvais usage de la GList, c'est que les dev ne lisent pas la doc, la doc n'est pas assez clair, l'API devrais etre repensé.

          • [^]Re: autre optimisation

            Posté par Yusei (page perso, ) le 02/11/2005 à 11:54. (lien). Évalué à 4.

            Au passage, la GLib propose GArray, qui est un tableau extensible, et pourrait certainement remplacer les G(S)List dans de nombreux cas.
            
            

            je m'attend a avoir un objet de type Liste qui offre une interface simple et clair.
            Ensuite il peut y avoir autant de specialisation possible que l'on veut

            
            
            Le problème si on a une seule interface commune aux différents types de données, c'est qu'on va être obligé de définir toutes les opérations pour tous les types, même quand une opération est très coûteuse.
            
            Par exemple on va avoir une opération "obtenir l'objet précédent" qui sera disponible aussi dans les GSList, malgré le fait que ce soit une opération très coûteuse dans une GSList (on doit parcourir la liste), et très peu coûteuse dans une GList ou GArray (accès en temps constant).
            
            Actuellement, GSList ne propose pas cette opération. Donc si j'ai besoin d'obtenir l'objet précédent, plusieurs cas se présentent:
            - j'adapte mon algo pour avoir toujours un pointeur sur l'objet précédent, et donc c'est bien mieux qu'avoir utilisé une fonction générique
            - je code une fonction générique, et j'ai une bonne chance de me rendre compte que c'est mauvais
            - j'utilise un type de données plus adapté, comme une GList.
            
            Au final, même si l'on masque les spécificités des types de données dans une interface commune, on a quand même besoin de savoir ce qui est utilisé derrière si on veut être efficace.

            • [^]Re: autre optimisation

              Posté par vrm (page perso, ) le 02/11/2005 à 12:10. (lien). Évalué à 1.

              tu fais un gros
              
              throw new UnsupportedException("send a patch");
              
              :)

            • [^]Re: autre optimisation

              Posté par ham () le 02/11/2005 à 12:59. (lien). Évalué à 3.

              
              Au final, même si l'on masque les spécificités des types de données dans une interface commune, on a quand même besoin de savoir ce qui est utilisé derrière si on veut être efficace.
              

              
              
              d'ou ma remarque d'utiliser par defaut des listes qui sont performantes en moyenne, comme, au pif, des listes doublement chainé.
              
              Le mechanisme proposé permet justement de pouvoir choisir ce qui est utilisé derriere SI on veut etre efficace.
              
              Actuellement il faut connaitre les details de l'implementation derriere, ses limites,...etc. avant de l'utiliser, et ca c'est mal.
              Quand j'utilise une API je m'attend a avoir un truc qui me simplifie la vie, ensuite si je sait que mon programme doit en moyenne augmenter ses donnés de 200 élements, j'ai pas envie de changer tout mes types a chaque fois, l'API devrait me permettre de la regler.
              
              De plus les exceptions, ca peut servir a gérer ce genre de truc, meme si c'est ca pourrais etre plus propre:
              - un objet de base
              - une interface si besoin est pour des propriété particulière
              - des itérateurs
              Enfin Cf les vecteurs en java,
              
              il suffit de faire une GList abstraite et que le dev choissisent une implementation precise.

              • [^]Re: autre optimisation

                Posté par Yusei (page perso, ) le 02/11/2005 à 13:36. (lien). Évalué à 3.

                On est d'accord qu'il y a mieux "en général" qu'une liste simplement chaînée, par exemple des listes de tableaux. Mais il n'y a pas de structure qui soit bonne "en général", et qui permette d'éviter de se demander quoi choisir. Si ça existait, tu penses bien que tout le monde l'utiliserait :)
                
                L'approche la plus propre que je connaisse est celle de la STL, où effectivement dans de nombreux cas on peut changer la structure de données sans changer le code, mais là non plus on n'est pas dispensé de savoir choisir entre les différents types de données. Et si tu choisis le mauvais type et que tu fais un algo en fonction de ce type, tu devras quand même réécrire ton code si tu changes d'avis.
                
                Ce que je veux dire, c'est que tu peux abstraire autant que tu veux tes types de données, au moment de coder l'algo tu es obligé de savoir des choses basiques comme:
                - Je peux parcourir mes éléments séquentiellement ou pas ?
                - Je peux accéder à un élément n'importe où ou pas ?
                - Je peux parcourir dans les deux sens, ou dans un seul ?
                - Je peux déplacer des éléments ou pas ?
                - Je peux stocker beaucoup de données ou pas ?
                (Pour toutes ces questions, il faut bien sûr penser "en temps et en espace raisonnables", sinon la réponse est toujours oui)
                
                Et même si ton API te fournit le même ensemble de fonction pour tous les types, ça ne veut pas dire que ces fonctions sont efficaces.
                
                Par exemple si tu utilises comme abstraction des iterateurs, ton API ne te donnera pas d'iterateur qui puisse se déplacer dans les deux sens pour une liste simplement chaînée. Ou bien si elle te fournit un iterateur qui le fait, il sera très lent.
                
                Pareil pour les listes doublement chaînées, tu auras sûrement une fonction "obtenir l'élément à la position i", mais cette fonction sera lente. Donc si tu veux être efficace, quoi qu'il arrive, tu devras connaître les limites du type de données que tu manipules.
                
                (Après, savoir si ça vaut le coup de se casser la tête pour choisir le bon type de données, c'est un autre problème. Dans beaucoup de cas, utiliser un Vector en Java sera très acceptable. Mais si tu as besoin d'être efficace, pas le choix)

                • [^]Re: autre optimisation

                  Posté par ham () le 02/11/2005 à 15:40. (lien). Évalué à 1.

                  Je suis globalement d'accord,
                  Je ne dis pas que l'API doit fournir une classe liste quifaittout, je dis que l'API doit fournir une abstraction, avec plusieurs niveau si nécessaire,
                  
                  et si l'API propose une implémentation par defaut (GDefaultList), peut etre prendre un truc vaguement générique, facilement changeable.
                  
                  Ensuite pour avoir des programmes quitorche, c'est encore mieux si l'API a un flag profiling pour voir les statistiques d'utilisations des fonctions, avec des infos utiles (nombre d'elements, .. toussa).
                  
                  Je pense que les cas ou l'on recherche l'optimisation est bien plus faible que les cas ou on veux juste une liste.
                  
                  Sinon je suis allé voir la doc de la GLib et les type proposé sont trop spécialisé (i.e il manque le vecteur de java).
                  Si on veut utiliser la Glib, il n'y a pas vraiment une liste a tout faire avec performances correcte.
                  
                  Le plus proche est le GArray, mais ca ressemble a un tableau avec du realloc, eventuellement avec de la préalocation,
                  pas des trucs du genre <truc tres opaque> avec une API type tableau,
                  par ex partitioner l'espace des index dans un arbre a arité fixe, le tout paramétrable, avec de bon defaut.
                  
                  Ensuite si on veut s'amuser en C on peut commencer a mettre les donnés de liste dans la structure a stocker, et stocker des offset dans une strucuture de type liste.
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  
                  

              • [^]Re: autre optimisation

                Posté par fmaz fmaz () le 02/11/2005 à 17:10. (lien). Évalué à 3.

                Les listes doublement chaînées ne sont pas « efficaces en moyenne ».
                
                Pour rechercher si un élément est dans ta liste, tu dois forcément
                parcourir ta liste ce qui est linéaire alors qu'avec un arbre binaire,
                c'est en temps logarithmique.

                • [^]Re: autre optimisation

                  Posté par ham () le 02/11/2005 à 23:02. (lien). Évalué à 3.

                  c'etait juste une illustration.
                  
                  Les arbres binaire, il y en a plein, si ce n'est pas equilibré, ben c'est moin interessant (Cf quick sort et tri-fusion).
                  
                  Une premiere etape pour choisir ses structure de données:
                  http://en.wikipedia.org/wiki/List_of_data_structures
                  
                  et ensuite
                  
                  http://www.nist.gov/dads/
                  
                  Pour avoir plein d'algo, et de pointeurs