Hé ho, laisse-nous un peu le temps de faire les outils ! :-)
Grâce à tout ce merdier multicore, je pense que j'aurai du boulot pour encore quelques années.
Les outils qui gèrent le multicore existent pourtant en partie, mais malheureusement ne sont pas libres : DDT et Total View par exemple (qui ont aussi plein de défauts) sont des debuggers fait exprès pour les programmes parallèles (ils comprennent même MPI et OpenMP).
gdb gère les threads POSIX, et DDD (qui a récemment repris son dév) est capable d'en tirer parti.
C'est pas encore la joie, mais ça avance. Il existe tout un tas d'outils pour analyser la mémoire (ValGrind et Acumem [non-libre] sur x86 par ex).
C'est loin d'être suffisant, mais je pense qu'il faudra encore 5 ans mini pour avoir des outils utilisables par des non-experts pour trouver les bugs ET améliorer les perfs. Mais ça va venir, nécessairement.
[^] # Re: Où est le problème ?
Posté par lasher . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 2.
Grâce à tout ce merdier multicore, je pense que j'aurai du boulot pour encore quelques années.
Les outils qui gèrent le multicore existent pourtant en partie, mais malheureusement ne sont pas libres : DDT et Total View par exemple (qui ont aussi plein de défauts) sont des debuggers fait exprès pour les programmes parallèles (ils comprennent même MPI et OpenMP).
gdb gère les threads POSIX, et DDD (qui a récemment repris son dév) est capable d'en tirer parti.
C'est pas encore la joie, mais ça avance. Il existe tout un tas d'outils pour analyser la mémoire (ValGrind et Acumem [non-libre] sur x86 par ex).
C'est loin d'être suffisant, mais je pense qu'il faudra encore 5 ans mini pour avoir des outils utilisables par des non-experts pour trouver les bugs ET améliorer les perfs. Mais ça va venir, nécessairement.