> Java d'ailleurs n'accède pas aux ressources matérielles
Il n'y a que le noyau qui accède au matérielle. Mais hors noyau, il n'y a rien qui empêche de faire tout le reste en java (dont un équivalent de la libc). Si java est si rapide (même plus rapide de C selon "certains" benchs) alors pourquoi ne pas faire d'équivalent de la libc en java ?
La réponse est simple => trop lent trop gros. C'est valable pour tous les langages interprétés.
Puis notes que dans un noyau il n'y a qu'une petite partie qui est dépendante du matériel. La vm, les FS, le réseau, etc... sont généralement faites pour être indépendantes du matériel (heureusement).
> Si tu pousses ton raisonnement, "les compilateurs C++, c'est nul car en fait, ca transforme tout en assembleur" !!!!!
Relis bien, je dis qu'un langage interprété est forcément plus lent que la version compilée en native.
D'ailleur il y a aussi du langage C interprété. Et il est fort logiciquement plus lent. L'interprétation (même si c'est du bytecode) bouffera toujours du temps. C'est un fait indiscutable. De plus tu ne peux pas aller très loin dans l'optimisation à la volée car ça bouffe aussi du temps. Il faut forcément faire un compromis.
Lorsqu'il y a un bench Java qui prétend que java est plus rapide que le C ou le C++ il faudrait toujours donner le temps passé dans des librairie écrite en C ou assembleur et optimisé au petit oignon.
Je peux utiliser mplayer pour lire des DVD. Fais l'équivalent de mplayer en java (c-à-d réécrit tout mplayer et n'utilise pas de librairies C fournis par mplayer) et tu auras des performances lamentables.
NB : Je trouve que Java est un bon langage et rapide. Je m'énerve sur les benchs à la con et/ou leurs conclusions.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à -1.
Il n'y a que le noyau qui accède au matérielle. Mais hors noyau, il n'y a rien qui empêche de faire tout le reste en java (dont un équivalent de la libc). Si java est si rapide (même plus rapide de C selon "certains" benchs) alors pourquoi ne pas faire d'équivalent de la libc en java ?
La réponse est simple => trop lent trop gros. C'est valable pour tous les langages interprétés.
Puis notes que dans un noyau il n'y a qu'une petite partie qui est dépendante du matériel. La vm, les FS, le réseau, etc... sont généralement faites pour être indépendantes du matériel (heureusement).
> Si tu pousses ton raisonnement, "les compilateurs C++, c'est nul car en fait, ca transforme tout en assembleur" !!!!!
Relis bien, je dis qu'un langage interprété est forcément plus lent que la version compilée en native.
D'ailleur il y a aussi du langage C interprété. Et il est fort logiciquement plus lent. L'interprétation (même si c'est du bytecode) bouffera toujours du temps. C'est un fait indiscutable. De plus tu ne peux pas aller très loin dans l'optimisation à la volée car ça bouffe aussi du temps. Il faut forcément faire un compromis.
Lorsqu'il y a un bench Java qui prétend que java est plus rapide que le C ou le C++ il faudrait toujours donner le temps passé dans des librairie écrite en C ou assembleur et optimisé au petit oignon.
Je peux utiliser mplayer pour lire des DVD. Fais l'équivalent de mplayer en java (c-à-d réécrit tout mplayer et n'utilise pas de librairies C fournis par mplayer) et tu auras des performances lamentables.
NB : Je trouve que Java est un bon langage et rapide. Je m'énerve sur les benchs à la con et/ou leurs conclusions.