Salut
 
Avec un copain, cet été nous aimererions faire un moteur de ray-tracing. Connaissant "bien" C++ et trouvant ce language particulièrement chiant on aimerait en utiliser un autre. Pour ce qui est de Java, on le trouve trop lent, il reste C#. Mais on ne connais pas ces performances en terme de rapidité d'exécution face à Java et C++.  
 
Quelqu'un pourrait-il nous éclairer ???
 
Merci

 
troll
 
ban
 
(et si c'est sérieux peux tu justifier "on le trouve trop lent" )

T'as testé avant de dire que "Java est trop lent", ou c'est juste basé sur des à priori ?

C'est un copain qui lui a dit...  
J'aime beaucoup le "on aime pas c++, on aime pas java, il ne reste donc plus que C#"...:lol:

 
des futurus décideurs élevés au grain

   
Pi d'abord les débats sur les langages ya un topic exprès!

 
Troll, Ban ??? Pkoi ???
 
Pourquoi trop lent ? Mais c bien connu voyons le fait de passé par une machine virtuel ne peut qu'augmenter considérablement les performances...  
J'ai déjà vu un moteur de ray-tracing tourné en java, comparé à un moteur de ray-tracing en c/c++, c le jour et la nuit...
 
J'ai jamais dis que je n'aimais pas java et c++ seulement java est nettement plus facile à manipuler que c++ et comme c# ce rapproche beaucoup de java, je me posais la question... mais bon si c'est trop vous demandé, je vais allé me renseigner ailleur....

drapal

 
Je suppose que tu voulais dire que le fait de passer par une JVM ne pouvait que diminiuer les perfs, soit
 
Déjà de un il y a une différence ENORME entre dire ce language est trop lent et ce language est trop lent pour tel type d'application.  Tu as le droit de détester ce que tu veux, chacun est libre. Mais balancer on le trouve trop lent comme un cheveu ds la soupe, ca ne fait pas très sérieux ...

 
Les JIT ça existe, et pour des algorithmes fortement répétitifs, seul la première itération est lente, puisqu'ensuite la convertion en code machine a déjà été faite une fois et est réutilisée.
 

 
On peut trouver des moteurs de raytracing lents en C++ aussi. Un foirage sur l'algo, on monte d'un niveau en complexité par rapport à un autre moteur, et hop, un moteur lent, et ce indépendamment du langage utilisé.

Perso je vote Troll.

 
perso j'ai testé et je trouve ca trop lent
 
 
<insert flame here>

 
ça à l'air interressant ça, c'est quoi JIT ?

 
C#, ça tourne dans une machine virtuelle aussi (ou équivalent)

 
Just In Time
 
tu compile qu'une fois si je dis pas de connerie

 
bin Just In Time tu connais pas?

 
Ben non. J'devrais ?

 
euh non pas forcément ...

JIT = compilation à la volée. En gros, le programme est compilé pendant son exécution

 
(ca doit etre horrible a programmer un truc comme ca)

Oui je sais, et c'est pour ca que je suis venu ici, pour me renseigner sur les différences de perfs entre java et c# s'il y en a... mais je remaque que personne ne m'a répondu pour l'instant...

 
y'a eu pas mal de test de fait je crois, cherche sur le net, mais a priori ce genre de question c l'ideal pour declencher une bonne guerre des familles

C'est parce-qu'il n'y a pas de réponse définitive...et pour les trolls c'est trop tôt!

Désolé, mais comme je parlais juste avant de faire un ray-tracer, cela me paraissait d'une évidence...

 
pas vraiment non

Oui c ce que je vois...   j
e me ramene pour poser une question interessante me semble-t-il et je me fais agressé...

J'avais essayé de programmer un émulateur Z80 un jour. Le trouvant trop lent, j'avais décidé de passer d'un interpréteur à un recompilateur dynamique.
J'ai jamais réussi à faire tourner ce bordel correctement. Je pouvais obtenir des gains phénoménaux sur une écriture en mémoire, mais je me cassais la gueule sur un transfert de registre à registre (un comble quand même).
J'ai balancé ce projet, en me disant que mon émulateur Z80 finirait par tourner le jour ou les PC dépasseront 1 Ghz

autant pour moi alors  

 
ben c normal hein, y'a des fans des java et toi tu debarques avec des "Java c'est tout lent " alors ils se veskent.
 
Note perso je suis pas fan non plus de java et je trouve que effectivement niveau velocite on a vu mieux (surtout pour de l'intensif (genre ton RT). Perso je choisirais C++ mais bon, si ca te broute )

 
tiens, tu peux en dire plus ? Perso le truc que je capte pas c comment le CPU decode rapidement les opcodes
 
(Perso j'ai vu comment c t deja la misere sur mon compilo "off line" ou je pouvais me permettre une bonne grosse table des symboles bien epaisses, alors faire ca en live ca me fait assez peur Deja la j'ai fait pas mal d'heure de debug et y doit encore avoir plein de cas ou le truc perds pieds, encore que la depuis qq tps c stable)

  En même temps il parait que la compilation Just in time ça marche bien, en même temps j'ai du  lire ça sur le site de sun alors bon...  

C'te vieux troll de base
Si tu veux un exemple de perfos, j'en ai un : j'avais un prog C (pas programmé par moi) qui faisait de la lecture dans des fichiers puis de l'insertion en base de données MySQL. Pour 4000 fichiers, il mettait 20 min environ sur un PIII 750. Avec la même config, j'ai développé le même type de soft. Résultat, plus de 15000 fichiers en 9 min.
 
A toi de voir l'utilisation que tu comptes faire de ton prog et la connaissance que tu as de l'algo et de chaque langage

 
disons que la ton exemple est assez enquiquinant parce que si il a fait ses IO comme un porc (genre je lis un caractere apres l'autre) c un peu normal
La par contre ca serait de l'intensif, du brut, bref du 100& cpu, donc j'imagine que meme en JIT y'a risque de handicap (J'imagine, mon experience perso c quand meme avec une vieille JVM (au mieux) ou PersonnalJava (au pire, ce truc la est revoltant) alors bon)
 
 

 
Ca pourrait être probant si tu avais fait la version C.

 
A mon avis y'aurait gain, j'en suis quasiment sur (par analogie avec ce que j'avais deja fait avant). Je vais convertir la routine bouffant le plus de tps de Java->C (ca devrait pas etre bien dur) a l'occas

Ui, j'imagine que le prog C était assez mal foutu  Mais c'est surtout pour dire : si tu maîtrises mieux un langage qu'un autre, il vaut mieux s'orienter vers celui-ci plutôt que de regarder lequel a les meilleures perfs au millième de seconde près. Un algo propre et compréhensible sera souvent mieux codé dans le langage qu'on maîtrise le mieux

Tu n'as qu'à utiliser Ada à la place : le compilateur génère du code natif et efficace, comme C++, et le langage est nettement plus rigoureux que C++ (même plus que Java).
 
Et puis c'est gratuit (aussi bien le compilo que la plupart des librairies. Et si tu veux réutiliser du code C++, c'est encore plus simple que l'interface native de Java).

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