Beagle 0.2.1

• [^]Re: Beagle 0.2.1

  Posté par kaouete (page perso, ) le 30/01/2006 à 22:56. (lien). Évalué à 5.

  et hop, l'annonce pour ceux que ca interesse :
  http://mail.gnome.org/archives/dashboard-hackers/2006-Januar(...)

• [^]Re: Beagle 0.2.1

  Posté par dco () le 01/02/2006 à 11:15. (lien). Évalué à 2.

  Yep.... sortie de la version 0.2.0 le 21 Janv et la 0.2.1 le 30... C'est pas sympa pour les modérateurs ;)
  
  
  Juste le pourquoi de cette version éclaire (cf lien de kakaouete) :
  
  "The widespread exposure of our new user interface helped us uncover a handfull of bugs which are fixed in this release."
  
  traduction doc(tm):
  
  La grande diffusion de notre nouvelle interface nous a aidés à décourvrir une poignée de bugs qui ont été corrigés dans cette version

Interessant

• [^]Re: Interessant

  Posté par freeflight00 () le 31/01/2006 à 12:04. (lien). Évalué à 2.

  Pas que ma puissance CPU est limité, mais j'aimerais pas que mes ressources soient gaspillés

  
  Arrete de compter tes mégas perdus et compte le temps que tu gagnes ;)
  
  Quant au choix du langage, le libre, c'est également laisser le choix aux devs d'utiliser les outils qu'ils veulent... y compris ceux qui ne te parraissent pas optimisés.
  
  Néanmoins, c'est en utilisant un langage dans des rôles délicats et critiques qu'il se bonnifie. Si tu le cantonne a faire qu'un rôle, il ne risque pas de s'améliorer.
  
  Enfin, Beagle c'est en partie Nat Friedman et ses joyeux drilles de chez Novell (Icaza, etc...) qui sont les instigateurs de Mono. Ca m'aurait étonné qu'ils utilisent autre chose. Puis Beagle est quand meme un formidable outil de promotion du langage...

  • [^]Re: Interessant

    Posté par Gaetan_63 (page perso, ) le 31/01/2006 à 14:40. (lien). Évalué à 2.

    Je suis d'accord avec toi.
    
    Et je comprend pas les insultes des deux autres zigotos qui me prennent de haut. J'ai pas le temps de leur répondre autrement que par mon mépris, s'ils veulent des explications, je me ferais un plaisir de leur expliquer exactement mes connaissances en la matière, certes humble, mais qui couvre comment fonctionne une machine virtuelle (en fait uniquement les VM Java et .NET, certes pas celle de Mono), qu'est ce que la compilation dynamique, qu'est que le MSIL et à quel point c'est tout sauf Natif (c'est natif qu'après la compilation dynamique), ...
    
    Mon (humble) expérience me fait dire ceci: .NET ne me semble pas adapté pour un tel travail. Après je me goure peut être et je retourne à mon champs cultiver mes carottes.

    • [^]Re: Interessant

      Posté par TImaniac (page perso, ) le 31/01/2006 à 16:51. (lien). Évalué à 3.

      (c'est natif qu'après la compilation dynamique), ...
      Ben voilà t'as l'explication qui fou en l'air tout ton raisonnement : Beagle c'est un daemon, la compile JIT est effectuée pendant les première secondes, voir pas du tout si Beagle est compilé en natif avant (AOT), après le service tourne pendant toute sa vie de service en natif, c'est quand même le principal pour un daemon non ?

      --
      MonoFrance

