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.

[moldavi]

Bonjour.

En fouillant deux secondes je suis tombé sur cette page :

http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx

The OpenMP C and C++ application program interface lets you write applications that effectively use multiple processors. Visual C++ supports the OpenMP 2.0 standard.

Visual Studio a ses faiblesses, je pense qu'il y a une raison technique au problème d'optimisation. Il faut juste espérer que les développeurs en charge améliorent la chose.

Mais intuitivement, je dirai qu'optimiser quelque chose de déjà optimisé c'est étrange.

[bacelar]

Mais intuitivement, je dirai qu'optimiser quelque chose de déjà optimisé c'est étrange.

Bin non, l'optimisation est une tâche sans fin, on peut toujours optimiser un code, toujours.
C'est juste que le gain à tendance à diminuer et que le périmètre où ces optimisations sont efficaces devient de plus en plus réduit et que le domaine où c'est contre productif devient énorme.

Non, un code n'est jamais optimisé à fond.
Une simple innovation technique peut tout remettre en cause.

Mais soutenons les

développeurs en charge améliorent la chose.

même si c'est des aliens asocials.

[moldavi]

Re.

Bin non, l'optimisation est une tâche sans fin, on peut toujours optimiser un code, toujours.

Je ne sais dans quel contexte tu dis cela, mais j'aurais plutôt tendance à dire qu'à un moment on atteint les limites de l'optimisation. La meilleure optimisation étant celle "manuelle" et voire, avec preuve scientifique.

Je pense donc qu'un logiciel comme Visual Studio avec des options de compilation d'optimisation, ne prends pas le risque d'optimiser une librairie optimisée, elle aussi logiciellement.

Une simple innovation technique peut tout remettre en cause.

Une innovation matérielle ou un algo inconnu ?

Pour une innovation matérielle, effectivement il faut refaire l'optimisation. Pour l'algo inconnu, on attend les nouveaux Einstein.

Non, un code n'est jamais optimisé à fond.

Pour résumer, un code de 10 lignes peut-être optimisé à fond (et par rapport à une architecture matérielle), et un code d'1 million de lignes, effectivement c'est impossible.

Je fais la différence entre optimiser des bouts de code et optimiser une architecture logicielle. Mon raisonnement sur le message précédent portait sur l'optimisation de bouts de code, pas sur une architecture complexe.

Après si ton raisonnement c'est de dire que les programmes que l'on développe, on ne prend jamais le temps de les optimiser à fond, et que donc il y a toujours des optimisations à faire, je suis bien d'accord.

[bacelar]

avec preuve scientifique

Gödel est mon ami : http://fr.wikipedia.org/wiki/Th%C3%A..._de_G%C3%B6del
Il est impossible de prouver qu'un algorithme est optimal, alors encore moins une implémentation, seule la solution l'est.

Quand on optimise, il n'y a pas de limite, et donc modifier une architecture est toujours dans l'ordre du possible.
Et c'est souvent un "quick win".

[moldavi]

Ok.

C'est bien pour cela que je me suis permis de faire la différence entre une optimisation de quelques lignes de code et une architecture logicielle.

Je comprends mieux le contexte de ton raisonnement.