GPU vs performances du processeur pour les algorithmes communs [fermé]

Question

Je voudrais savoir si des algorithmes courants (tri, recherche, graphes, etc.) ont été portés sous OpenCL (ou dans un langage GPU), et comment les performances se comparent au même algorithme exécuté par la CPU. Je suis particulièrement intéressé par les résultats (chiffres).

Merci!

Answer 1

Il existe de nombreux exemples de ce type d'informations sur le site Web de NVidia. N'oubliez pas que certaines opérations, telles que le tri, nécessitent des algorithmes spéciaux pour un parallélisme efficace et peuvent ne pas être tout à fait aussi efficaces qu'un algorithme sans thread sur un seul cœur.

Answer 2

Les GPU sont des matériels hautement spécialisés conçus pour effectuer très bien un petit ensemble de tâches hautement parallélisées. Ceci est essentiellement arithmétique (en particulier les calculs à virgule flottante simple précision bien que les nouveaux GPU se débrouillent plutôt bien avec la double précision). En tant que tels, ils ne sont adaptés qu'à des algorithmes particuliers. Je ne sais pas si le tri entre dans cette catégorie (du moins en général).

Des exemples plus courants sont les prix des instruments financiers, de grandes quantités de mathématiques matricielles et même neutralisation du cryptage (par la force brutale). Cela étant dit, j’ai trouvé un tri rapide parallèle sur GPU à l'aide d'un algorithme hybride .

Un autre exemple fréquemment cité est exécuter SETI @ HOME sur un GPU Nvidia , mais il compare les applications à des oranges. Les unités de travail des GPU sont différentes (et très limitées) par rapport à ce que les processeurs font habituellement.

Answer 3

Découvrez la poussée :

  

Thrust est une bibliothèque CUDA de fichiers parallèles   algorithmes avec une interface   ressemblant au modèle standard C ++   Bibliothèque (STL). La poussée fournit une   interface de haut niveau flexible pour GPU   une programmation qui améliore grandement   productivité des développeurs.

Answer 4

Soyez prudent, très inquiet de tout nombre de performance cité pour GPGPU. Beaucoup de gens aiment publier des chiffres vraiment impressionnants qui ne prennent pas en compte le temps de transfert nécessaire pour transférer les données d'entrée du processeur vers le processeur graphique et les données de sortie, en dépassant toutes deux un goulot d'étranglement PCIe.

Answer 5

Le redimensionnement des images doit être courant sur de nombreux sites Web acceptant les téléchargements d'images.

Le redimensionnement d’une image jpeg de 2 Mo à 2600ish x 2000ish (512x512) a pris 23,5 millisecondes en C # avec les options de qualité la plus basse absolue et l’échantillonnage le plus proche. La fonction utilisée était basée sur graphics.DrawImage () . L'utilisation du processeur était également% 21,5.

Obtention de "rgba byte array" l'extraction côté C # et son envoi vers le processeur graphique, son redimensionnement en processeur graphique et l'obtention des résultats dans une image ont pris 6,3 millisecondes et l'utilisation du processeur était de% 12,7. Cela a été fait avec un gpu% 55 moins cher avec seulement 320 cœurs.

Seulement multiplicateur d'accélération de 3,73X.

Le facteur limitant était l'envoi des données RVB extraites de 20 Mo (le format jpeg ne représente que 2 Mo!) au GPU. Cette partie qui prenait beaucoup de temps représentait près de 90% du temps total, y compris l'extraction de tableaux d'octets côté C #! Donc, je pense qu'il y aurait environ 30X accélération au moins si une partie de l'extraction pouvait aussi être faite en GPU.

30X n'est pas mauvais.

Vous pouvez ensuite canaliser la couche d'extraction avec la couche de redimensionnement pour masquer le temps d'attente de la copie en mémoire afin d'obtenir encore plus de vitesse! Cela pourrait être 40X-50X.

Ensuite, si vous augmentez la qualité de l’échantillonnage (bicubique au lieu de voisin proche), vous avez encore plus d’avantage côté GPU. L'ajout d'un filtre 5x5 gaussien n'a ajouté que 0,77 millisecondes. Le processeur gagnerait un temps supplémentaire, en particulier si les paramètres gaussiens nécessaires sont différents de ceux de l’implémentation C # .Net.

Même si vous n'êtes pas satisfait du taux d'accélération, du déchargement sur le processeur graphique et du "noyau libre". sur le processeur est toujours avantageux pour pousser plus de travail sur ce serveur.

Ajoutez maintenant le fait que les niveaux de consommation d'énergie du GPU (30W contre 125W dans cet exemple) sont beaucoup plus avantageux.

La CPU pourrait difficilement gagner en

 C[i]=A[i]+B[i]

tests lorsque les deux côtés fonctionnent avec des codes optimisés et que vous pouvez toujours décharger la moitié des baies sur le GPU et terminer plus rapidement en utilisant CPU + GPU en même temps.

Le GPU n'est pas conçu pour des travaux non uniformes. Les GPU ont des pipelines profonds, il est donc trop long de se lever après un décrochage en raison de la ramification. De plus, le matériel de type SIMD l'oblige à faire la même chose pour tous les éléments de travail dessus. Lorsqu'un élément de travail fait une opération différente de celle du groupe, il perd la trace et ajoute des bulles dans tout le pipeline SIMD ou simplement, d'autres attendent le point de synchronisation. La fusion affecte donc les zones de pipeline profondes et étendues et la rend encore plus lente que le processeur dans des conditions parfaitement chaotiques.