Un autre compilateur Java générant du code natif x86

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
17
oct.
2001
Java
Ca vient de sortir en version 1.0, Manta dépend de gcc 2.95 ou supérieur, X Window, libjpeg, libungif et libgmp (Linux et un processeur x86 aussi). De plus ce nouveau compilateur natif a le bon gout d'être publié sous LGPL.



Les points importants sont que ce compilateur supporte les spécifications 1.1 du langage, qu'il a pour but d'exploser (en terme de performances) les autres implémentations de compilateur natif Java et surtout il contient une implémentation efficace de RMI conforme au standards de Sun!



Bref, si il a pas une tête de gagnant celui-la...

Aller plus loin

  • # First troll

    Posté par  . Évalué à -10.

    Franchement, java ça pu. Quel interet de faire un compilo rapide. Sa peu faire croire aux gros porc qui programment en java qu'ils font de l'informatique.

    • [^] # Re: First troll

      Posté par  . Évalué à -8.

      Bon alors la prochaibe fois tu postes en -1
      Et la prochaibe fois, l'autre con qui a voté [+] s'abstient.

      Ceci-dit, c'est vrai que Java c'est pas ce qu'il y a de plus rapide quand on ne sait pas programmer, ce qui semble être ton cas.

      • [^] # Re: First troll

        Posté par  . Évalué à -5.

        Attrapé. marche bien mon piége à troll.

        • [^] # Re: First troll

          Posté par  . Évalué à -4.

          Oui, et toi aussi.
          On peut allé loin comme ça.

          ça me rappelle mon enfance ...

        • [^] # Re: First troll

          Posté par  . Évalué à -4.

          Non, mais ca t'amuse de pourrir ce site avec des commentaire de merde, juste pour joué. Toi aussi, tu fait des alertes à la bombe trois fois par semaine pour ne pas aller en cour de maths ?

          Tu mérite une féssée déculottée ! Retourne a l'ecole, tu dira moins de connerie !

          • [^] # Re: First troll

            Posté par  . Évalué à -8.

            Euh...

            s'il y en a un qui doit retourner à l'école, c'est bien toi.

            L'orthographe, c'est pas ton fort.

          • [^] # Re: First troll

            Posté par  . Évalué à -7.

            La prochaine fois que tu te réponds à toi-même, évite de reproduire les mêmes fautes, parce que ça va se voir, là.

    • [^] # Re: First troll

      Posté par  . Évalué à -9.

      Parce que toi, tu es un vrai programmeur ! Tu ne manges pas de quiche, et tu codes directement en langage machine, c'est plus rapide (a moins que ce ne soit en Visual Basic, encore mieux).

      • [^] # Re: First troll

        Posté par  . Évalué à -6.

        Chouette une deuxiéme prise dans le piége.

    • [^] # Re: First troll

      Posté par  (site web personnel) . Évalué à 10.

      Oui et non ...
      Déjà il ne faut pas faire l'amalgame entre java langage, et java plateforme...

      En tant que plateforme, c'est vrai qu'actuellement les implémentations tenaient rarement la route en termes de performances. Et pour cause, quand on voie à quoi ressemble de bytecode java, on comprend les difficultés à faire une VM potable (genre je te refais un assembleur sans registres et uniquement à pile)

      Maintenant, en tant que langage, java est un langage comme un autre avec ses charmes et ses défauts. Sans dire qu'on atteint l'apothéose (en particulier avec sa gestion plus que gourmande de la mémoire), on peut arriver à faire de vraies applications plutot propres sans trop s'embrouiller.

      Quant aux "gros porcs", ils ne programment pas qu'en java, et je ne connais pas encore de langage qui interdise de programmer comme un gros porc.
      Personnellement, je pense qu'avec ces compilos natifs, java pourra peut être (enfin) justifier sa place pour des applications coté serveur sur des bécanes un peu plus modestes...

      • [^] # Re: First troll

        Posté par  . Évalué à -5.

        Mince, c'est quoi ça? Faut faire attention, c'est un piége à troll. Tu risques de te faire mal aux XP.

      • [^] # Re: First troll

        Posté par  . Évalué à -2.

        ADA permet d'eviter de programmer comme un gros porc comme tu dis.

        • [^] # Re: First troll

          Posté par  . Évalué à -1.

          Pas d'accord : en Ada comme dans tout autre langage tu peux programmer comme un gros porc : j'ai déjà vu des gens coder uniquement avec les types de base non surchargés et avec des System.Address et des 'Address dans tous les sens, et j'en passe et des meilleurs ...

        • [^] # Re: First troll

          Posté par  . Évalué à 7.

          Ada (et non pas ADA) impose effectivement certaines règles de programmation comme le typage fort, la séparation spécification / corps, etc.

          Cependant, j'ai suffisament vu de code Ada super crade pour pouvoir t'affirmer qu'il est tout à fait possible de programmer comme un porc en Ada.

        • [^] # Re: First troll

          Posté par  . Évalué à -4.

          Le problème avec Ada, c'est que si tu programme vraiment "dans la logique", ça devient illisible.

          Finalement, Ada est pire que le mal.

          • [^] # Re: First troll

            Posté par  . Évalué à -3.

            Ce n'est pas vrai non plus. Un code Ada correctement écrit est certes très verbeux, mais parfaitement clair et facile à maintenir.
            As tu déjà essayé ? (je veux dire, plus d'une demi journée.)

        • [^] # Re: First troll

          Posté par  . Évalué à 4.

          Euh, j'ai connu un programmeur Ada (un vrai, un poilu) qui faisait du code Ada incomprehensible. Heureusement que son projet est passé à la poubelle, j'aurais plein les malheureux qui auraient eut a le maintenir.

          Depuis il fait du C++, il est content, il peut faire pire.

        • [^] # Re: First troll

          Posté par  . Évalué à 4.

          En Ada, il y a des goto...
          Véridique.

      • [^] # Re: First troll

        Posté par  . Évalué à 0.

        Et si la force de Java se mesurait en terme de compétences?
        - La plupart des nouveaux diplômés sont Javaïsés: débutant=>"moins cher" et "déjà formé"=>"moins cher"
        - Une IHM a faire? La plupart de developpeurs Java sont formés a Swing ("pas de temps d'adaptation"="moins cher") Alors qu'en C: Qt? GNOME? MFC? MOTIF?

    • [^] # Re: First troll

      Posté par  . Évalué à -2.

      Toi tu es un véritable. Tu passerais des heures à réécrire une fonction d'affectation d'entier siplement pour qu'elle soit belle.

      Mais pendant que tu te tire la nouille sur des conneries, il y a des gens qui bossent, qui font des programmes qui doivent être utilisé, pas un tas de merde imbitable d'un crétin persuadé que l'amiga est le summum de l'informatique.

      Reste dans ta grotte, tant que tu n'en sors pas au moins, tu fait pas chier les gens serieux.

      • [^] # Re: First troll

        Posté par  . Évalué à -2.

        Ah cette fois c'est un vrai troll. Et de 3.

      • [^] # Re: First troll

        Posté par  . Évalué à -2.

        Dommage, ta réponse ne peut pas être prise au sérieux.
        En effet, les gens sérieux ne lisent pas DLFP.
        Et quand ils le font (par hazard ou sous la contrainte), ils ne répondent jamais à un troll, surtout auto-proclamé.

        Bien sûr, il y a les décideurs /

    • [^] # Re: First troll

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

      >Sa peu faire croire aux gros porc qui programment en java qu'ils font de l'informatique
      Bon, outre les fautes d'informatiques qui font penser à http://techmag.net/1_Michel_-_Ingeniformaticien.mp3(...) dans toute sa splendeur, tu devrais savoir que java n'est pas un langage de "gros porc", c'est même tout le contraire. Java n'est peut être pas LE langage (mais quel langage peut en dire autant), cependant, il permet au développeur de se concentrer sur les algorithmes et la beauté de la construction. Or, saches que c'est ce qui fait la puissance d'un programme bien avant l'optimisation du code généré par le compilateur. Si tu codes comme un porc en C pur, ton programme pourra être mille fois moins rapide qu'un programme java bien codé avec une complexité moindre. D'ailleurs, contrairement à une idée répandue, le fait de très peu réutiliser de code en C par exemple a plutôt tendance à plomber les perfs. (à mon avis, si tu implémentes une table de hashage en C toi même, elle sera sans doute bien moins rapide qu'en java où elle a été bien optimisée).
      Je ne parle même pas de la réutilisation du code, un axe majeur en java du développement.

      • [^] # Re: First troll

        Posté par  . Évalué à -3.

        Chouette un gros morceau est tombé dans le piége et en plus c'est un troll qui dance la java. Je sens que je vais le hacher avec la table, ça sera plus optimisé.

      • [^] # tout a fait d'accord sauf que...

        Posté par  . Évalué à -2.

        bah ouais sauf qu'il y a une faute de frappe:
        il ne faut pas lire java mais perl !

        et au passage et pour la derniere fois:

        JAVA N'EST PAS STANDARD!

      • [^] # Re: First troll

        Posté par  . Évalué à 0.

        Et pourquoi est-ce que les gros porcs n'auraient pas le droit d'avoir un langage à eux. Il faudrait un compilo qui se charge de transformer du source degeu en code optimisé ! Dans un monde libre, on est en droit de revendiquer la liberté de pouvoir programmer comme un gros porc (des fois, ça fait du bien et ça fait quelque chose à raconter à la machine à café...)

      • [^] # Re: First troll

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

        > D'ailleurs, contrairement à une idée répandue, le fait de très peu réutiliser de code en C par exemple a plutôt tendance à plomber les perfs.

        T'es sur de ta phrase là ? :-)

        > (à mon avis, si tu implémentes une table de hashage en C toi même, elle sera sans doute bien moins rapide qu'en java où elle a été bien optimisée).

        Non, ta hashtable sera plus rapide qu'en Java, à moins vraiment d'être un gros mauvais mais :

        - faut vraiment avoir que ça à foutre pour implémenter une hash-table en C, pourquoi pas des listes chainées aussi ?

        - appelée d'un programme Java, le gain de perf sera quasi-nul voire négatif (un pote à moi avait essayé), parce que le goulot d'étranglement c'est JNI :-).

  • # moui

    Posté par  . Évalué à 8.

    > qu'il a pour but d'exploser (en terme de performances) les autres implémentations de compilateur natif Java

    étant donné qu'il est en version 0.1, on peut raisonnablement estimer que le but n'est pas encore atteint..

    • [^] # Re: moui

      Posté par  . Évalué à 10.

      A ce propos, si un modérateur pouvait corriger la nouvelle : c'est donc en version 0.1 et pas en 1.0
      et d'apres Freshmeat en GPL et non LGPL.
      (je n'ai pas trouvé la licence sur le site et je n'ai pas téléchargé le code)

      A+

  • # bytecode natif ???

    Posté par  . Évalué à 10.

    Euh... faudrait m'expliquer, soit tu génères du bytecode, soit du code natif, mais du bytecode natif je connais pas...

    aller hop, -1 et anonyme

  • # Mwarf !!

    Posté par  . Évalué à -1.

    Quand on voit la date de dernière mise à jour, on peut se poser des questions !!!

  • # *ware

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

    vaporWare, theoryWare, videloanWare, quel va etre l'evolution de ce produit ?
    La question essentielle est surtout: est ce que ca marche ?

    Sans benchmark, on peut surement faire la même annonce: La question est alors: trouver un algo pour passer de Manta a i2bp

    • [^] # Re: *ware

      Posté par  . Évalué à -4.

      Tu y es pas, c'est i2bp qui a utilisé manta pour compiler leur player

    • [^] # Re: *ware

      Posté par  . Évalué à -2.

      A-ware, une nouvelle technologie qui permet des taux de compressiosn de 69/1 tout en étant natif-bytecode et évidemment cross-compiling.

      Je sais ce que c'est, je fais partie de l'équipe de décideurs qui ont investi dans cette révolution informatique.

    • [^] # Re: *ware

      Posté par  . Évalué à -2.

      peux tu m'expliquer le terme de VideolanWare ?
      Par simple curiosite :-)

  • # Version 1.1 de Java

    Posté par  . Évalué à 10.

    Bon, je veux pas dire, mais Java 1.1 c'est l'antiquité. Tout le monde est en 1.2 ou 1.3, et se prépare au 1.4.

    C'est comme d'annoncer qu'on vient de faire un réimplémentation libre de DirectX 2 ou de Fortran 66: C'est bien en soi, mais pas vraiment utile.

    • [^] # Re: Version 1.1 de Java

      Posté par  . Évalué à -2.

      Tout a fait d'accord ...

    • [^] # Re: Version 1.1 de Java

      Posté par  . Évalué à 2.

      En meme temps, on peu comprendre que le projet à pris du temps et qu'il a bien fallu se poser sur un version...
      Wait & see donc...
      Thoms

    • [^] # Re: Version 1.1 de Java

      Posté par  . Évalué à 6.

      Les librairies ont changés, mais le langage très peu, et la machine virtuelle quasiment pas.

    • [^] # Re: Version 1.1 de Java

      Posté par  . Évalué à 10.

      Non ! Il ne faut pas confondre version 1.1 du LANGAGE Java, et version 1.1 de la PLATEFORME Java.
      Je dirais même, pour être complet, qu'il ne faut pas non plus confondre avec la machine virtuelle Java et son bytecode associé.

      Je vais donc résumer rapidement les 3 entités :
      - le langage Java est l'ensemble de règles syntaxiques à respecter pour coder en Java. Pour simplifier, il s'agit du format du fichier source.
      - la plateforme Java est l'ensemble des classes qui sont utilisables par une application Java (application indépendante, applet, servlet, JSP, JavaBean, EJB ...). Dans cet ensemble, il y en a qui sont obligatoires (dans les sous paquets de java.*) et d'autres qui sont optionnels (les autres paquets).
      - le bytecode Java est le format de fichier utilisé pour le code précompilé. Il est ensuite utilisé par la JVM, ou machine virtuelle Java. Il faut bien comprendre le du bytecode n'est pas forcément généré à partir de code Java (j'ai entendu parler d'un compilateur de bytecode à partir d'Ada).

      Actuellement, la version du langage est la 1.1. Cette version a été introduite dans le JDK1.1 (d'où la confusion possible ...)
      La version de la plateforme est la 1.4 pour la version standard J2SE (implémentation de référence béta pour l'instant) et la 1.3 pour la version entreprise J2EE.
      La version du bytecode a changé à chaque version de JDK/SDK. On peut s'en convaincre en regardant l'option -target de javac qui peut prendre les valeurs 1.[1234].

      En ce qui nous concerne dans cette nouvelle, il s'agit de la version du langage qui est importante. Hors, la 1.1 est la dernière, bien qu'elle existe depuis le JDK1.1 ...

      • [^] # Re: Version 1.1 de Java

        Posté par  . Évalué à -1.

        - le langage Java est l'ensemble de règles syntaxiques

        j'aurais plutôt parlé de sémantique que de syntaxe mais bon ...

      • [^] # Re: Version 1.1 de Java

        Posté par  . Évalué à 1.

        mmmh ...

        je peux compiler mes class 1.4 sur un compilateur supportant la plateforme 1.1 donc ?

        • [^] # Re: Version 1.1 de Java

          Posté par  . Évalué à 2.

          Si tu as à ta disposition une implémentation des classes de la version 1.4 du SDK, ça ne devrait normalement pas poser de problème. C'est ce qui est fait par exemple avec Jikes qui n'est qu'un compilateur ; comme il ne contient pas d'implémentation des classes de base, il faut lui spécifier où les trouver (en ligne de commande ou par la variable d'environnement JIKEPATH).

          Maintenant, il faut savoir qu'il existe des compilateurs Java qui ne sont pas capables d'utiliser d'autres classes de base que celles pour lesquelles ils ont été prévus. Cela t'empêche alors d'imposer tes propres classes.

          Mais je ne connais absolument pas Manta, alors je ne peux pas dire ce qu'il en est dans ce cas ...

  • # Mais quel interet...

    Posté par  . Évalué à -10.

    de faire un compilo natif java alors qu'il existe des compilos natifs C/C++ bien plus performant ?
    En plus java c'est un langage proprietaire de SUN, le C/C++ est normalisé lui au moins.
    En plus vous en connaissez beaucoup des OS compatible Posix sous licence GPL écrit en Java ?

    • [^] # Re: Mais quel interet...

      Posté par  . Évalué à -2.

      Vite, la pancarte !! c'est urgent !!!

    • [^] # Re: Mais quel interet...

      Posté par  . Évalué à 0.

      http://image.pathfinder.com/time/daily/special/photo/halloween2000/(...)

    • [^] # Re: Mais quel interet...

      Posté par  . Évalué à 2.

      si je ne m'abuse, le langage n'est pas propriétaire., seule l'implémentation l'est. Et encore l'équipe qui s'occuppe de Blackdown a eu l'autorisation de distribuer leur implémentation en GPL (ou LGPL).
      Pour plus de détails va voir du côté de la dernière Debian Weekly News

      • [^] # relie ta license

        Posté par  . Évalué à -1.

        sun peut te demander des royalties sur les softs
        que tu vends.

    • [^] # Re: Mais quel interet...

      Posté par  . Évalué à 3.

      >java c'est un langage proprietaire de SUN, le C/C++ est normalisé lui au moins

      Si c'est est troll, je saute dedans à deux pieds, quitte à eclabousser : Java est encore plus standard que le C, et bien plus que le C++.

      Je m'explique : java à été standardisé auprès de l'organisme de standardisation ISO. Le C auprès de l'ANSI et le C++... et bah non. c'est pas officiellement standardisé.

      ANSI : American National Standards Institute
      ISO : International Standardisation Organisation

      donc ISO>ANSI ==> Java est plus standard que le C.


      mais bon, c'était histoire d'écraser un troll, ça faisait longtemps :)

      • [^] # Re: Mais quel interet...

        Posté par  . Évalué à 4.

        J'avais oublié de préciser le contexte de la normalisation de Java par Sun :

        Vous vous souvenez, il y a deux ou trois ans, quand Microsoft avait sorti une JVM foireuse et propriétaire... et ben ca à tellement enervé Sun qu'ils ont fait tout ce qu'il fallait pour normaliser leur language. Ainsi, Microsoft ne pouvait plus ne pas respecter un standard ISO : une implémentation ne peut en porter le nom que si elle se plie au standard. Sun avait gagné une bataile.

        Le résultat, vous le connaissez : pas de jvm dans Windows XP.

        Moralité ? Si Microsoft n'arrive pas à s'aproprier un standard... il le rejette ?

        • [^] # oui mais SUN n'a pas pu devenir un standard!

          Posté par  . Évalué à 2.

          ILS SE SONT FAIT jeter par tous les organismes
          privés ou publics, à même de décrire le
          soit-disant "standard" java.
          Car ces gars qui font les expertises ont déclaré:
          qu'il avait été impossible pour eux de dégager quoi que ce soit de standard depuis les spécifications données par sun.
          en d'autres termes:
          SUN(C)JAVA(C) EST UN LANGAGE FERME ET PROPRIETAIRE

          <troll on>
          java est un standard => visualC++ est un standard
          la deuxieme partie de l'implication est fausse
          donc la premiere aussi.
          <troll off>

      • [^] # Re: Mais quel interet...

        Posté par  . Évalué à 5.

        Je vais écraser un troll qui écrase un troll, donc un énorme troll!!!

        C est standardisé ISO
        http://anubis.dkuug.dk/JTC1/SC22/WG14/(...)
        "The current C programming language standard ISO/IEC 9899 was adopted by ISO in 1999."

        C++ est en cours de standardisation
        http://anubis.dkuug.dk/jtc1/sc22/wg21/(...)

        Bon, j'ai cherché ca en vitesse donc merci de me corriger si je ne suis plus à jour.

      • [^] # Re: Mais quel interet...

        Posté par  . Évalué à 2.

        histoire d'enculer les mouches et d'apporter quelques précisions sur une erreur souvent commise :
        ISO ne signifie pas "International Standardisation Organisation" (ce qui d'ailleurs est de l'anglais incorrect, la version correcte etant "International Organization for Standardization") mais est un mot dérivé du grec et signifiant égal, ce qui tombe bien pour un organisme de normalisation et permet que le monde entier utilise le même nom.

        plus d'info sur http://www.iso.org/iso/fr/aboutiso/introduction/whatisISO.html(...)

        voila voila...

      • [^] # Re: Mais quel interet...

        Posté par  . Évalué à 1.

        Je m'explique : java à été standardisé auprès de l'organisme de standardisation ISO. Le C auprès de l'ANSI et le C++... et bah non. c'est pas officiellement standardisé.

        Mon cheval m'informe qu'il programme en C-ISO et non en C-ANSI. Oserais-tu le traiter de menteur ?

        • [^] # N'importe quoi

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

          Heu même pas vrai je suis sur.... D'ailleurs comment il fait pour taper sur le clavier avec ses gros sabots ? Moi je dis c'est du pur FUD.

      • [^] # Re: Mais quel interet...

        Posté par  . Évalué à 1.

        Bon sang, je n'ai jamais vu pareil immondice.

        Le C est normalisé ISO (ISO 9899:1999). Parler de C ANSI est ridicule parce que c'est une norme US. On pourrait également parler de C AFNOR (fr) vu qu'ils ont aussi ratifié la norme internationale ISO.

        Le C++ est normalisé ISO aussi (ISO 14882:1998).

        Enfin, peux-tu me donner la référence ISO de Java afin d'éventuellement avérer tes dires ? Merci.

        --gb

      • [^] # Re: Mais quel interet...

        Posté par  . Évalué à 1.

        Je me permet de corriger ta remarque :
        Le langage C a été normalisé en 1990 par l'ISO, qui a repris directement la norme ANSI (de 1989) donc ANSI C == ISO C et par habitude on dit ANSI C pour ISO C.
        D'ailleurs la nouvelle norme du langage C "ISO C99" est sortie est rajoute quelques extenstions comme la possibilités de déclarer des
        variables locales aillleurs qu'au début d'un bloc (et aussi, mais je n'en suis pas sur, d'utiliser les commentaires // à la C++
        )
        Il y a également des normes ISO pour le C++, mais peu de compilateurs (par exemple le compilateur de Microsoft a du mal avec les templates compliqués) supportent l'intégralité de la norme. Donc c'est comme si il n'y avait pas de norme du tout..

      • [^] # Re: Mais quel interet...

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

        De quelle couleur est le ciel sur ta planète ?

  • # portabilité ... *hum*

    Posté par  . Évalué à 5.

    Linux et un processeur x86 aussi

    Quelqu'un me rappel les objectifs de Java ?

    Il n'y a pas un problème, là ? Déjà qu'on a du mal à avoir des machines virtuelles sur certaines architectures, là on dit merde à tout ceux qui n'utilise pas un PC. Et pourquoi Linux ? Je ne vois pas ce qui doit absoluement être spécifique à un noyau dans un compilateur.

    J'espère néanmoins que cette "concurrence" sera bénéfique pour GCC (plus particulièrement GCJ).

    • [^] # Re: portabilité ... *hum*

      Posté par  . Évalué à 4.

      Quelqu'un me rappel les objectifs de Java ?

      Les objectifs de Java ou les objectifs de Sun ?

      Chacun fait et code ce qu'il veut.

      • [^] # Re: portabilité ... *hum*

        Posté par  . Évalué à -1.

        le monsieur evoquait bien sur le "write once run everywhere"

        -1 (ouverture de porte ouverte)

    • [^] # Re: portabilité ... *hum*

      Posté par  . Évalué à 3.

      et bien , tu garde la l'agréement de coder en java tout en permettant a ceux qui le désirent de le compiler en natif

      Chacun est libre non ?

      D'ailleurs j'ai demandé au dalai lama et il m'a répondu :

      "Java a comme objectifs ceux que lui donne"

      ;)

  • # et gcj

    Posté par  . Évalué à 4.

    sans vouloir lancer de troll (celui d'en haut suffit), j'aimerais savoir si gcj (qui m'a l'air plus aboutit) que manta est interessant à utiliser et si le code " machine généré " (on va dire comme ça) est pas trop goret.

    • [^] # Re: et gcj

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

      gcj par rapport à manta, je ne sais pas. Mais dans bien des cas, le programme tourne plus vite sur la jvm sun, que compilé par gcj (Programme avec beaucoup d'e/s et des exceptions). Maintenant bon, la compilation de java en natif, je ne trouve pas ca génial : tuer la portabilité pour un gain (ou souvent une perte) de performance minimine, moi je dit bof.

      Remarque : Il y toba et towerj (proprio) qui font la même chose que manta et gcj (j'ai pas les url sous la main)

  • # Bad Idea !

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

    Ce qui est bien avec Java(tm), c'est que si la JVM est bien ca peut pas planter réellement à l'exécution si le programme est pas pourri.
    Si on revient à exécuter du code natif, le programme peut de nouveau se rétamer comme une merde dès que par exemple il traite une E/S non testée.

    Pour moi c'est de la merde ces idées de Java compilé en natif. Programmez bien, et Java est suffisamment rapide (sauf pour les jeux :-( ).

    sdjkh sdfiuze^p qsospo spsdopodf qpi, non mais.

  • # bon gout ?

    Posté par  . Évalué à -1.

    « ce nouveau compilateur natif a le bon gout d'être publié sous LGPL. »

    Je ne comprend pas cette phrase. Et j'aimerais que ce type de prises de parti (bon goût) mélangées avec les faits soit expliquées (et non gratuites).

    Tout d'abord, si Manta dépend de gcc, ce compilateur ne pourrait pas être sous une licence non compatible avec le GNU GPL.
    Ensuite, pourquoi choisir cette LGPL alors que gcc lui est en GPL et ne s'en porte pas plus mal.

    A ce propos, la lecture de cette article vaux le coup d'oeil, je pense :
    http://www.gnu.org/philosophy/why-not-lgpl.fr.html(...)



    Sinon, on peut toujours se demander pourquoi de nouveaux projets sont lancés s'ils ont les mêmes objectifs et la même approche que d'autres projets libres (pourquoi ne pas participer ?).

    • [^] # Re: bon gout ?

      Posté par  . Évalué à 0.

      Sinon, on peut toujours se demander pourquoi de nouveaux projets sont lancés s'ils ont les mêmes objectifs et la même approche que d'autres projets libres (pourquoi ne pas participer ?).

      Comment toi, yeupou, peux-tu sortir une énormité pareille ?

      • [^] # Re: bon gout ?

        Posté par  . Évalué à 0.

        Je ne vois pas en quoi c'est une enormité. Mais je curieux de l'apprendre.

        Parce qu'a priori, je ne vois pas pourquoi ce Manta est apparu alors que ces auteurs auraient très bien pu contribuer à l'avancement de GCJ (par exemple).
        Si l'objectif de Manta est d'être très performant, j'imagine que c'est aussi le but de GCJ et d'une manière générale de tout les compilateurs, non ?

        Alors, où est l'énormité ?

  • # OUIN arretez de dire du mal de java :....(

    Posté par  . Évalué à 4.

    non je plaisante

    Je vous rappelle que java a également été conçu pour que l'implémentation du programme d'exécution puisse optimiser l'éxécution en compilant a la volée le pseudo code en code machine, le pb etant que cette optimisation prend du temps et est importante pour obtenir une bonne performance.

    Je mentionnerais HotSpot qui exploite ce qu'on appelle la compilation adaptative. Les applis executent en general de nombreuses fois certaines portions de code, dont le fonctionnement determine donc la performance de l'appli. HotSpot evalue a l'execution ( a mesure qu'il execute ) les parties repetées souvent et les compile en code machine.... et comme il ne compile qu'une petite partie du code il laisse le temps a son optimisation.

    Avantage : il peut effectuer des optimisation a l'execution ce qu'un compilateur statique ne permet pas.

    Pour revenir sur 'Java sux' ... forcement si tu code tout en assembleur ca ira beaucoup plus vite ... je te laisse a ton assembleur, tu me rappelle quand tu as fait une appli actuelle en moins de deux ans

    De plus java est lent , mais ca dépend pourquoi, et un prog java bien foutu ca fonctionnera tres bien, comme un prog java mal foutu ca ramera
    ( note : c'est ce que disent les developpeurs java ;)

    j'ai fini

    Allez y , moulez maintenant ;)

  • # x86

    Posté par  . Évalué à -1.

    Je trouve ke c pas tres clair, le but de java a la base c'est d'etre executable sur n'importe kel becane qui a une vm, puisque c'est la vm ki execute le code (grosso modo).
    donc ke les vm soit lentes ok, mais ke des compilo 'java' genert du code x86 ca revient a dire ke je fait un exec c++ , genre ???
    or ca n'a plus rien a voir avec du java...
    ou alors je comprend pas la news.
    kk1 a des infos clair la dessus ?

    • [^] # Re: x86

      Posté par  . Évalué à -2.

      >Je trouve ke c pas tres clair...

      Ton écriture IRC ne l'est pas non plus, ce que tu dis est peut-être intéressant mais je ne lirais pas.

      kk1 pe t gréfé 1 cervo?

  • # SmallEiffel

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

    The current distribution includes an Eiffel to C compiler, an Eiffel to Java bytecode compiler, a documentation tool, a pretty printer and various other tools, with their sources.

    ba oui, pourkoi pas utiliser un langage independant et le transformé en C ou en bytecode java,...

    en voila une bonne idee (en plus le langage effeil est connue pour etre un langage objet tres bien foutu)

    http://www.loria.fr/projets/SmallEiffel/(...)

Suivre le flux des commentaires

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