MISE À JOUR (30.07.2014):
Je relance le benchmark sur notre nouveau HPC. Le matériel ainsi que la pile logicielle ont changé par rapport à la configuration dans la réponse d'origine.
Je mets les résultats dans une feuille de calcul google (contient également les résultats de la réponse originale).
Matériel
Notre HPC possède deux nœuds différents, l'un avec les processeurs Intel Sandy Bridge et l'autre avec les processeurs Ivy Bridge les plus récents:
Sandy (MKL, OpenBLAS, ATLAS):
- Processeur : 2 x 16 Intel (R) Xeon (R) E2560 Sandy Bridge à 2,00 GHz (16 cœurs)
- Mémoire RAM : 64 Go
Ivy (MKL, OpenBLAS, ATLAS):
- Processeur : 2 x 20 Intel (R) Xeon (R) E2680 V2 Ivy Bridge à 2,80 GHz (20 cœurs, avec HT = 40 cœurs)
- Mémoire RAM : 256 Go
Logiciel
La pile logicielle est pour les deux nœuds le sam. Au lieu de GotoBLAS2 , OpenBLAS est utilisé et il existe également un ATLAS BLAS multithread défini sur 8 threads (codé en dur).
- OS : Suse
- Compilateur Intel : ictce-5.3.0
- Numpy: 1.8.0
- OpenBLAS: 0.2.6
- ATLAS :: 3.8.4
Benchmark des produits scalaires
Le code de référence est le même que ci-dessous. Cependant, pour les nouvelles machines, j'ai également utilisé le benchmark pour les tailles de matrice 5000 et 8000 .
Le tableau ci-dessous comprend les résultats de référence de la réponse originale (renommée: MKL -> Nehalem MKL, Netlib Blas -> Nehalem Netlib BLAS, etc.)
Performances à filetage unique:
Performances multi-threads (8 threads):
Threads vs taille de la matrice (Ivy Bridge MKL) :
Suite Benchmark
Performances à filetage unique:
Performances multi-threads (8 threads):
Conclusion
Les nouveaux résultats de référence sont similaires à ceux de la réponse originale. OpenBLAS et MKL fonctionnent au même niveau, à l'exception du test Eigenvalue . Le test Eigenvalue ne fonctionne que raisonnablement bien sur OpenBLAS en mode mono-thread . En mode multi-thread, les performances sont pires.
Le "tableau de la taille de la matrice par rapport aux threads" montre également que bien que MKL ainsi qu'OpenBLAS s'adaptent généralement bien avec le nombre de cœurs / threads, cela dépend de la taille de la matrice. Pour les petites matrices, l'ajout de cœurs supplémentaires n'améliorera pas beaucoup les performances.
Il y a également une augmentation des performances d'environ 30% de Sandy Bridge à Ivy Bridge, ce qui pourrait être dû à une fréquence d'horloge plus élevée (+ 0,8 GHz) et / ou à une meilleure architecture.
Réponse originale (04.10.2011):
Il y a quelque temps, j'ai dû optimiser certains calculs / algorithmes d'algèbre linéaire écrits en python en utilisant numpy et BLAS, j'ai donc évalué / testé différentes configurations numpy / BLAS.
Plus précisément, j'ai testé:
- Numpy avec ATLAS
- Numpy avec GotoBlas2 (1.13)
- Numpy avec MKL (11.1 / 073)
- Numpy avec Accelerate Framework (Mac OS X)
J'ai exécuté deux benchmarks différents:
- produit scalaire simple de matrices de différentes tailles
- Benchmark suite qui peut être trouvée ici .
Voici mes résultats:
Machines
Linux (MKL, ATLAS, No-MKL, GotoBlas2):
- Système d'exploitation : Ubuntu Lucid 10.4 64 bits.
- Processeur : 2 x 4 Intel (R) Xeon (R) E5504 à 2,00 GHz (8 cœurs)
- Mémoire RAM : 24 Go
- Compilateur Intel : 11.1 / 073
- Scipy : 0,8
- Numpy : 1,5
Mac Book Pro (Accelerate Framework):
- Système d'exploitation : Mac OS X Snow Leopard (10.6)
- CPU : 1 Intel Core 2 Duo 2,93 Ghz (2 cœurs)
- Mémoire RAM : 4 Go
- Scipy : 0,7
- Numpy : 1,3
Mac Server (Accelerate Framework):
- Système d'exploitation : Mac OS X Snow Leopard Server (10.6)
- Processeur : 4 X Intel (R) Xeon (R) E5520 @ 2,26 Ghz (8 cœurs)
- Mémoire RAM : 4 Go
- Scipy : 0,8
- Numpy : 1.5.1
Benchmark produit dot
Code :
import numpy as np
a = np.random.random_sample((size,size))
b = np.random.random_sample((size,size))
%timeit np.dot(a,b)
Résultats :
Système | taille = 1000 | taille = 2000 | taille = 3000 |
netlib BLAS | 1350 ms | 10900 ms | 39200 ms |
ATLAS (1 processeur) | 314 ms | 2560 ms | 8700 ms |
MKL (1 processeurs) | 268 ms | 2110 ms | 7120 ms |
MKL (2 processeurs) | - | - | 3660 ms |
MKL (8 processeurs) | 39 ms | 319 ms | 1000 ms |
GotoBlas2 (1 processeur) | 266 ms | 2100 ms | 7280 ms |
GotoBlas2 (2 processeurs) | 139 ms | 1009 ms | 3690 ms |
GotoBlas2 (8 processeurs) | 54 ms | 389 ms | 1250 ms |
Mac OS X (1 processeur) | 143 ms | 1060 ms | 3605 ms |
Serveur Mac (1 processeur) | 92 ms | 714 ms | 2130 ms |
Suite Benchmark
Code :
Pour plus d'informations sur la suite de référence, cliquez ici .
Résultats :
Système | valeurs propres | svd | det | inv | point |
netlib BLAS | 1688 ms | 13102 ms | 438 ms | 2155 ms | 3522 ms |
ATLAS (1 processeur) | 1210 ms | 5897 ms | 170 ms | 560 ms | 893 ms |
MKL (1 processeurs) | 691 ms | 4475 ms | 141 ms | 450 ms | 736 ms |
MKL (2 processeurs) | 552 ms | 2718 ms | 96 ms | 267 ms | 423 ms |
MKL (8 processeurs) | 525 ms | 1679 ms | 60 ms | 137 ms | 197 ms |
GotoBlas2 (1 processeur) | 2124 ms | 4636 ms | 147 ms | 456 ms | 743 ms |
GotoBlas2 (2 processeurs) | 1560 ms | 3278 ms | 116 ms | 295 ms | 460 ms |
GotoBlas2 (8 processeurs) | 741 ms | 2914 ms | 82 ms | 262 ms | 192 ms |
Mac OS X (1 processeur) | 948 ms | 4339 ms | 151 ms | 318 ms | 566 ms |
Serveur Mac (1 processeur) | 1033 ms | 3645 ms | 99 ms | 232 ms | 342 ms |
Installation
L'installation de MKL comprenait l'installation de la suite complète de compilateurs Intel, ce qui est assez simple. Cependant, à cause de certains bogues / problèmes, la configuration et la compilation de numpy avec le support MKL étaient un peu compliquées.
GotoBlas2 est un petit paquet qui peut être facilement compilé en tant que bibliothèque partagée. Cependant, à cause d'un bogue, vous devez recréer la bibliothèque partagée après l'avoir construite afin de l'utiliser avec numpy.
En plus de cette construction, il pour plusieurs plates-formes cibles n'a pas fonctionné pour une raison quelconque. J'ai donc dû créer un fichier .so pour chaque plateforme pour laquelle je souhaite avoir un fichier libgoto2.so optimisé .
Si vous installez numpy à partir du référentiel d'Ubuntu, il installera et configurera automatiquement numpy pour utiliser ATLAS . L'installation d' ATLAS à partir des sources peut prendre un certain temps et nécessite des étapes supplémentaires (fortran, etc.).
Si vous installez numpy sur une machine Mac OS X avec des ports Fink ou Mac, il configurera numpy pour utiliser ATLAS ou Accelerate Framework d'Apple . Vous pouvez vérifier en exécutant ldd sur le fichier numpy.core._dotblas ou en appelant numpy.show_config () .
Conclusions
MKL fonctionne mieux suivi de près par GotoBlas2 .
Dans le test de valeur propre , GotoBlas2 fonctionne étonnamment moins bien que prévu. Je ne sais pas pourquoi c'est le cas.
L'Accelerate Framework d'Apple fonctionne vraiment bien, en particulier en mode mono-thread (par rapport aux autres implémentations BLAS).
Les deux GotoBlas2 et MKL s'adaptent très bien avec le nombre de threads. Donc, si vous devez gérer de grandes matrices, l'exécuter sur plusieurs threads vous aidera beaucoup.
Dans tous les cas, n'utilisez pas l' implémentation par défaut de netlib blas car elle est bien trop lente pour tout travail de calcul sérieux.
Sur notre cluster, j'ai également installé l'ACML d'AMD et les performances étaient similaires à MKL et GotoBlas2 . Je n'ai pas de chiffres difficiles.
Personnellement, je recommanderais d'utiliser GotoBlas2 car il est plus facile à installer et gratuit.
Si vous voulez coder en C ++ / C, consultez également Eigen3 qui est censé surpasser MKL / GotoBlas2 dans certains cas et est également assez facile à utiliser.