Version imprimable
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... :koi:
Quelqu'un a plus d'infos sur le sujet?
NONCitation:
qui cherche � optimiser correctement son code utilisera openmp
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.
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.Citation:
Envoy� par bacelar
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.Citation:
Envoy� par bacelar
Moi, l'optimisation par parall�lisme, c'est le d�but du processus d'optimisation.Citation:
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.
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. :aie:
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 :cry:). :mouarf:
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. :oops:
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 :cry:
Franchement, je travail plus avec des clients de ma caricature que de la tienne.Citation:
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.
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. :cry:
Bonjour.
En fouillant deux secondes je suis tomb� sur cette page :
http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx
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.Citation:
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.
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.Citation:
Mais intuitivement, je dirai qu'optimiser quelque chose de d�j� optimis� c'est �trange.
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
:ccool:Citation:
d�veloppeurs en charge am�liorent la chose.
m�me si c'est des aliens asocials. :aie:
Re.
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.Citation:
Envoy� par bacelar
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 innovation mat�rielle ou un algo inconnu ?Citation:
Envoy� par bacelar
Pour une innovation mat�rielle, effectivement il faut refaire l'optimisation. Pour l'algo inconnu, on attend les nouveaux Einstein.
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.Citation:
Envoy� par bacelar
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.
G�del est mon ami : http://fr.wikipedia.org/wiki/Th%C3%A..._de_G%C3%B6delCitation:
avec preuve scientifique
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".
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.