Reprise du message précédent :
heuh nan je peux pas laisser passer ca, mon honneur d'expert est en jeu, le compilo java (java=>bytecode) optimise que dalle, rien, quequette

 
Je me lève, et je confirme, c'est le role du JIT de faire ça, afin d'optimiser différemment suivant la plateforme.

Voici quelques définitions extraites du "Dictionnaire des développeurs":
http://dico.developpez.com/html/
 
Java
en  np.
Langage de programmation orienté objet. propriété de la société Sun Microsystems. Langage multiplateforme grâce à un bytecode commun pour toutes les platesformes. Ce bytecode est interprété par la JVM installée sur le système hôte.
 
langage interprété
fr  n. m.
Langage de programmation dont le code source est interprété et non pas compilé. C'est-à-dire que chaque ligne est analysée et exécutée à la volée par un interpréteur.
 
Les langages interprétés sont portables car ils évitent la production d'un programme compilé dont le code exécutable est spécifique à une architecture particulière. La programmation de tels programmes est également plus rapide (la phase de compilation est souvent longue).
 
langage compilé
fr  n. m.
Langage de programmation dont le code source est compilé par un compilateur afin de produire un code exécutable.
 
compilateur
fr  n. m.
Programme réalisant la compilation du code source d'un programme. Le code exécutable ainsi produit sera spécifique et optimisé pour le microprocesseur pour lequel est conçu le compilateur.
 
code exécutable
fr  n. m.
Suite d'octets, généralement une portion d'un programme compilé, compréhensible par l'ordinateur et réalisant une tâche.
 
interpréteur
fr  n. m.
Programme qui interprète le code source d'un programme ligne après ligne. Contrairement à un compilateur, il ne produit pas de code exécutable sauvegardé dans un fichier. La transformation du code source en code machine se fait à la volée et est exécuté ligne après ligne. Ceci a pour effet de ralentir l'exécution du programme : un programme compilé est plus rapide qu'un programme interprété.
 
JIT  (Just In Time Compiler)
en  acr.
Compilateur qui convertit le bytecode en code natif pendant l'exécution du programme. Il en résulte une amélioration de la vitesse de l'application, le code n'étant alors plus interprété par la JVM.
Il est possible de le désactiver pour améliorer les stack trace pour le débuggage.

 
 
jpense on a fait avancer le debat, la

C++ vs Java => le putain de troll mythique

oué jai entendu que le java est tres utilisé pour les telephones portable etc...
mais bon, plus un langage est bas niveau, plus il aura une durée de vie élévé...
Par exemple l'assembleur existera toujours a moins qu'il y ait un tres gros chamboulement dans le monde de la micro informatique (quand les pcs fonctionneront sur un autre principe quoi)..
 
Le c++ est un langage tres bas niveau, et a prioris il sera tres dificile qu'un autre langage de meme niveau  puisse le concurrencer car le c++ a été bien pensé, existe depuis des decennies et des milliers de biliothequent existent pour c++... cependant depuis 7ans le langage est de moins en moins utilisé mais selon des experts la baisse devrait se stabiliser car on aura toujours besoin, d'un langage bas niveau pour une maitrise parfaite de ce que l'on veut faire.
 
Le java est un langage legerement plus haut niveau mais tres bien pensé là aussi, par contre son avenir reste toujours incertaines, il a été créer il y a une dizaine d'année si mes souvenirs son bon, c'est un langage qui a été tres utilisé en 2000-2002 si mes souvenirs sont bon, mais son utilisation a tres legerement baissé ces derniers temps meme si le taux reste tres fort (neanmoin bcp plus faible que le c++)
 
LEs autres langage plus haut niveau par contre n'ont quasiment aucune chance de durer plus de 20ans meme les derniers comme le php ont une esperence de vie bcp plus faible que le c++ ou asembleur... plus un langage est haut niveau plus il est lent mais plus il est possible de faire mieux...

 
On peut maitriser ce que l'on fait avec java    
 