• [^]Re: Interessant

  Posté par TImaniac (page perso, ) le 31/01/2006 à 12:57. (lien). Évalué à 1.

  Sans lancé un troll, je ne peux que me poser la question du choix du language (pseudo compilé, interprété dans une machine virtuelle)
  Pourquoi pseudo compilé ? Pourquoi interprété ? C# n'a pas été conçu pour être interprétable, et Beagle n'est PAS interprété. C'est du code natif qui tourne, aussi vite que ton code écrit en C ou n'importe quoi.
  
  Gaspillé par quoi? Par l'interprétation
  Y'a aucune phase d'interprétation. C'est pas du javascript !
  , par un garbage collector (
  Le GC a des inconvénients, mais aussi des avantages : il est capable de recycler la mémoire, il intervient aux moments opportuns (quand le CPU est peu utilisé par exemple). Tu pourras toujours reproduire le même comportement en C/C++ mais de façon très difficile. Et les projets bien "codés" comme tu dis utilises de plus en plus d'approches similaire, comme Apache qui gère une pile mémoire un peu comme un GC.
  
  qui te prend 200Mo parce qu'il a vu que j'avais de la place, et que si je lance un nouveau programme ca commence à swappé
  Ca c'est n'importe quoi. Lorsque les ressources mémoires sont trop faibles, le GC s'active et fait du nettoyage pour éviter justement de swapper inutilement.
  Le problème général n'est pas du au GC "qui bouffe de la mémoire" mais à la conception de l'application : en java ou C# on se permet parfois de bouffer inutilement de la mémoire en créant des millions d'objets impossible collecter par le GC : là tu bouffes de la mémoire et tu swappes. Mais tu le dis toi même : faut bien coder. Tu peux avoir exactement le même comportement en C/C++ en allouant plein de mémoire.
  
  Dsl pour le troll
  C'est rigolo les trolls, mais pour bien troller faut normalement faire semblant de partir sur des vérités pour ensuite dériver sur des conclusions par un raisonnement volontairement fallacieux. Toi tu pars direct avec des idées reçues déjà mainte et mainte fois tuées : C# n'est pas interprété et le GC ne bouffe pas de ressource, c'est le programmeur qui en demande trop.
  Enlève toi de la tête cette idée de machine virtuelle, ce n'est qu'un point de vu des compilateur et du développeur, à l'exécution il n'y a qu'un environnement d'exécution proposant des services (GC, sécurité, etc.) et un programme qui tourne en NATIF.

  --
  MonoFrance

  • [^]Re: Interessant

    Posté par gallenza () le 31/01/2006 à 15:48. (lien). Évalué à 2.

    Ta vision du NATIF pour une machine virtuelle me fait bien rire...

    • [^]Re: Interessant

      Posté par TImaniac (page perso, ) le 31/01/2006 à 16:52. (lien). Évalué à 1.

      Moi c'est plutôt votre vision VM == interprétation hérité de l'âge Java à ses débuts et autres langages de script qui me fait rire :)

      --
      MonoFrance

      • [+] [^]Re: Interessant

        Posté par gallenza () le 31/01/2006 à 20:05. (lien). Évalué à -7.

        Je comprends bien que quand on a à peu près que ça comme compétence on défende sa technologie, ça ne change rien au fait que c'est de la merde.

        • [^]Re: Interessant

          Posté par TImaniac (page perso, ) le 31/01/2006 à 23:26. (lien). Évalué à 3.

          Merci pour les compliments. On se connaît pour que tu puisses juger de mes compétences ? En quoi c'est "MA" technologie ? Enfin tu dois avoir raison même sans argument et avec des "compliments gratuit", puisqu'on te pertinente.

          --
          MonoFrance

