Discussion :

[r0d]

Bonjour,

je viens de voir ça: http://msdn.microsoft.com/en-us/library/7k7e9y2d.aspx

Je trouve ça ahurissant: tout développeur c++ qui cherche à optimiser correctement son code utilisera openmp. Or voilà: j’apprends que le profiler de visual c++ n'est pas compatible avec openmp. Il y a quelque chose qui m'échappe...

Quelqu'un a plus d'infos sur le sujet?

[bacelar]

qui cherche à optimiser correctement son code utilisera openmp

NON
OpenMP, c'est pour le parallélisme, et on ne peut pas paralléliser tout et n'importe quoi.

Je ne paralléliserais que les parties critiques du code que je prendrais soin de mettre dans un module dédié, histoire d'utiliser des profiler spécialement designé pour le parallélisme.

Et le reste du code avec un profiler plus conventionnel.

Donc, cela ne me choque pas que l'implémentation d'un profiler soit très sensible options de compilation.

Je préfère un profiler qui fait correctement son boulot quitte à avoir quelques contraintes, qu'un profiler qui marche partout mais qui donne que des valeurs approximatives.

[r0d]

NON
OpenMP, c'est pour le parallélisme, et on ne peut pas paralléliser tout et n'importe quoi.

Bien sûr, mais généralement, quand tu en arrive à devoir profiler ton code sérieusement, c'est que tu es déjà arrivé à des optimisations du type parralélisation. Bien sûr pas 100% des fois, mais quand-même fort souvent.

Je ne paralléliserais que les parties critiques du code que je prendrais soin de mettre dans un module dédié, histoire d'utiliser des profiler spécialement designé pour le parallélisme.

Entièrement d'accord avec toi, c'est la raison pour laquelle je trouve ahurissant que le profiler de microsoft ne le fasse pas. En fait, c'est plus fourbe que cela. Par exemple, le profiler intégré à visual C# gère parfaitement le parralélisme. Visual C++ 2010 gère égalemen le parralélisme de sa propre lib (Parallel pattern Library). Le fait de ne pas supporter openmp est, il me semble, un choix politique.

[bacelar]

Bien sûr, mais généralement, quand tu en arrive à devoir profiler ton code sérieusement, c'est que tu es déjà arrivé à des optimisations du type parralélisation. Bien sûr pas 100% des fois, mais quand-même fort souvent.

Moi, l'optimisation par parallélisme, c'est le début du processus d'optimisation.
C'est du "quick win".
On parallélise rapidement un code pourri (mais pas trop).

Résultat, gain spectaculaire en performance en très peu de temps.
Et après, pour le code pourri, bin comme le client est très content des perfs, il s'en fout.

Et nous, on va facturer un nouveau pigeon pour une prestation d'optimisation et encore passer pour un dieu (ou plus souvent, pour un alien asocial ).

Si je ne me trompe pas, c'est M$ qui pousse OpenMP, donc si c'est un choix politique, ce n'est pas très cohérent.

Etant donné que le code natif est beaucoup plus opaque que le code JITé via .NET, je pense que la complexité du profiler du code natif est bien supérieur.

Et franchement, vu la complexité de ces trucs, les développeurs des profilers, c'est eux les vrais dieux/aliens.

[r0d]

Mhhh. Je croyais que c'était putôt Intel qui poussait openMP. Mais je n'ai aucune source fiable, donc je ne sais pas.

Mais sinon tu carricatures un peu. Souvent la parallélisation est dès le début dans les specs et le code qui en découle est conçu pour, dès le début également. Bon, c'est aussi une autre carricature, je sais bien qu'en vérité, c'est pas souvent le cas.

Mais je sais pas, je trouvais que microsoft avait pris le bon chemin ces dernières années. Son compilo c++ qui respecte de plus en plus le standard, le langage c# qui (et ce fut une surprise pour moi quand je m'y suis mis sérieusement) est très bien pensé et assez propre, etc. Et là je suis un peu déçu

[bacelar]

Mais sinon tu carricatures un peu. Souvent la parallélisation est dès le début dans les specs et le code qui en découle est conçu pour, dès le début également. Bon, c'est aussi une autre carricature, je sais bien qu'en vérité, c'est pas souvent le cas.

Franchement, je travail plus avec des clients de ma caricature que de la tienne.

J'ai même eu droit, quand j'ai "parallélisé" en 1 jour, une application .NET qui était déjà "impossible à rendre plus optimale" et qui chargeait au taquet une machine bi-pro à 50% de CPU, et donc passant à 100% après "optimisation" à :
"Faites gaffe, vous allez casser la machine" VERIDIQUE.