lundi 13 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

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

Posté par Val (page perso, ). Modéré le 17 octobre 2001.
0
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...

> Lire les commentaires (103 commentaires, moyenne: 0,2).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

[+] First troll

Posté par Anonyme () le 17/10/2001 à 13:53. (lien). Évalué à -36.

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.

moui

Posté par Anonyme () le 17/10/2001 à 13:55. (lien). É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..

bytecode natif ???

Posté par Anonyme () le 17/10/2001 à 13:56. (lien). Évalué à 14.

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 Anonyme () le 17/10/2001 à 13:58. (lien). Évalué à -1.

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

*ware

Posté par Emmanuel Blindauer (page perso, ) le 17/10/2001 à 14:02. (lien). É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

Version 1.1 de Java

Posté par gle () le 17/10/2001 à 14:21. (lien). Évalué à 21.

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.

[+] Mais quel interet...

Posté par Anonyme () le 17/10/2001 à 14:35. (lien). É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 ?

portabilité ... *hum*

Posté par Anonyme () le 17/10/2001 à 16:06. (lien). É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).

et gcj

Posté par Benjamin Michotte (page perso, ) le 17/10/2001 à 17:08. (lien). É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.

Bad Idea !

Posté par VACHOR (page perso, ) le 17/10/2001 à 17:18. (lien). É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 gnap gnap (page perso, ) le 17/10/2001 à 20:19. (lien). É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 ?).

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

Posté par Roger Rabbit () le 17/10/2001 à 22:35. (lien). É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 psc () le 18/10/2001 à 00:55. (lien). É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 ?

SmallEiffel

Posté par Mathieu CLAUDEL (page perso, ) le 18/10/2001 à 05:48. (lien). É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/(...)

--
Collectif ski roumanie 2005

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.3254s (dont 0.0262 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !