mouais

• [^]Re: mouais

  Posté par patrick_g (page perso, ) le 02/11/2006 à 12:33. (lien). Évalué à 10.

  >> il y a eu 1 message sur la mailing list. on ne va pas dire que c'est l'enthousiasme général
  
  Devant cette annonce sortie de nulle part et annonçant un projet pouvant être vu comme "concurrent" il aurait pu y avoir une avalanche de trolls. Cela n'a pas été le cas et c'est déjà très bien.
  J'attends quand même de voir comment va s'effectuer la synchro périodique avec GCC mainline avant de crier victoire.
  
  En tous cas cette annonce consacre vraiment la prééminence de GCC et ça c'est une excellente nouvelle.

Une petite coquille ...

pilotage uniquement par mandriva ?

• [^]Re: pilotage uniquement par mandriva ?

  Posté par patrick_g (page perso, ) le 02/11/2006 à 13:19. (lien). Évalué à 9.

  Bah la seule info c'est la phrase sur la mailing list qui annonce que :Sebastian volunteered to regularly sync from both mainline and the lto-branch.
  
  Donc je pense que ce ne sera pas un gros paquet de code qu'on écrit dans son coin et qu'on amène sous son bras 30 mois plus tard (qui à dit compiz ?). Les merge seront réguliers.
  Par contre je ne sais pas si le boulot se fera de façon ouverte en permanence (svn et autre).

• [^]Re: pilotage uniquement par mandriva ?

  Posté par marseillais (page perso, ) le 02/11/2006 à 13:22. (lien). Évalué à 10.

  Après NEPOMUK qui semble t'il a réellement démarré ( le développeur de k3b a été embauché par mandriva pour ce projet ) il semblerait que plusieurs projet européen de recherche sur les logiciels libres soient lancés et que mandriva ait la confiance des gouvernements pour mener ces projets.
  C'est une bonne chose il me semble. Espérons que ces projets arrivent a terme et ne soit pas que de simples annonces suivi de recherches fondamentales poussée ne débouchant sur rien de concret.

  • [+] [^]Re: pilotage uniquement par mandriva ?

    Posté par rewind () le 03/11/2006 à 10:32. (lien). Évalué à -4.

    Moi j'ai du mal à comprendre comment mandriva qui a du mal à ficeler une release en temps et en heure va pouvoir mettre des gens sur un projet aussi important... Je m'interroge vraiment et je me demande si ce n'est pas juste pour récupérer des crédits...

    • [^]Re: pilotage uniquement par mandriva ?

      Posté par kowalsky () le 03/11/2006 à 10:44. (lien). Évalué à 2.

      FUD... Méconnaissance du sujet, etc...

      --
      You got the money, I got the soul.

      • [^]Re: pilotage uniquement par mandriva ?

        Posté par rewind () le 04/11/2006 à 09:42. (lien). Évalué à 3.

        J'aimerais bien des explications alors si c'est possible comme ça il n'y aura plus de FUD...

        • [^]Re: pilotage uniquement par mandriva ?

          Posté par Ant () le 04/11/2006 à 12:07. (lien). Évalué à 4.

          Ben justement, la 2007 est sortie à la date prévue, malgré une certaine inquiétude (il me semble) de la part des utilisateurs quant à son niveau de maturité.
          Il y a eu quelques soucis, mais dans l'ensemble ce lancement me parait bien plus réussi que celui de la 2006.
          
          Cette obstination à tenir le calendrier trouve peut-être là son explication....
          
          Quant au choix de mandriva, je ne vois pas d'autre société "européenne" qui fasse de la R&D sous linux et qui soit mieux placée...
          Il y avait Suse, mais elle appartient à novell maintenant.

          • [^]Re: pilotage uniquement par mandriva ?

            Posté par rewind () le 04/11/2006 à 16:33. (lien). Évalué à 3.

            http://qa.mandriva.com/twiki/bin/view/Main/MandrivaLinux2007
            
            Initial date: 2006.09.15
            Estimated date: 2006.10.02
            
            15 jours de retard...
            
            
            Et le problème que je soulève n'est pas un problème de choix, je suis très content qu'une société, française qui plus est, fasse ce choix là. Je me pose simplement la question des moyens qui seront réellement derrière.

            • [^]Re: pilotage uniquement par mandriva ?

              Posté par Juke (Jabber id, page perso, ) le 06/11/2006 à 20:51. (lien). Évalué à 0.

              tu va pas chipoter pour 15 jours, c'est kif kif
              

        • [+] [^]Re: pilotage uniquement par mandriva ?

          Posté par Ant () le 04/11/2006 à 13:28. (lien). Évalué à -1.

          Ben justement, la 2007 est sortie à la date prévue, malgré une certaine inquiétude (il me semble) de la part des utilisateurs quant à son niveau de maturité.
          Il y a eu quelques soucis, mais dans l'ensemble ce lancement me parait bien plus réussi que celui de la 2006.
          
          Cette obstination à tenir le calendrier trouve peut-être là son explication....
          
          Quant au choix de mandriva, je ne vois pas d'autre société "européenne" qui fasse de la R&D sous linux et qui soit mieux placée...
          Il y avait Suse, mais elle appartient à novell maintenant.

    • [+] [^]Re: pilotage uniquement par mandriva ?

      Posté par Troy McClure (page perso, ) le 03/11/2006 à 12:13. (lien). Évalué à -1.

      tu dois être ubuntiste pour être aussi médisant..

      • [^]Re: pilotage uniquement par mandriva ?

        Posté par marseillais (page perso, ) le 03/11/2006 à 17:49. (lien). Évalué à 1.

        :) eh eh jle suis mais c'est pas pour ca que je suis d'accord avec lui.
        Sinon en dehors de ces propos trollesque je trouve que l'implication de mandriva dans de gros projets est trés bien pour ces projets novateurs et pour mandriva qui devient une vitrine des technologies européennes.
        
        désolé pour le chauvinisme....
        
        ps: d'ailleurs j'hésite a passer a mandriva depuis la derniére version simplement par pur chauvinisme.....

