> en Java il est possible de faire des optimisations dans la VM en cours d'exécution et donc de générer dynamiquement du code optimisé
Pour donner le fond de ma pensée : c'est du pipo de marketeux !
Je veux de concrêt. Trouves mois un cas concrêt où c'est possible. C'est-à-dire que l'analyse ET l'optimisation supplémentaire ne coût pas plus cher qu'une optimisation "statique" aux petits oignons par le compilateur "statique" (il a le temps de faire l'optimisation lui...). Comme je l'ai dit ailleur je ne vois pas ce que peut apporter cette optimisation "dynamique". Si tu peux répondre à l'autre post sans pipo marketeux, c'est un plus.
btw, si l'optimisation est faite qu'une seule fois (comme souvent dit ici), je ne vois pas en quoi c'est dynamique !
> il est tout à fait possible que dans *certains* cas un programme Java soit plus rapide que le même proramme en C/C++
Si celà arrive, c'est seulement la preuve que le compilateur C n'est pas bon ou que le code C équivalent à la fonctionnalité java n'est pas top. Point barre.
Lis les commentaires de la news osnews : http://www.osnews.com/comment.php?news_id=7372&limit=no#249529(...) g++ lost fibo, hash2, methcall narrowly (scored between the 2 jvm's in all cases)
g++ won heapsort, objinst, sieve narrowly
g++ won hash, ackerman, strcat, matrix by 1.4 - 3x faster
g++ won nestedloop, random by 6x - 7x.
Et ça sur des tests qui sont sensés montrer la supériorité de java. Alors en usage général... Tiens donnes UN programme de la "vie réelle" ou java tourne plus vite.
Si g++ ne "gagne" pas pour les premiers tests, c'est de peu.
De plus, on ne connais pas les fonctions écritent en C qui sont utilisées par java et qui sont peut-être mieux foutu que le code C utilisé pour le bench de g++ (ya pas les source jdk). Et oui, java utilise des fonctions dans la VM qui sont écrites en C.
Ce que peut faire Java, le compilateur C peut le faire et à coût 0 lors de l'utilisation.
> tu peux imaginer une analogie simple avec les bases de données qui te permettent de faire des statistiques en cours de fonctionnement sur tes données pour en optimiser les chemins d'accès
C'est de l'analyse de données qui sont DYNAMIQUE !
Que je sache, je code java n'est pas dynamique. Où alors c'est un sacré bordel à programmer et forcément lent (il faut systématiquement optimiser à nouveau un code qui change).
> En revanche, Java utilisera à coup sur tjs plus de mémoire que le même programme en C/C++.
Et donc il passe du temps à "brasser" plus de données, le cache cpu est moins heureux, etc. Belle optimisation.
J'ai vu un test qui montrait que ne plus mettre certaines fonctions réseaux _inline_ dans le noyau permettait un gain significatif de performance simplement car le cache du cpu est moins stressé. Et pourtant _inline_ sur le papier c'est mignon.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Pour donner le fond de ma pensée : c'est du pipo de marketeux !
Je veux de concrêt. Trouves mois un cas concrêt où c'est possible. C'est-à-dire que l'analyse ET l'optimisation supplémentaire ne coût pas plus cher qu'une optimisation "statique" aux petits oignons par le compilateur "statique" (il a le temps de faire l'optimisation lui...). Comme je l'ai dit ailleur je ne vois pas ce que peut apporter cette optimisation "dynamique". Si tu peux répondre à l'autre post sans pipo marketeux, c'est un plus.
btw, si l'optimisation est faite qu'une seule fois (comme souvent dit ici), je ne vois pas en quoi c'est dynamique !
> il est tout à fait possible que dans *certains* cas un programme Java soit plus rapide que le même proramme en C/C++
Si celà arrive, c'est seulement la preuve que le compilateur C n'est pas bon ou que le code C équivalent à la fonctionnalité java n'est pas top. Point barre.
Lis les commentaires de la news osnews :
http://www.osnews.com/comment.php?news_id=7372&limit=no#249529(...)
g++ lost fibo, hash2, methcall narrowly (scored between the 2 jvm's in all cases)
g++ won heapsort, objinst, sieve narrowly
g++ won hash, ackerman, strcat, matrix by 1.4 - 3x faster
g++ won nestedloop, random by 6x - 7x.
Et ça sur des tests qui sont sensés montrer la supériorité de java. Alors en usage général... Tiens donnes UN programme de la "vie réelle" ou java tourne plus vite.
Si g++ ne "gagne" pas pour les premiers tests, c'est de peu.
De plus, on ne connais pas les fonctions écritent en C qui sont utilisées par java et qui sont peut-être mieux foutu que le code C utilisé pour le bench de g++ (ya pas les source jdk). Et oui, java utilise des fonctions dans la VM qui sont écrites en C.
Ce que peut faire Java, le compilateur C peut le faire et à coût 0 lors de l'utilisation.
> tu peux imaginer une analogie simple avec les bases de données qui te permettent de faire des statistiques en cours de fonctionnement sur tes données pour en optimiser les chemins d'accès
C'est de l'analyse de données qui sont DYNAMIQUE !
Que je sache, je code java n'est pas dynamique. Où alors c'est un sacré bordel à programmer et forcément lent (il faut systématiquement optimiser à nouveau un code qui change).
> En revanche, Java utilisera à coup sur tjs plus de mémoire que le même programme en C/C++.
Et donc il passe du temps à "brasser" plus de données, le cache cpu est moins heureux, etc. Belle optimisation.
J'ai vu un test qui montrait que ne plus mettre certaines fonctions réseaux _inline_ dans le noyau permettait un gain significatif de performance simplement car le cache du cpu est moins stressé. Et pourtant _inline_ sur le papier c'est mignon.