Posté par boubou .
En réponse à la dépêche Mono 0.24.
Évalué à 2.
Euh, d'abord quel besoin d'être agressif et grossier ?
Ok, désolé. Cependant, ça devient insupportable de répondre toujours au même FUD. Donc toutes mes excuses pour l'aggressivité, pas pour le qualitificatif "conneries pareilles".
mais ce n'est pas du logiciel libre tout d'abord
C'est sûr que le site de la SNCF n'est pas libre, mais bon, on s'en fout un peu. Par contre, ce qui est plus remarquable, c'est que Chronopost utilise en partie JBoss.
des sociétés qui peuvent se permettre de dépenser des millions (d'euros!) en matériel de pointe et en piles de serveurs dans des data centers pour compenser la différence de performances de Java.
C'est de l'humour ? Le matériel de pointe en question, ce sont surtout les 4Go de mémoire par serveur, à part ça, je te fais remarquer que ce qui coûte cher, ce n'est pas le matériel, mais les programmeurs. Et vu l'efficacité pour le développement de framework comme .Net ou J2EE, la boite gagne. Quand nous avons remporté l'appel d'offre, tout était bien entendu pris en compte, les serveurs comme le coût de développement. Tient d'ailleurs, j'ai oublié de dire que notre solution est entrièrement basée sur de l'open source, excepté la JVM...
Blitz en C++, à patir du template metaprogramming, va plus vite que le LAPAC qui a été codé à la main
Sauf que c'est du pipot intégral. Je connais les benchs, ils sont réalisé contre l'implémentation basique toute pourrie de BLAS et LAPAC, pas contre une implémentation haut de gamme comme la MKL d'Intel ou Atlas (open source). Par contre, les benchs dont je te parlais sont deux de COLT contre MKL et Atlas... Alors oui, Blitz c'est sympa, mais c'est un gadget pour faire du calcul matriciel efficace, contrairement à COLT. Bien sûr, tu peux vraisemblablement utiliser Blitz au dessus d'une implémentation efficace de BLAS, mais c'est aussi possible en Java. L'intérêt de COLT, c'est que c'est 100% pur Java.
je te fais remarquer que ces optimisations sont possible pour un compilateur Eiffel car il dispose de la possibilité d'effectuer l'analyse globale du code.
En effet, comme en Sather, et dans une certaine mesure. Sauf qu'à ma connaissance, la décision d'inlining est prise en se basant sur des critères heuristiques de complexité de la méthode, alors qu'avec un JIT, tu peux faire des évaluations par chronométrage. De plus, dès que l'analyse globale laisse un doute (à cause de la covariance en Eiffel, par exemple), tu ne peux plus inliner. Avec un JIT, on peut imaginer maintenir deux codes, une version inlinée parce qu'en général on doit utiliser celle-ci et une version sans inline quand on détecte (par un simple test de plus) qu'en fait l'objet passé n'est pas du bon type.
Donc tant mieux si les machines virtuelles progressent, cela permet de diminuer l'écart de performances entre un code compilé et un code interprété, mais cet écart existe toujours et cela restera un fait.
Bien entendu, mais les machines virtuelles compilent le code au vol. Pour une application qui tourne longtemps, elles peuvent battre la compilation statique...
[^] # Re: Mono 0.24
Posté par boubou . En réponse à la dépêche Mono 0.24. Évalué à 2.
Ok, désolé. Cependant, ça devient insupportable de répondre toujours au même FUD. Donc toutes mes excuses pour l'aggressivité, pas pour le qualitificatif "conneries pareilles".
mais ce n'est pas du logiciel libre tout d'abord
C'est sûr que le site de la SNCF n'est pas libre, mais bon, on s'en fout un peu. Par contre, ce qui est plus remarquable, c'est que Chronopost utilise en partie JBoss.
des sociétés qui peuvent se permettre de dépenser des millions (d'euros!) en matériel de pointe et en piles de serveurs dans des data centers pour compenser la différence de performances de Java.
C'est de l'humour ? Le matériel de pointe en question, ce sont surtout les 4Go de mémoire par serveur, à part ça, je te fais remarquer que ce qui coûte cher, ce n'est pas le matériel, mais les programmeurs. Et vu l'efficacité pour le développement de framework comme .Net ou J2EE, la boite gagne. Quand nous avons remporté l'appel d'offre, tout était bien entendu pris en compte, les serveurs comme le coût de développement. Tient d'ailleurs, j'ai oublié de dire que notre solution est entrièrement basée sur de l'open source, excepté la JVM...
Blitz en C++, à patir du template metaprogramming, va plus vite que le LAPAC qui a été codé à la main
Sauf que c'est du pipot intégral. Je connais les benchs, ils sont réalisé contre l'implémentation basique toute pourrie de BLAS et LAPAC, pas contre une implémentation haut de gamme comme la MKL d'Intel ou Atlas (open source). Par contre, les benchs dont je te parlais sont deux de COLT contre MKL et Atlas... Alors oui, Blitz c'est sympa, mais c'est un gadget pour faire du calcul matriciel efficace, contrairement à COLT. Bien sûr, tu peux vraisemblablement utiliser Blitz au dessus d'une implémentation efficace de BLAS, mais c'est aussi possible en Java. L'intérêt de COLT, c'est que c'est 100% pur Java.
je te fais remarquer que ces optimisations sont possible pour un compilateur Eiffel car il dispose de la possibilité d'effectuer l'analyse globale du code.
En effet, comme en Sather, et dans une certaine mesure. Sauf qu'à ma connaissance, la décision d'inlining est prise en se basant sur des critères heuristiques de complexité de la méthode, alors qu'avec un JIT, tu peux faire des évaluations par chronométrage. De plus, dès que l'analyse globale laisse un doute (à cause de la covariance en Eiffel, par exemple), tu ne peux plus inliner. Avec un JIT, on peut imaginer maintenir deux codes, une version inlinée parce qu'en général on doit utiliser celle-ci et une version sans inline quand on détecte (par un simple test de plus) qu'en fait l'objet passé n'est pas du bon type.
Donc tant mieux si les machines virtuelles progressent, cela permet de diminuer l'écart de performances entre un code compilé et un code interprété, mais cet écart existe toujours et cela restera un fait.
Bien entendu, mais les machines virtuelles compilent le code au vol. Pour une application qui tourne longtemps, elles peuvent battre la compilation statique...