J'aimerai bien y croire...

histoire de tiers...

Compilation lente

• [^]Re: Compilation lente

  Posté par Gael Tessier (page perso, ) le 02/11/2006 à 14:10. (lien). Évalué à 4.

  Justement, on avance une estimation du ralentissement de la compilation avant même que le projet ait commencé. C'est peut-être la limite qu'ils se sont fixés de ne pas dépasser.
  
  Et côté gain à l'exécution, des estimations ont-elles été faites ?
  
  --
  http://www.tessier-net.org

  • [^]Re: Compilation lente

    Posté par Paul POULAIN (page perso, ) le 02/11/2006 à 14:35. (lien). Évalué à 2.

    si j'ai bien tout bien lu, l'objectif est finalement d'améliorer le temps d'éxécution, mais surtout de détecter des problèmes d'exécution dès la phase de compilation.
    du genre : une fonction F qui appelle une fonction G(x) = 1/f(x), ou on peut avoir f(x) qui vaut 0 à l'exécution. C'est l'exemple qui est donné, mais j'imagine qu'il doit y avoir pas mal de choses au niveau détection de failles potentielles à faire.
    
    L'amélioration de l'exécution, c'est plus mieux du point de vue affichage, mais l'amélioration de la qualité, ce sera plus mieux pour les geeks que nous sommes ;-)

    • [^]Re: Compilation lente

      Posté par Thomas Douillard () le 02/11/2006 à 14:54. (lien). Évalué à 2.

      Il y a des chances que les performances ne soient pas améliorées dans l'histoire, c'est sûr : les algorithmes de détections de ce type de propriétés ne se font pas forcément, du point de vue de la complexité algorithmique, aussi rapidement que les autres, sauf peut-être à rechercher des propriétés relativement triviales.
      
      Ils vont peut-être devoir changer d'ordre de grandeur l'algorithme, ce qui n'est à priori pas bon pour le temps d'exécution. Je pense pas que le "10x" soit significatif, ils donnent ça comme un vague ordre de grandeur dans la description du projet.

