Les langages qui s'en sortent bien dans le shootout sont les langages qui automatisent la gestion des threads et font souvent de bien meilleur choix que lorsqu'on code à la main.
On est pas tout à fait en phase. Moi ce que je disais au contraire, c'est que l'impact du langage est beaucoup moins important dans un contexte multi-thread : c'est l'algo mis en oeuvre par le programmeur qui fait le gros de la différence.
Java/C# vont devoir se mettre au diapason vite fait, mais je fais confiance à Sun/Microsoft pour prendre les dispositions nécessaires.
Au contraire, quand tu vois le bench, on s'apercoit que les langages C# ou Java n'ont pas à rougir des perfs des langages bas niveaux, parcque la différence se fait au niveau de la qualité des algos mis en oeuvre par les programmeurs. Mais en soit la base technique des langages C# ou Java est adapté au contexte multi-core.
Le seul véritable critère important dans le langage, c'est le fait qu'il mette à disposition du programmeur l'accès aux fonctionnalités multi-core natives de l'OS/machine sous-jacent. Les langages comme Python avec des implémentations totalement foireuses du multi-thread se font largués.
Sinon effectivement, si les langages veulent se différencier dans la course au multi-thread, c'est en proposant des nouvelles constructions pour automatiser la répartition sur plusieurs threads. Bien souvent ca se fait à l'aide de bibliothèques, et non directement dans le langage. (pour parler de mon église, on peut citer TPL http://en.wikipedia.org/wiki/Task_Parallel_Library )
Dans tous les cas, ces éventuelles "aides" au programmeur ne pourront que s'appuyer sur les compétences du programmeur : si l'algo est pas adapté, il sera pas parallélisable, quelque soit le langage. Bref, le programmeur va de nouveau devoir réfléchir, et ca c'est bien, ca laisse beaucoup de chemin d'évolution possible.
[^] # Re: perf
Posté par TImaniac (site web personnel) . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 5.
On est pas tout à fait en phase. Moi ce que je disais au contraire, c'est que l'impact du langage est beaucoup moins important dans un contexte multi-thread : c'est l'algo mis en oeuvre par le programmeur qui fait le gros de la différence.
Java/C# vont devoir se mettre au diapason vite fait, mais je fais confiance à Sun/Microsoft pour prendre les dispositions nécessaires.
Au contraire, quand tu vois le bench, on s'apercoit que les langages C# ou Java n'ont pas à rougir des perfs des langages bas niveaux, parcque la différence se fait au niveau de la qualité des algos mis en oeuvre par les programmeurs. Mais en soit la base technique des langages C# ou Java est adapté au contexte multi-core.
Le seul véritable critère important dans le langage, c'est le fait qu'il mette à disposition du programmeur l'accès aux fonctionnalités multi-core natives de l'OS/machine sous-jacent. Les langages comme Python avec des implémentations totalement foireuses du multi-thread se font largués.
Sinon effectivement, si les langages veulent se différencier dans la course au multi-thread, c'est en proposant des nouvelles constructions pour automatiser la répartition sur plusieurs threads. Bien souvent ca se fait à l'aide de bibliothèques, et non directement dans le langage. (pour parler de mon église, on peut citer TPL http://en.wikipedia.org/wiki/Task_Parallel_Library )
Dans tous les cas, ces éventuelles "aides" au programmeur ne pourront que s'appuyer sur les compétences du programmeur : si l'algo est pas adapté, il sera pas parallélisable, quelque soit le langage. Bref, le programmeur va de nouveau devoir réfléchir, et ca c'est bien, ca laisse beaucoup de chemin d'évolution possible.