Tu sais que tu peux faire un modèle actor en Java en zero copy et sans avoir à commuter de thread à chaque fois ?
Genre http://www.malhar.net/sriram/kilim/ ca tient Erlang en microbench et ca le fracasse en perf sur le code metier. L'optimisation de la VM d'Erlang étant à des années lumières de celle de Java. Le fork/join de la JSR 166y n'obtient pas ses perfs avec une implémentation naïve d'un stagiaire.
On confond un peu tout et n'importe quoi ici. Un modèle de parallélisme donné peut très souvent être implémenté sur n'importe quelle techno. Donc se servir dudit modèle pour venter les performances d'un langage ou d'une VM est absurde.
De même beaucoup ici confondent scalabilité et performance. À scalabilité identique un code plus performant terminera sa tâche plus rapidement quelque soit le nombre de ressources à sa disposition.
Pour le moment tout le monde cherche le bon modèle. Les threads demandent des legendary engineers pour simplement faire du code qui marche [1]. Alors tout le monde propose des nouveaux trucs et un jour peut être on trouvera le truc qui scale, qui a de bonnes perfs, qui est facile à développer et qui est facile à débugger. En cadeau bonus si ca marche en local et en distribué c'est merveilleux. Pour le moment on est dans la phase ou on lance n'importe quoi en l'air et on verra bien ce qui retombe.
Parallèlement il faut réussir à découper son code métier en morceaux parallèles. C'est difficile, et on oublie pas la loi d'Amdah au passage...
[1] On peut, entre autre, lancer un grand jeu sur les memory models de Java, C++, .Net ou sur ceux des processeurs si certains veulent dire le contraire.
[^] # Re: perf
Posté par ckyl . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 7.
Genre http://www.malhar.net/sriram/kilim/ ca tient Erlang en microbench et ca le fracasse en perf sur le code metier. L'optimisation de la VM d'Erlang étant à des années lumières de celle de Java. Le fork/join de la JSR 166y n'obtient pas ses perfs avec une implémentation naïve d'un stagiaire.
On confond un peu tout et n'importe quoi ici. Un modèle de parallélisme donné peut très souvent être implémenté sur n'importe quelle techno. Donc se servir dudit modèle pour venter les performances d'un langage ou d'une VM est absurde.
De même beaucoup ici confondent scalabilité et performance. À scalabilité identique un code plus performant terminera sa tâche plus rapidement quelque soit le nombre de ressources à sa disposition.
Pour le moment tout le monde cherche le bon modèle. Les threads demandent des legendary engineers pour simplement faire du code qui marche [1]. Alors tout le monde propose des nouveaux trucs et un jour peut être on trouvera le truc qui scale, qui a de bonnes perfs, qui est facile à développer et qui est facile à débugger. En cadeau bonus si ca marche en local et en distribué c'est merveilleux. Pour le moment on est dans la phase ou on lance n'importe quoi en l'air et on verra bien ce qui retombe.
Parallèlement il faut réussir à découper son code métier en morceaux parallèles. C'est difficile, et on oublie pas la loi d'Amdah au passage...
[1] On peut, entre autre, lancer un grand jeu sur les memory models de Java, C++, .Net ou sur ceux des processeurs si certains veulent dire le contraire.