• [+] [^]Re: Interessant

  Posté par boubou (page perso, ) le 31/01/2006 à 13:18. (lien). Évalué à -4.

  Si au moins il y a avait quelque chose d'intéressant dans ton post, par exemple des faits expérimentaux ou des sources pour les affirmations gratuites, mais non, rien, simplement une liste de choses fausses. Mais , ô miracle, ton commentaire est jugé pertinent ! Pertinent un message qui démontre que son auteur ne sait pas comment fonctionne une machine virtuelle et un garbage collector. Pitoyable serait plus approprié.

  • [^]Re: Interessant

    Posté par Gaetan_63 (page perso, ) le 31/01/2006 à 13:58. (lien). Évalué à 10.

    Je sais très bien comment fonctionne une machine virtuelle, merci c'est mon boulot. Je travaille sur Java dans l'embarqué, et j'ai déjà travaillé sur .NET auparavant en entreprise.
    
    Je ne donne pas de source expérimentale, certes, car on fait dire ce que l'on veut à des chiffres et surtout à des benchmarks (cf Apple).
    J'utilise tous les jours mon ordinateur et je constate pas mal de chose : les applications Java/.NET sont des bouffes mémoires.
    
    Ex: Freemind (programme que j'adore) me prend après une journée d'utilisation 80 Mo. ca te semble normal, toi?
    Eclipse, après quelques heures, me prend plus de 500 Mo. Toujours normal? Pourtant eclipse est un programme extraordinaire que j'adore, mais il me faut bien 1Go de ram pour être confortable avec.
    Visual Studio n'a jamais atteind une telle occupation en mémoire. A j'oubliais, je travaille aussi bien sous windows que sous linux.
    
    Et je vais pas faire un cour sur le fonctionnement d'une machine virtuelle, sur l'interprétation du byte code. Je suis conscient des avantages et inconvéniant de cette technologie, pour moi (humble avis), elle n'est pas adaptée pour un démon.
    
    Si vous me traitez de pitoyable, je vous execre Boubou, et vous laisse dans votre médiocrité. Soyez poli. Merci

    • [^]Re: Interessant

      Posté par LeMagicien Garcimore () le 31/01/2006 à 15:18. (lien). Évalué à 3.

      Je vais te dire un secret : la VM java et celle de .NET fonctionnent pas tout à fait de la même façon.
      
      Dans .NET, le code CIL est compilé en code natif avant l'exécution. C'est donc bien du code natif qui tourne.
      http://msdn.microsoft.com/library/default.asp?url=/msdnmag/i(...)
      
      La VM Java de sun est différente, elle compile en natif uniquement le code qui est souvent utilisé, le reste est interpreté.
      http://java.sun.com/j2se/1.4.2/docs/guide/vm/index.html
      
      Avant d'envoyer chier tout le monde, renseigne-toi. Un peu d'humilité, ça fait jamais de mal et ça evite de passer pour un couillon.
      
      (J'espère que j'ai pas dit de conneries moi :) )

      • [^]Re: Interessant

        Posté par boubou (page perso, ) le 31/01/2006 à 16:06. (lien). Évalué à 3.

        Disons que dans les deux cas, la machine virtuelle compile au vol quand elle pense que c'est utile. Comme l'assembleur .NET n'est pas facile à interpréter efficacement, tout est compilé au vol. En Java, c'est plus compliqué, mais les machines modernes compilent plus ou moins tout.
        
        Pour l'histoire de la mémoire, l'occupation parfois délirante des JVM n'est pas liée à la notion de machine virtuelle, mais à des défauts de Java : comme on ne peut pas créer de types non objet (contrairement à C#), on subit un overhead mémoire important pour tout ce qui n'est pas type fondamentaux (un Integer prend entre 12 et 16 octets, contrairement à 4 pour un int). Cet overhead est aussi lié à la présence d'un verrou dans chaque objet pour la gestion de la concurrence. Ces problèmes n'existent pas en C#.

        • [^]Re: Interessant

          Posté par Wajsberg Julien () le 01/02/2006 à 00:10. (lien). Évalué à 1.

          Permet moi de te contredire: les types dits "natifs" existent en Java, notamment "int" que tu cites...
          
          Et je pense pas que ce soit ces quelques différences avec C# qui changent grand chose, à vrai dire...

          • [^]Re: Interessant

            Posté par TImaniac (page perso, ) le 01/02/2006 à 08:08. (lien). Évalué à 2.

            Il existe des types primitifs en Java (types valeurs en C#) mais on ne peut pas en créer soit même, donc il a raison. En C# tu peux créer tes propres types valeurs (primitifs).
            L'intérêt, c'est qu'un type valeur est alloué sur la pile et non sur le tas, ce qui est est beaucoup plus efficace. Enfin faut bien voir que la pile n'a pas une taille infinie et que ces objets sont passés "par valeur", donc à utiliser quand c'est pertinent (ce qui est loin d'être le cas général).

            --
            MonoFrance

    • [^]Re: Interessant

      Posté par gnumdk () le 31/01/2006 à 15:25. (lien). Évalué à 4.

      >Et je vais pas faire un cour sur le fonctionnement d'une machine virtuelle,
      >sur l'interprétation du byte code. Je suis conscient des avantages et
      >inconvéniant de cette technologie, pour moi (humble avis), elle n'est pas
      >adaptée pour un démon.
      
      J'en sais encore moins que toi, mais il me semble quand meme que mono permet d'avoir soit du bytecode interprété soit du natif via un compilateur C# qui genere exactement la meme chose qu'un compilateur C, un gros binaire bien natif...
      
      Et il me semble que .Net permet cela mais la j'en suis encore moins sur...
      
      Voila, peut etre une explication sur le pourquoi tu te fais casser plus haut...

      --
      Venga Batucada

      • [^]Re: Interessant

        Posté par Bench () le 31/01/2006 à 16:55. (lien). Évalué à 9.

        Il se plaint de l'occupation mémoire et vous vous répondez sûr l'interpretation ou non du bytecode...
        Je suis d'accord avec lui, l'occupation mémoire d'un daemon Mono/C# est incroyablement plus élevée que celle d'un daemon en C/C++, à fonctonnalité équivalente. Et même si la théorie nous dit qu'un daemon Mono/C# peut fort bien rivaliser avec un daemon C/C++, la réalité est tout autre.

        • [+] [^]Re: Interessant

          Posté par boubou (page perso, ) le 31/01/2006 à 17:16. (lien). Évalué à -2.

          Non, il se plaint des deux. Et en plus, il donne des exemples d'occupation mémoire pour Java, ce qui est certe un problème mais 1) qui n'a rien à voir avec le fait que Java utilise une JVM 2) ne s'applique pas à C#/.NET.
          
          Voilà, gros pipo, comme toujours. Et au fait, quels exemples réels peux-tu nous donner d'occupation mémoire "incroyablement plus élevée à fonctionnalité équivalente" ? J'attends (un exemple en C#, pas en Java).

        • [+] [^]Re: Interessant

          Posté par Staz (Jabber id, ) le 01/02/2006 à 00:51. (lien). Évalué à -1.

          > Et même si la théorie nous dit qu'un daemon Mono/C# peut fort bien rivaliser avec un daemon C/C++, la réalité est tout autre.
          La réalité? quelle réalité? il n'y aucun deamon C/C++ à fonctionnalité équivalente à Beagle pour prouver tes dire.

          • [^]Re: Interessant

            Posté par Bench () le 01/02/2006 à 04:47. (lien). Évalué à 2.

            Relit la news... tu verra que Beagle n'est pas le seul à faire de l'indexation de fichiers pour effectuer des recherches par mot clefs...
            Entre autre Kat qui est, je te le donne en mille, ... écrit en C++

            • [^]Re: Interessant

              Posté par boubou (page perso, ) le 01/02/2006 à 11:29. (lien). Évalué à 1.

              Sur ma machine (sous la dernière mandriva), kat plante tout le temps après avoir occupé beaucoup de CPU et de mémoire. C'est un bon exemple, en effet.

      • [^]Re: Interessant

        Posté par Gaetan_63 (page perso, ) le 31/01/2006 à 17:09. (lien). Évalué à 5.

        Non, le compilateur de .NET ne compile pas du code natif, il compile du bytecode appelé MSIL (bon, ou CIL), qui est compilé dynamiquement au lancement de l'application par la machine virtuelle.
        
        Maintenant j'ai une question :
        Le code généré est-il (attention, je parle du code produit par le compilateur dynamique de Mono ou de .net) aussi performant "algorithmiquement" qu'un code C (donc issu de gcc, avec toutes les optimisation qu'il a jugé nécessaire de faire, quand tu lui donnes un -O2) ?
        J'aimerais trouvé un dump (assembleur x86) d'un traitement matématique écrit en C#, compilé en MSIL puis compilé en langage machine par Mono, puis par .NET (sous Windows). Pour voir si le code est aussi optimisé (dans ce cas précis) ...
        
        Juste my 2 cents.
        
        PS : il y a le compilateur Bartok qui compile le bytecode CIL en instruction x86 : http://en.wikipedia.org/wiki/Singularity_(operating_system)

        • [^]Re: Interessant

          Posté par TImaniac (page perso, ) le 31/01/2006 à 23:22. (lien). Évalué à 6.

          Non, le compilateur de .NET ne compile pas du code natif,
          C'est quoi le compilateur .NET ?
          Dans ces environnements il y a 2 types de compilateurs :
          - les compilateurs qui visent la machine virtuelles (C# --> MSIL ou Java -->bytecode)
          - les compilateurs qui visent le code natif (MSIL --> x86 ou bytecode --> x86)
          
          GCC fonctionne à peu prêt pareil : il a un frontend et un backend avec un langage intermédiaire propre à GCC. les frontend (ceux qui manipulent du C, du C++ ou jesaispasquoi) produise du code intermédiaire (ce sont des frontend), puis le backend s'occupe d'effectuer la compilation en code natif suivant la machine cible (x86 ou autre).
          
          Comme tu peux le constater sur le papier, c'est exactement le même fonctionnement. D'ailleur c'est pas pour rien que GCC est capable de compiler du Java, techniquement les 2 phases de compilations sont similaires dans leurs objectifs.
          
          Au final le code qui s'exécute EST du code machine x86 (ou autre) quelque soit la technique :
          - Pour le compilateur GCC, le code produit est par défaut systématiquement du code machine. Il est cependant possible de lui demander le code intermédiaire.
          
          Pour les environnement Java et .NET, la dernière étape de compilation (code intermédiaire --> code natif) est effectuée par défaut au dernier moment (Just-In-Time), au prix d'un chargement plus long mais d'une plus grande souplesse de déploiement, voir des optimisations supplémentaires : en effet, le runtime connaît exactement la configuration sur laquelle il tourne, il est alors capable d'effectuer des optimisations spécifiques, là où avec un compilateur "classique" comme GCC tu aurais été obligé de générer toute une série de binaire avec toutes les combinaisons d'optimisations possible, ou, plus généralement, t'aurais pondu un binaire optimisé de manière "générique".
          Maintenant, de la même manière qu'il est possible de modifier le comportement par défaut de GCC pour qu'il génère son code intermédiaire, il est possible de modifier le comportement par défaut de Java ou .NET/Mono pour qu'il compile directement en natif, bref pour qu'un binaire x86 arrive à la sortie.
          Tu sembles en douter, ben fait le test :
          Java :
          utilises GCJ, c'est son comportement par défaut
          Mono :
          mono -aot monprog.exe (AOT pour Ahead-Of-Time)
          Avec .NET :
          ngen monprog.exe
          
          Le code généré est-il (attention, je parle du code produit par le compilateur dynamique de Mono ou de .net) aussi performant "algorithmiquement" qu'un code C (donc issu de gcc, avec toutes les optimisation qu'il a jugé nécessaire de faire, quand tu lui donnes un -O2) ?
          Faut bien voir que même algorithmiquement identiques, des programmes écrits dans des langages différents ne peuvent être optimisés de la même façon, bien souvent à cause de la sémantique du langage. Le C est pas forcement le meilleur dans le domaine, puisque bien souvent il autorise tout et n'importe quoi, ne laissant pas vraiment de liberté au compilateur pour spécialiser un morceau de code.
          Ensuite un compilateur comme GCC peut très bien te pondre du code super-optimisé sur telle plateforme (x86) et super mal optimisé sur une autre plateforme (PPC) (je dis n'importe quoi c'est pour l'exemple).
          Il peut aussi y avoir de grosses différences entre les compilateurs, le compilo d'intel est par exemple beaucoup plus performant que le compilo GCC.
          
          Donc voilà comme tu peux le constater, c'est vraiment difficile de comparer. Mais techniquement, les problèmes d'optimisations sont les mêmes en C ou C#/Java. Ce qui va ralentir ton code, une fois de plus ce n'est pas le fait qu'il y est un code intermédiaire, mais le fait qu'il est des services associés : sercices de reflexion, de gestion de types, d'isolation et plus généralement de sécurité. Ces services fournissent de nombreuses fonctionnalités aux développeurs et peuvent avoir un coup en terme de performance.
          Ces services assurent une qualité de code supplémentaire non négligeable.
          Mais que va faire un "bon" programmeur C/C++ ? Il va chercher à acquérir les mêmes types de services (réflexion, gestion mémoire, etc.). Comment va-t-il faire ? Il va utiliser des outils pour (GC, etc.) ou alors il va réinventer la roue, avec de forte chances que le tout soit moins bien optimisé et avec autant de bugs potentiels. Quand à certains services, il ne pourra peut être même pas les "émuler", comme tous ceux liés à la sécurité.
          
          L'intérêt de plateformes comme Java ou .NET c'est de proposer ces services "en standard", avec une implémentation largement testée et éprouvée.
          
          Maintenant que certains préfèrent encore se passer de ces services et gagner quelques malheureux % de temps d'exécution au risque de passer un temps fou à réinventer la roue avec des bugs potentiels supplémentaires, ca les regardent, ca peut être parfois justifier (bas niveau), mais d'une manière générale ca l'est rarement. Ou si pour le "fun".
          
          Il faut également bien voir que les plateformes comme Java ou .NET proposent une grande quantité de classes en standards, celle-ci sont bien souvent optimisés et/ou font appels à du code natif quand c'est nécessaire.
          
          'aimerais trouvé un dump (assembleur x86) d'un traitement matématique écrit en C#, compilé en MSIL puis compilé en langage machine par Mono, puis par .NET (sous Windows). Pour voir si le code est aussi optimisé (dans ce cas précis) ...
          Si tu veux prendre un exemple "mathématique", j'ai envie de te répondre : plutôt que de passer 3 plombes en C à débugguer un segmentation fault ou autre fuite mémoire, moi je préfères affiner mon algorithme en Java en réduisant sa complexité. Ca c'est autrement plus efficace ;)
          
          Enfin si tu veux vraiment trouver un dump, ben utilise les méthodes que je t'ai expliqué au dessus (gcj, mono -aot et ngen) pour avoir une image native :) Mais bon visiblement t'y crois pas à ce fameux code natif avant exécution :)

          --
          MonoFrance

