Reprise du message précédent :
comparaison des perfs (bon d'accord, ca date un peu, mais c'est tout ce que j'ai trouvé )=> http://www.aceshardware.com/read.jsp?id=153
 
Sinon, la machine Hotspot de Sun c'est encore plus balèze qu'un JIT. Si je me souviens bien, un JIT, ca compile tout en une fois (enfin, méthode par méthode non ?) en natif et puis ca exécute.  
La Hotspot, elle commence directement en interpretant, et si elle trouve qu'il y a des bouts de code où ca reste longtemps, elle créé une nouvelle thread pour compiler ce bout de code en parallèle puis le remplace par le code natif.
 
Par exemple, si il y a 5000 ligne qui s'exécute qu'une fois, puis une boucle où elle passe tout son temps, elle compile juste la boucle. Et puis, si ca reste vraiment longtemps, elle repasse une deuxième couche avec les infos qu'elle a sur l'exécution (loop unrolling et des trucs comme ca). En gros, elle fait comme les profiler en C++, mais en temps réel!
Elle fait aussi de l'inlining et d'autre trucs, je sais plus trop...
J'avais lu un papier là dessus et c'était assez impressionant!
 
Apparement, ca marche assez bien (en tout cas pour certains codes): j'ai testé avec un algo de résolution de problème à contraintes (problème des N-reines pour ceux qui connaissent) et avec la JIT du jdk1.2.2, ca prenait 35sec, avec la hotspot du jdk1.4, ca descendait à 9sec. Pas négligeable quoi

 
un moteur en raytracing, c'est impossible d'en faire un rapide sous une machine virtuelle vu les temps de calcul mis en cause (entre 30 min et plusieurs jours) => C++ only

Le mieux c'est de la faire en assembleur en utilisant les extensions SIMD de ton proc.

 
Certainement, mais il faut reserver une chambre à l'hopital psychiatrique dès la phase de conception

Question bête : tu t'es basé sur des mesures pour dire cela ? Si tu en faisais, à mon avis, tu aurais de grosses surprises...
 
Franchement, la différence de vitesse n'est pas si considérable (ce n'est pas comme si tu écrivais ton moteur dans un langage de script style Perl, par exemple) qu'elle rende réddhibitoire l'utilisation de Java. Même si tu avais un facteur 5 (i.e. Java 5 fois plus lent que C++, ce qui reste à démontrer pour ce type d'applications), n'oublie jamais que cela correspond à la différence entre les processeurs d'aujourd'hui et les processeurs d'il y a 3 ans seulement. Pas énorme...

Euh... Je comprends pas trop les premères réactions (j'ai pas lu la suite, je me suis arrêté au moment où ça commence à enfin devenir à peut près sérieux).
 
Y'a des gens qui ont lu pour quoi c'était faire ?
 
RayTracing.
 
Ca vous dis quelquechose ?
 
Bosser avec des réels 64 bits en faisant des fonction de calculs intensifs, y'a pas photo, Java est à la ramasse complète. Aucun avantage de ce langage n'est exploitable, et il ne reste plus que les inconvénients, qui sont loin d'être petits, notamment au niveau de la rapidité d'éxécution pour les fonctions de bas niveau. (et niveau calculs dans un raytracer, ça se pose là pour ce qui est des calculs de bas niveau, c'est pas la phase de modèlisation de la scène en mémoire qui est longue, mais la phase de calcul des rayons).
 
Le C# devrait être à peine plus rapide, parceque son seul avantage par rapport au java, c'est qu'une vois le programme démarré, il est compilé en mémoire, et c'est donc du code natif qui est éxécuté, on gagne donc un peu...
 
Mais il n'est lui non plus pas du tout adapté.
 
Le C++ est évidement mieu adapté, mais à nouveau, il est bien trop lent par rapport aux besoins d'un raytracer. Le C pur est la seule solution réellement performante.
 
A la limite... Je crois que c'est le fortran aussi, qui est très bon en matière de calculs.
 
Sinon il reste toujours l'ASM, mais là je vous souhaite du courrage
 
En résumé, Java ou C#, ça sera à peut près la même catastrophe niveau temps, avec un léger avantage pour le C#. Si c'est juste pour le fun, vous pouvez vous amuser à faire votre appli avec des langages. Mais si c'est en réponse à un réel besoin, laissez tomber et utilisez un langage qui est destiné à ce ganre de programmes, c'est à dire soit de TRES bas niveau (C) soit doté de librairies de calcul très performantes (je crois que c'est le fortran, mais je suis pas sûr)

De toute façon, c'est une hérésie de faire des moteurs 3D dans un langage autre que l'assembleur...

Bah ça dépends de quelle partie... Franchement, la partie qui s'occupe de générer l'image à partir des pixels calculés, elle serait écrite en BASIC et tournerait sur un GOUPIL, ça changerait rien à la vitesse d'éxécution du raytracer
 
Y'a juste les fonctions de calculs qui peuvent tirer profit de l'assembleur (sâchant qu'il ne faut pas négliger un code C optimisé, parceque les bidouilles que pourra faire le compilo peuvent être source de grosses optimisation par rapport à un code ASM pur pas forcément maîtrisé à 100%

Ouais mais 9 fois sur 10, les compilos actuels oublient les extensions SIMD des proc en compilant, du coup tu vas compiler du C sur un Athlon XP qui n'utilisera même pas le SSE ou le MMX ! Alors que ça procure un gain de vitesse non négligeable !

 

 
Faire du raytracing en java est d'autant plus débile qu'un code de moteur est très facilement portable puisque c'est que du C++ ultrastandard et qu'il n'y aucun appel API ou d'UI ou autre.

Et tu crois que le java il fait quoi ?
Qu'il s'amuse à interpeter instruction par instruction ?
On est plus au stade du java 1.1 hein
 
Mais je suis d'accord que ce n'est sans doute pas le langage le plus adapté.  
Quoi qu'il est toujours possible de faire tout en java et de faire le moteur de raytracing en C, c'est pas difficile de faire un appel JNI à partir de Java.  
Comme ca, si le moteur est fait en C tout à fait standart, tout le programme sera facilement portable, interface graphique comprise.

C plus rapide que C++ ???? Pourquoi ???

+ bas niveau...après c'est comme tjrs, ca dépend de ta façon de coder...

 
à la limite, c'est une bonne solution  

Je pense à ca parce que je compte faire la même chose pour un tout autre projet

Bah moi, je vais sur www.povray.org, je dwl les sources, je les charge dans VC++ et je compile et zou, je viens de faire mon super raytracer super bien en quelques secondes

Et si je veux le porter sur amiga, je dwl les sources pour amiga
 
C encore plus portable que le Java

C'est po vrai, tu sais pas le faire tourner sur mon GSM

Va faire tourner un raytracer en java sur un gsm toi

 
on peut peut-être faire les calculs en parallèle sur plusieurs GSM pour accélérer

 
comme ceux qui ont fait un mega calculateur avec 65 playstations en parrallele    
 

 
ouais, ça doit presque atteindre un p4 3ghz  

 
j'ai retrouvé le lien  
http://arrakis.ncsa.uiuc.edu/ps2/cluster.php
 

ouais, j'y pensais aussi, mais niveau consommation ca va pas être top, va falloir améliorer les batteris

Pis je te raconte pas les communication GSM