Et essaie de garder exactement le meme code entre linux/windows/mac/BSD et j'en passe.
 
C++ c'est sympa, mais le code dépend de la machine. On aura toujours besoin de l'assembleur c'est vrai, du c++ surement aussi, mais ca veut pas dire que ca sera utilisé à grande échelle.
 
Et ta distinction langage bas/haut niveau n'a pas lieu d'etre, les usages sont différents.

 
Et merde, j'ai explosé de rire !
 
Non, le C++ est le pire langage au niveau de la construction. Sa grammaire est calamiteuse, sa norme ouverte à plein de conneries, contenant des choses inimplémentables. Ses constructions de haut niveau allégrement explosables par celles bas niveau, permettant de faire facilement des effets de bord monstrueuse. Son système de production (compil + link) est également une horreur, laissant à des outils externes la garantie de construction saine des delivrables alors qu'il est le mieux placé pour savori ce qui se passe.
 
Aujourd'hui, devant des constructions logicielles de plus en plus complexes, de plus en plus importantes en taille, les langages de haut niveau sont la norme, car eux seuls permettent de gérer cette complexité sans s'emmeler dans la tuyauterie. J'attends avec impatience sa mort. J'attends avec impatience que l'on évolue, de la même façon que l'on est passé des cartes perforées aux langages de haut niveau.

je pensais avoir lu qu'on voyait des différences de perf final selon le compilo, c'était peut-être genre pondre du bytecode plus digeste pour un JIT bien précis, c'est pas une petit optim ça ?  

bah tu regarderas le code que le compilo de sun genere pis vala hein ?

Pas vraiment non

Ratal, parce qu'il n'existe pas un unique assembleur, il y en a un par microprocesseur, et un ASM ne dépasse pas la durée de vie de son proco. Ca veut dire qu'il y a des ASM Z80, 68000, x86, PowerPC, ..., et que quand une lignée de processeurs devient obsolète l'assembleur associé l'est tout autant. Des langages plus haut niveau peuvent être placés en surcouche de dizaines de structures, donc d'assembleurs, différents et en être totalement indépendants

MAIS WAI §§§

Le LISP est probablement l'un des langages de plus haut niveau possibles, il est tellement abstrait que c'est une abstraction de langage. La syntaxe est très difficilement bitable parce qu'il a été créé en tant que théorie mathématique et non langage, mais bon...
 
Et le LISP date de 1965, et il est toujours vivant aujourd'hui
 
Donc tes langages haut niveau qui ne durent pas 20 ans, hein...

en même temps, si le LISP dure autant, c'est qu'il y a personne pour l'user

Ben s't'un langage de barbus mathématiciens quand même  
(j'ai halluciné quand j'ai vu que les calculs se faisaient en RPN)
 
Mais il n'empêche qu'il vit et survit, en dehors de son application à Emacs par exemple. Et en dehors de Lisp même il vit encore à travers ses dérivés (dialectes) genre Common Lisp ( http://en.wikipedia.org/wiki/Common_Lisp ) ou Scheme

 
 
C'est pas du RPN , RPN c'est 5 4 + , en Lisp c'est du ( enfin j'ai fait du scheme mais c pareil il me semble )
(+ 5 4)
 
et c'est -pas- drole a utiliser ( ca c'est rien, a coté du bordel sur les listes, cons & co ... )

 
 
tiens j'étais pourtant sur que le compilo faisait de l'inlining, ou simplifiait les constructions hasardeuses avec des String (genre remplacer toto = "a" + "b" + "c"; par toto = "abc" ), etc...

ouais bon y bricole ptet un peu ca, mais c'estpas ce que l'on apelle de la vraie optimisation d'homme

