lib matrice portable

Bonjour,

Les posts ont deja traité de librairie de calcul matricielle, specilament pour les matrices de grande taille.

Dans mon cas mes matrices sont au max 3x3 et je ne leur demande pas autre chose que de contenir des doubles et de me sortir les valeurs et vecteurs propre. Et je compte garder la portabilité de mon dode Windows/Unix (ce qui semble exclure Atlas maheureusement a moins de fournir avec mon code un mode d'emploi détaillé pour son install sous windows).

Comprenez moi bien, c'est calcul se portent sur un tres grand nombre de matrice et la moindre milliseconde gagnée est non négligeable...

Merci

Et tu a regardé du côté de MTL, Blitz++, ... ?

Oui, les noms reviennent régulièrement sur le forum, je voudrais en fait savoir laquelle est la plus performante dans mon cas. Je n'ai pas besoin d'une lib vraiment générique, je pense qu'au contraire une petite lib specialisé sera plus performante, non (vs par exemple la MTL)?

Pourquoi pas programmer toi même.
-Ne fais pas de boucles
-utilise des variables pour sauvegarder les accès mémoires
-SSE SSE2 SSE3

SSE 8O je ne vois pas.

Utilisation des instructions parallèles du processeur.

SSE,SSE2,SSE3 sont les successeurs des instructions MMX.
On ne peut pas parler d'optimisations si on n'utilise pas les instructions SIMD du processeur.

Les instructions SSE1(Pentium 3) permettent entre autres de manipuler 4 floats à la fois, SSE2 (Pentium 4) de manipuler 2 doubles à la fois.

Et bientôt SSE4 :D

vous avez loupé le SSE3 :roll:

Citation:

---

Et bientôt SSE4

---

J'ai été déçu par SSE3. Ca sert pas à grand chose comparativement à SSE/SSE2.
Je crois que SSE4 n'apportera environ qu'une douzaine d'instructions nouvelles, mais je sais pas lesquelles.
Je crois que SSE3 et SSE4 sont surtout commerciaux, pour se démarquer temporairement d'AMD. Et puis les programmes utilisant SSE3 ne sont pas légions...

Blitz++ : ancêtre de référence. boost.ublas challenger. Leur portabilité exige des compilos "récents" (i.e. pas ceux qui ont pratiquement 9 ans ...). Ils ont des types tinyArray qui correspondent à des matrices non redimensionnables, à la taille connue lors de la compilation.

MTL, plus maintenue.

ATLAS. Si elle focalise sur les SSE & cie, je ne la qualifierai pas de portable. Si elle ne fait qu'exploiter le pipeline d'une archi bien précise. Alors c'est jouable, je pense. Je crois qu'elle a une API C par contre. C'est dommage quand on voit que Blitz++ et boost.ublas savent offrir une expressivité quasi mathématique aux objets matriciels, et ce sans perte de perf.

Autre piste peut-être. Il n'y a pas des routines cablées dans les procs graphiques pour gérer les matrices 3x3 et les 4x4 ?

Citation:

---

Autre piste peut-être. Il n'y a pas des routines cablées dans les procs graphiques pour gérer les matrices 3x3 et les 4x4 ?

---

Pour les valeurs / vecteurs propres, pas vraiment non :aie:

On peut faire faire des choses marrantes aux GPUs actuels, mais globalement pour ce genre de question je pense que c'est une mauvaise piste.

Citation:

---

ATLAS. Si elle focalise sur les SSE & cie, je ne la qualifierai pas de portable. Si elle ne fait qu'exploiter le pipeline d'une archi bien précise. Alors c'est jouable, je pense. Je crois qu'elle a une API C par contre. C'est dommage quand on voit que Blitz++ et boost.ublas savent offrir une expressivité quasi mathématique aux objets matriciels, et ce sans perte de perf.

---

ATLAS se laisse compiler sous de nombreux systèmes (SSE, Altivec) et s'adapte lors de l'installation à ceux ci (mémoire cache...), donc elle est portable.
Mais la librairie ATLAS est lente pour les très petites matrices (toute proportion gardée) à cause des nombreux tests et appels de fonction qu'elle fait avant d'attaquer la multiplication proprement dite. Maintenant c'est pas sûr que Blitz et Co soient plus rapides pour les très petites tailles.
Certes je déteste l'interface BLAS moi aussi, mais je crois que pour les fans de Boost que vous êtes, je crois que UBLAS sait interfacer ATLAS.

De toute facon le plus rapide qu'on puisse faire consiste à programmer une version spécialisée pour chaque taille de matrice. C'est pas la mer à boire pour de si petites matrices.
-pas de boucles, pas de tests
-rétension des valeurs dans les registres
-SIMD