• [^]Re: Compilation lente <=> Analyse de flot

  Posté par Ontologia (page perso, ) le 02/11/2006 à 15:13. (lien). Évalué à 10.

  Il est écrit dans l'article que l'optimisation sera globale et non plus locale.
  De quoi s'agit - il ?
  
  D'analyse de flot, très probablement.
  
  L'analyse de flot consiste à analyser toutes les branches d'exécutions du code, de produire un graphe de dépendances des données afin de détecter ce qui sera exécuté et ce qui ne le sera pas (qu'on appelle code mort).
  
  Typiquement, un objet C hérite de A et B, or dans le code on exécute que C.méthode(), B.méthode(), mais jamais A.méthode()
  
  A.méthode() est donc du code mort à ne pas inclure dans le code finale et à ne pas tester à (l'eventuelle) résolution dynamique de branche.
  
  Une analyse de flot peut être plus ou moins profonde. Ainsi une analyse très profonde peut être munie d'un moteur logique qui va par exemple détecter qu'une variable n est forcément pair (n := n*2;) et 10 km plus loins que l'on teste sa parité.
  Le moteur logique vire le test, ayant déduit qu'il ne sert à rien.
  
  Tout ceci permet d'optimiser avec bonheure toute sorte de choses faisable jusqu'ici par un humain mais rendant le code très vite illisible et inmaintenable.
  
  Ce genre d'algorithme est passeblement exponenentielle et est surtout très gourmand en mémoire.
  Lisaac qui est pour le moment le seul compilateur objet à implémenter ce type d'algorithme (oui je sais, prosélytisme), utilise environ 256 à 512 Mo pour compiler 50 000 lignes (pour 90 secondes de compilation sur une bonne machine).

  • [^]Re: Compilation lente <=> Analyse de flot

    Posté par Thomas Douillard () le 02/11/2006 à 16:07. (lien). Évalué à 4.

    D'accord avec toi, sauf que l'analyse de flot ne permet pas seulement à mon avis de détecter du code mort, mais aussi de détecter les erreurs potentielles, cf l'exemple de la division par 0 donné plus haut.
    
    Question plus technique : c'est quoi qui bouffe de l'espace dans Lisaac ? les propriétés trouvées (genre n pair), qu'on est obligé de garder parce qu'on sait pas si elles serons utiles ou pas ? (question naïve sans doute, j'y connais pas grand chose) ? Je pense pas que le graphe de flot en lui même prenne autant de place ... ? Le moteur d'inférence ?

    • [^]Re: Compilation lente <=> Analyse de flot

      Posté par Ontologia (page perso, ) le 02/11/2006 à 16:52. (lien). Évalué à 6.

      c'est quoi qui bouffe de l'espace dans Lisaac ?
      D'après ce que j'ai compris de ce que m'a expliqué Benoit, c'est le graphe de dépendance, ou graphe de flot qui prend de la place en mémoire.
      
      Faut pas oublier que Lisaac est pas un compilateur procédural mais objet.
      En procédural, tu as deux dimensions : la variable globale et la variable locale.
      En objet tu as la variable globale, locale, et l'objet en question (on peut instancier autant de fois qu"on veut), ça monte donc très très vite (les sous graphes se dupliquent très vite...).
      Lisaac est un compilateur qui traduit ton code dans un langage élémentaire rassemblant , si je ne me trompe pas, les primitives suivantes :
      
      Read
      Write
      Switch (branchement)
      soustraction
      multiplication
      division
      and
      or
      test =
      >
      
      Avec ça, il optimise tout, et reconstitue du C...
      
      Sachant que la conditionnelle est défini dans la librairie pour être justement traduite dans ce mini langage, tu imagines bien que la granulité étant très fine, on arrive très vite à des graphes très volumineux. Prenons un simple
      
      a,b : STRING;
      a := STRING.create 64;
      b := STRING.create 64;
      a := "Esope reste ici".to_string;
      b := " et se repose\n".to_string;
      (a+b).print;
      
      Là dedans, à part la primitive print, et les chaînes qu'on retrouvera tels quels dans le source C produit, ca fait déjà un beau graphe quand tu utilises des primitives aussi fines que celles décrites plus haut...
      STRING est déjà un gros objet qui utilise lui même une cascade de code (gestion mémoire, initialisation, opération +, etc...).
      
      
      Ya la gestion des contrats qui prend énormément de place aussi, car les contrats sont propagés dans tout le code.
      
      Quand au moteur d'inférence, il fut implémenté (en 2001), mais mangeait 4 Go de mémoire pour 500 lignes de code (hors librairie), ils arrivaient à faire planter le calculateur du Loria avec, à l'époque (vers 2001).
      C'est en réduisant la profondeur de l'analyse de flot que Lisaac est devenu réalité.
      
      Un des principaux travaux de recherche des prochains mois de notre ami (maintenant qu'il a enfin un poste) va consister à réimplémenter une analyse profonde dans le compilateur, avec pour but d'améliorer la sécurité et la prise en charge des contrats, prouver le langage interne, etc...

      • [^]Re: Compilation lente <=> Analyse de flot

        Posté par Thomas Douillard () le 02/11/2006 à 20:30. (lien). Évalué à 3.

        Il doit me manquer un truc, parce là je comprends pas ce qui peut faire exploser la taille.
        
        Genre pourquoi il y a duplication des sous-graphes ? à priori il suffirait de faire un arc d'un graphe vers un autre pour un appel de fonction par exemple, sans rien dupliquer du tout. Un genre d'inlining dans le graphe ? Les boucles qui sont déroulées si possible ? Il y a peut être des trucs du genre SSA (Single assignment si je me trompe pas), création d'une variable à chaque affectation ?
        
        D'autre part, je vois pas pourquoi l'instanciation des objets ferait augmenter la taille du graphe, dans un langage classique à priori c'set juste l'instanciation de la mémoire et l'appel au constructeur (en simplifiant), pas de quoi exploser, donc. C'est en rapport avec le modèle par prototype, peut-être ? Comment les objets interviennent dans ce graphe ?
        
        Pour la granularité, l'assembleur par exemple à une granularité très fine, et pourtant on a pas des exécutables de 512 megs ?

        • [^]Re: Compilation lente <=> Analyse de flot

          Posté par reno () le 02/11/2006 à 21:34. (lien). Évalué à 4.

          Bon je ne connais pas Lissac, mais il me semble que dans un compilateur faisant des optimisations globales, tu prends en compte tous les chemins possible, donc a chaque *if* tu as deux possibilités, et la combinatoire des chemins possible explose.
          
          C'est pour la phase d'optimisation que l'utilisation mémoire explose, la taille des binaires générée n'est pas impactée.

        • [^]Re: Compilation lente <=> Analyse de flot

          Posté par Antoine () le 02/11/2006 à 22:02. (lien). Évalué à 4.

          Genre pourquoi il y a duplication des sous-graphes ? à priori il suffirait de faire un arc d'un graphe vers un autre pour un appel de fonction par exemple, sans rien dupliquer du tout.
          
          Normalement, le but de l'analyse de flot est d'annoter les variables avec des propriétés décrivant leurs valeurs possibles. Pour cela on déroule le programme de toutes les façons possibles. Il y a théoriquement un jeu complet d'annotations séparées par façon de dérouler le programme, même si on peut factoriser. De plus, les annotations doivent être le plus fines possibles (par exemple l'intervalle de valeurs que peut prendre un entier).
          
          Un noeud dans un tel graphe n'est pas une fonction, mais un bloc de code, ainsi l'intérieur d'un "if" est un noeud indépendant. Mettons que tu as le fragment de code suivant :
          
          /* bloc A */
          if (cond) {
          /* bloc B */
          }
          /* bloc C */
          
          Alors le fragment de graphe correspondant comprendra trois noeuds A, B, C, et des arcs A->B, B->C et A->C. L'arc A->B sera annoté avec "cond" et l'arc A->C avec "not cond".
          
          On comprend vite que sur un programme ou sous-programme non-trivial, la combinatoire est explosive.

          • [^]Re: Compilation lente <=> Analyse de flot

            Posté par Thomas Douillard () le 04/11/2006 à 17:47. (lien). Évalué à 2.

            On comprend vite que sur un programme ou sous-programme non-trivial, la combinatoire est explosive.

            
            
            Pas moi en tout cas : sur ton exemple, on a 3 blocs de codes, et 3 noeuds et 6 arcs, en O(2*n) en fonction du nombre de ligne de code au pire, linéaire donc.
            
            Si ce schéma est imbriquée dans d'autres structures, il ne sera pas reproduit dans mon idée des graphes de flots en tout cas.
            
            bloc A'
            while ( cond1) do
            /* Ton bloc if */
            done
            bloc B'
            
            ca rajoute deux noeuds, 3 arcs, c'est tout.
            
            Je vois donc pas ce qui peut êxploser de ce côté, sauf si il y a reproduction de ces structures quand ce sont des fonctions, genre inlining en C++.
            
            Donc je crois pas que le graphe en soit bouffe tant d'espace.
            
            L'analyse de flot, qui est censée traiter tous les chemins possibles c'est évidemment différent. Dites moi si (où sûrement ;) ) je me trompes.

            • [^]Re: Compilation lente <=> Analyse de flot

              Posté par Ontologia (page perso, ) le 06/11/2006 à 09:00. (lien). Évalué à 3.

              Dans une analyse de flot profonde, on étudie non pas le graphe du code, mais le graphe des exécutions possible du code, comme l'expliquait Antoine et Reno. La combinatoire explose donc très vite.
              
              Avec un code du style
              
              Bloc A
              if (cond1)
              _ if (cond2)
              _ Bloc C
              _ else
              _ Bloc C'
              else
              _ Bloc A''
              end if
              Bloc B
              
              Dans ce genre de cas (fréquent), tu cherches à analyser l'ensemble des intervales de valeur dans lesquels peuvent se trouver tes variables (n'oubli pas que ton code est réduit selon les primitives que j'ai donné plus haut), en effet, il faut faire des suppositions sur les chemins d'exécution pour détecter ceux qui ne seront jamais pris, malgré les apparences.
              
              Avec deux boucles imbriqués, tu dois tester le devenir de toutes les variables du bloc A en fonction des branchements sur cond1,cond2.
              En d'autres termes, à cause de ces deux if imbriqués, tu es obligé de représenter 4 évolutions possible des variables du bloc A, afin de détecter les intervals possibles, etc..
              Posons par exemple que tu déclares une variable n := n*2+1 dans le bloc A...
              Tu as 4 évolutions possible de cette variable n, qui peuvent avoir des conséquences dans le code. Ce qui signifie que tu dois (si n est modifié dans plus d'une des 4 branches de test) représenter toute la suite du graphe orienté en 4 versions (!).
              
              Imagine quand tu as 5, 20, 50 niveau de test imbriqués avec des énormes blocs de code à l'intérieur... Ta combinatoire explose.
              
              Ai-je été clair ? :)

              • [^]Re: Compilation lente <=> Analyse de flot

                Posté par Thomas Douillard () le 06/11/2006 à 09:23. (lien). Évalué à 2.

                Hum, je suis pas sûr de ça, le graphe en lui même à pas nécessairement besoin d'être changé AMHA, seules les valeurs des variables (des intervalles si c'est traîté comme ça) ont besoin d'être modifiées en fonction des cas rencontrés.
                
                Bon, ok il reste clairement une exponentielle là dedans, mais je comprends pas pourquoi elle est nécessairement dans le graphe lui même.
                D'ailleurs, ici on a pris le cas des conditionelles, qui est simple, mais on fait comment dans le cas des boucles ? on déroule tout au fur et à mesure ? on peux pas savoir "à priori" combien on devra en dérouler, si on construit au fur et à mesure, ni même si l'algo se termine dans le cas de boucles potentiellement infinies.

                • [^]Re: Compilation lente <=> Analyse de flot

                  Posté par Ontologia (page perso, ) le 06/11/2006 à 09:28. (lien). Évalué à 2.

                  Ne pas oublier l'implications de changement de valeur de variable sur quelques centaines de lignes de code. Ne pas oublier non plus que ce n'est pas tellement le graphe du code qui bouffe de la mémoire, mais toutes les informations sur celui-ci (graphe de dépendances, intervales possibles de valeurs de variables, etc...)
                  
                  Quand au boucle, elles reviennent à un if avec un goto.

• [+] [^]Re: Compilation lente

  Posté par Nicolas Cornu () le 03/11/2006 à 08:34. (lien). Évalué à -1.

  Il fera pas bon d'être un p'tit pentium III...

[+] On est vendredi ou bien ?????