• [^]Re: Interessant

  Posté par reno () le 03/02/2006 à 22:14. (lien). Évalué à 2.

  > garbage collector (qui de facto utilise plus de mémoire (je rempli tant que j'ai de la place, je nétoi quand j'ai du temp ou plus de place) qu'un code C/C++ bien développé
  
  Ta vision des GC est un peu limité, il existe des papiers sur des GC qui dialogueraient avec la VM pour nettoyer suivant les besoins: plus de GC qui perdent des perf en sous-utilisant la mémoire ou pire qui font swapper en utilisant trop de RAM.
  Exemple: "Page-Level Cooperative Garbage Collection", maintenant j'ignores s'il existe des GC et des VM qui implémentent ça, je verrais bien ce genre de chose ajoutée à Linux par exemple.
  
  Le probleme dans ce que tu dits pour le C/C++, c'est le "bien développé", un bon exemple ou le C/C++ échoue c'est Mozilla/Firefox qui a tendance a bouffer de la RAM sans jamais diminuer, franchement à partir d'un certain niveau de complexité ne pas faire de fuite mémoire en C/C++ est très dur..
  Bien sûr avec un GC on remplace la fuite mémoire par la fuite d'objets si on ne fait pas attention, mais c'est quand même plus facile à gérer..
  
  A partir de la, j'avoue avoir une tres mauvaise experience de Java (même Sun n'est pas fichu de faire des appli Java graphique "legere" cf les outils d'admin dans Solaris9..) ou .Net pour les GUI, mais est-ce du au GC ou aux machines virtuelles?
  
  Difficile à dire, je n'ai jamais eu l'occasion de jouer avec des appli en language compilé avec GC..