Version imprimable
Bonjour, sur cette article
http://www.pixelglow.com/macstl/valarray/
il explique que valarray peut utiliser les instruction SIMD des processeur.
N'ayant pas trouvé grand chose dessus, je me demande si la STL de VC++ fait de même ainsi que celle de GCC??
merci
Très franchement, j'en doute fort.
Si tu veux en avoir le coeur net, tu compiles un petit programme de test en mode release, et tu regardes le code généré...
Et puis visiblement, le lien que tu donnes est une implémentation des valarrays spécialement conçue pour les instruction SIMD.
De toute façon les valarrays (ni la STL de façon générale) ne sont pas pratiques pour les calculs numériques, il vaut mieux utiliser une librairie spécialement conçue pour ça.
ok merci.Citation:
Envoyé par Charlemagne
Juste pour info, tu aurais des nom de quelques'une de ces lib?
Les librairies utilisant les instructions SIMD ne sont pas légions. Je connais celles-ci:
-ATLAS: algèbre linéaire (Blas, Lapack)
-FFTW: transformées de Fourier
-la mienne: http://www.ient.rwth-aachen.de/team/...al/genial.html
merci.
J'ai regardé un peu plus valarray qui as l'air trés pratique mais qui n'est pas totalement bien defini...Citation:
Envoyé par Charlemagne
Je vais me faire un petit prog pour voir, par contre je ne vois pas comment savoir si il fait du SIMD aprés avoir généré le code 8O ??
Sinon, d'autre personne aurai un avis sur les valarray?
merci
Ben tu regardes le code généré et tu verras bien...
je regarde le code assembleur? ben je vois pas trop comment en assembleur je peut voir si il fait du SIMD...Citation:
Envoyé par loufoque
Merci
Ben tu vois bien si ça utilise des instructions MMX, SSE ou SSE2...
Dans le même genre, toujours basées sur BLAS et LAPACK :Citation:
Envoyé par Charlemagne
- MKL (Intel)
- ACML (AMD)
Je connaissais, mais c'est payant je crois bien. C'est pour cette raison que je ne l'ai pas mentionnée. Prétend sur son site (benchs à l'appui) être plus rapide que FFTW et ATLAS, principalement sur des systèmes multi-processeurs derniers cris.Citation:
Envoyé par Miles
Je l'ai déjà croisé par hasard (je me rappelais vraiment plus du tout du nom). Payante?Citation:
Envoyé par Miles
J'imagine que pour ces 2 bibliothèques les sources ne sont malheureusement pas open source, et qu'elle ne tournent que sur des processeurs compatibles x86.
Pour repondre a ma queqtion. Ben non valarray de vc2005 ne fait pas de SIMD. De plus, elle n'as pas l'air de faire ce que je pensais..
remplacer par le compilot par :Code:Vres = V1*V2+V3;
merci pour les lib.Code:
2
Enfin c'est déjà pas mal, il te fait de la fusion de boucles...
Après une boucle comme ça, ça se vectorise automatiquement sans problème a priori.
je pensais qu'il faisait ça. mais vu le code il ne le fait pas. Il utilise des temp pour les operationCitation:
Envoyé par loufoque
Il est vraissemblable qu'il faille changer les options de compilations pour lui indiquer qu'il a le droit d'ajouter des instructions SIMD (vive la compatibilité i386...)
j'ai essayé en modifiant les option de visual. mais cela n'as rien changéCitation:
Envoyé par Miles
Ca suffira malheureusement pas. Les compilos ne sont pas "magiques". Au mieux il va intégrer ça ou là une instruction SIMD. Y'a plusieurs raisons à ça, en particulier ils ne peuvent pas juger de l'alignement mémoire, et dans le doute ils s'abstiennent de vectorialiser. De plus la vectorisation automatique ne fonctionne qu'avec des motifs imposés dans le code.Citation:
Envoyé par Miles
Le plus pratique et le plus contrôlable, c'est encore d'utiliser les fonctions intrasics d'Intel.
Je ne connais pas d'implémentation de la STL qui utilise les instructions SIMD, ceci dit c'est pas vraiment les containers et les algo de la STL qui pourraient vraiment tirer parti des SIMD. Il faut prendre la STL pour ce qu'elle est: un ensemble d'algo génériques. Libre à nous de les utiliser sur des containers utilisant les SIMD.
Et j'aime à peu près tout dans la STL (je commence certes à la trouver vieille et incomplète), à l'exception notable des valarrays qui sont en dessous de tout pour le calcul numérique. Je comprends pas pourquoi des gens ont perdu leur temps à en faire une implémentation SIMD...
PS:M'étonne pasCitation:
j'ai essayé en modifiant les option de visual. mais cela n'as rien changé
Parfois le compilo peut tout de même optimiser (en revanche, je ne sais pas ce que ça vaut). Par exemple ICC9.1 et 10 vectorisent certains algos de la STL (version GNU).
Toute facon y aurai que le vector qui pourrai utiliser les SIMD.Citation:
Envoyé par Charlemagne
Je trouve le concept super intéressant, pour ecrire un code lisible. Mais aprés recherche, c'est un truc que personne ne veut prendre la responsabilité de le définir. Et je pense que c'est la raison de sa faible efficacité. Aprés je pense que ça doit être un peu plus rapide qu'un vector (faut que je teste). Cela donne au moins une solution simple pour faire quelque calcul.Citation:
Envoyé par Charlemagne
Par contre, je me demande si il n'existe pas des implémentations pseudo-STL qui utiliserai OpenMP ( ou autre)
Ma mienne...Citation:
Envoyé par Mongaulois
OpenMP n'a rien à voir avec les instructions SIMD "vectorielles", mais ça fait du calcul multi-thread "parallèle" (je fais la distinction calculs vectoriels/parallèles, je ne sais pas si c'est la vrai dénomination).
Pour remplacer avantageusement OpenMP (qui ressemble à du mauvais C, comme dirait JP Coffe, c'est de la ...) par des algorithmes dans le style de la STL, y'a ma bibliothèque ou Intel TBB (dont la version 2 est devenue open source y'a qqs jours à peine)
Oui c'est une autre question. Bien sur il ne faut pas confomdre le SIMD et les thread...Citation:
Envoyé par Charlemagne
J'ai pas regarder TBB et ta lib encore.Citation:
Envoyé par Charlemagne
En regardant OpenMP, cela n'avait pas l'aire aussi mauvais. Aprés avoir discuté avec quelqu'un, cela avait vraiment l'air trés bien fait. Tu n'as pas a géré tout le processus de parallelisation.
Tu as juste a indique les zone a paralléliser et c'est a l'exécution que tout se fait. De plus OpenMP devient apparemment un standar et est multiplateforme.
Je regarderai TBB et ta lib. Merci pour les réponses
Encore heureux qu'OpenMP gère la parallélisation tout seul, c'est fait pour ça non!
C'est pas parce que ça devient un standard que c'est bon.
TBB est bien plus flexible, paramétrable, complet pour ceux qui apprécient la programmation générique "à la STL" (je tiens à préciser que je n'ai pas d'action Intel!). Les autres n'ont qu'à continuer à programmer en "C".
OpenMP n'est de surcroît compris que sur les compilos les plus récents (VC2005, GCC4.2). ICL (Intel C++ compiler) s'y est de toute évidence mis beaucoup plus tôt, car la version 8 (je l'ignore pour les versions antérieures) comprenait déjà OpenMP.
De plus , les benchs que j'ai fait (et fait faire dans dans d'autres topics) montre qu'OpenMP n'est pas si rapide que ça, en particulier pour des relatives petites boucles (pour lesquelles le multi-threading n'en vaut pas la peine et que la clause 'if' est sensée empêcher le sur-coût de synchronisation -un comble-, OpenMP se révèle calamiteusement lent sous tous les sytèmes et compilos testés).
Bref, je ne suis pas près de changer mon opinion sur OpenMP.
C'est peu être trop proche du compilot et trop jeune pour être deja super puissant et super optimizé. Je pense,qu'a la longue et si il est toujours soutenue par des industriel, il peut devenir bien plus puissant que n'importe quel lib de parallélisation. Enfin c'est mon point de vue actuel.Citation:
Envoyé par Charlemagne