Ah oui, t'as raison, c'est juste du PN  
(et oui c'est pareil)

Il me semble qu'il transforme les séquences d'ajouts de string en StringBuilders aussi dans Java5, et d'autres conneries du style
 
Genre  

=>

UP (pour le sondage)

 
tu fais une recherche bordel ça à déjà été posé 10000 fois

ecoute pas push, il est frustré d'avoir jamais rien compris a la programmation en logo

mais ouais jte faisais des trucs de fous moi, ça partait dans tous les sens

segfault en logo

[3615 mylife] je sais plus ce que je faisais mais jme souviens que c'était dans un stage sport-info des années avant que j'ai mon C64    
 
et j'ai retrouvé le nom du jeux que je cherchais l'autre fois, le meilleur jeux de tous les temps  
 
 
http://www.geocities.com/paulemoz2 [...] Snare.html

<<===== java cay nul
 
faut etre neuneu pour espérer avoir un avis objectif sur le sujet en postant dans la cat C++

 
pour l'instant ptet pas non plus. une JVM ne sera jamais aussi performante qu'un compilo dédié a une architecture.
mais il est certain que l'ensemble de la chaine va énormément progresser.
 
d'un autre coté, question chaine d'outils, c'est justement le point faible du java et du .net, c'est assez fermé et la palette d'outils est restreinte....

C'est le principe même du JIT hein, le code est compilé en code natif (comme du compilé classique) au moment où il est parsé, c'est plus de l'interprétation c'est de la compilation en live  
 
Il y a bien sûr des inconvénients: plus grosses utilisation de mémoire et plus long temps de démarrage, mais les gains sont présents, légers sur des codes simples et extrèmement impressionants sur des codes récursifs (qui s'optimisent très bien en compilé, de plus il y a un overhead dans la mesure où le code est compilé et caché au moment où il est rencontré pour la première fois, mais cette compilation est réutilisée par la suite, donc plus un code est utilisé souvent et plus sa compilation est avantageuse)

d'autant que l'optimisation se fait en fonction des resources disponibles au runtime et non au compile time ce qui parfois peut donner du code plus rapide (mais bon, spa tous les jours non plus que ca arrive )

 
non, mais ta machine virtuelle, t'en as pas de spécifique pour A64, pour P3, pour P4, pour PM...
de plus c'est assez fermé, t'as pas vraiment d'autre choix que celle de Sun. hein t'as pas de JVM Intel, Amd, IBM (PPC)....
 
la chaine d'outils est super-pauvre en Java.
 
le Java est ptet bien, mais pour l'instant c'est pauvre, il a été poussé par un effet de mode, et maintenant la mode (à la con) du moment c'est le .Net.
je veux dire: quelle sera la prochaine mode ? imagine un mec qui a appris le Java, les tafs bougent vers le .Net, après ça rebouge vers autre chose.
le C++ a fait ses preuves dans la pratique en termes d'efficacité.
 
de plus Java comme .Net sont assez fermés (Sun / Ms), ce qui fait tache comparé au C++ qui a été fait de manière collégiale entre de nombreux acteurs, ce serait juste une API ce serait pas gênant que ce soit assez fermé, mais vu que c'est un langage + specif de chaine d'outil....

après ça dépends de ce que tu veux faire.
 
si c'est des applis légère clientes, tu peux te permettre (de perdre du temps machine) en java.
 
si tu veux faire du temps réel / traitement multimédia, C/C++ restent les langages prépondérant. (avec une touche d'asm non portable)
 
tout est une question de ce que tu veux faire.
 
maintenant c'est dépendant de ce que xav92210 veut faire, ou recherche comme taf plus tard...
 
si c'est accès services entreprise, web, système de gestion, il vaux mieux commencer direct par le java.
si le truc qui l'interresse/le motive intellectuellement c'est plus du multimedia / temps réel (ce qui est a mes yeux bien plus bandant, l'autre tendance c'est plus pour bouffer), il vaux mieux reste un poil plus bas niveau et s'attaquer au C/C++ pour saisir et tirer profit (ou plustôt savoir maitriser) un peu plus les contraintes architecturelles d'un ordinateur.

Il a surtout fait ses preuves en termes d'instabilité et d'inefficacité du temps du programmeur.
 
Le C ou le C++ c'est très bien pour créer un code rapide et prenant peu de mémoire, mais c'est pas avec ça que tu génèreras des projets rapidement et de manière fiable.

Le C++, au niveau du core du langage, n'a pas été fait "de manière collégiale entre de nombreux acteurs", pas plus en tout cas que le Java ou le C#, ou le Ruby ou le Python. Il a été défini par un petit noyau de concepteurs qui ont formalisé leurs idées  
 
La chaîne d'outils du C++? Quelle chaîne d'outils? ses compilateurs et ses débuggers? Ses dizaines de libs redondantes pour faire tout ce qu'il ne gère pas nativement?
 
Et pourquoi ne pas se tourner vers des langages qui ne nécessitent pas 15 logiciels différents pour pouvoir coder un "hello world" stable?
 
Pour en finir avec les JIT, vas te renseigner hein, c'est pas ma faute si du code passant dans un JIT bien fait atteint les ordres de grandeur de vitesse du compilé natif

Et si t'as un minimum de finesse, tu codes ton appli dans ton langage haut niveau préféré (Lisp, Java, Python, Ruby), une fois qu'il est terminé (en 10% du temps que ça t'aurait pris en C/C++) tu profiles, tu optimises, si c'est insuffisant tu recodes les modules nécessaires et time-critical en natif (classiquement, de l'ordre de 5% du code, ton architecture étant parfaitement modulaire et tes tests unitaires complets) et tu finis par une appli ayant 99% des perfs du natif pur générée en 20% du temps de conception

je crois qu'on parles pas de la même chose.

y'a quoi comme JVM 1.5 autre que celle de sun ?

ou en tout cas ce que l'un voit comme avantage, l'autre le voit comme un défaut.
 
quand aux jvm, file moi un lien, que je puisse faire tourner la cyboman en java sur un 486...

 
(oué enfin les debuggueurs ca n'est pas que pour degager un segfault, hein ? )
 

La tout de suite, celle de BEA?
(je ne suis pas certain que ce soit une JVM Java5, mais ça m'en a franchement l'air)
 
IBM en sont encore à la 1.4.2, mais je ne doute pas qu'ils sortirons également une JVM 5 d'ici quelques temps

 
pour toi du natif, c'est quoi pour toi, par rapport au java ? du C/C++ par exemple ?
si oui tu démontres que oui le java et sa jvm ne peuvent pas lutter contre une compilation pure via un compilo spécialisé.
 
je ne suis pas en train de te dire que le java est une merde comparé au C/C++, je suis en train de te dire qu'en termes de performances d'éxécution du compilé ciblé sera toujours au pire équivalent qu'une vm qui bouffe du bytecode.
 
après, si dans la notion de "performances", tu inclus l'économie de développement, le vitesse de livraison, et donc ta paye pour bouffer derrière, oui le java et le .net sont là pour ça.
 
mais si tu veux te faire plaisir intellectuellement (sans pour aller très loin) sur des themes précis, ou avoir tout simplement un truc qui rame pas sur une machine a 2Ghz sur d'autre thèmes, bin le C/C++ ont toujours des qualités.
 
   

Blackdown.

 
sur BEA on voit ca : Compatible with J2SE 1.4.1

 
ok you've got point.
 
ceci dit, jusqu'a présent j'ai toujours été déçu par tout ce qui était java sur des traitements lourds observés sur des trucs qui tentaient de faire des traitements lourds en java (ie graphisme surtout).
je ne dit plus qu'il commençe a enfin y avoir des jvm spécifiques, mais j'ai toujours des doutes a leur capacité a coller a ce que fait un compilo C/C++ même pas forcément spécifique.
 
mais bon dans le futur je dis pas... wait & see.