La virgule flottante simple précision est-elle si mauvaise?

8

J'ai regardé certains des packages de la vue de tâche High perf traitant des calculs GPU, et étant donné que la plupart des GPU semblent être d'un ordre de grandeur plus forts pour effectuer des calculs arithmétiques en simple précision que ceux DP , je me demandais:

Pourquoi aucun des packages ne donne plus de contrôle à l'utilisateur sur le type de précision requis? Je peux voir de nombreuses applications dans les statistiques où les arithmétiques SP (c'est-à-dire codées avec une précision à 7 chiffres) sont assez bonnes pour une utilisation pratique (si je surestime les gains impliqués, faites-le moi savoir).
Python est-il plus flexible à ce sujet? Si oui, pourquoi ? Je ne vois pas pourquoi l'absence d'un type `` unique '' dans R rendrait impossible l'inclusion d'une telle option (avec un avertissement) dans, disons, GPUtools ou magma (bien que je serais heureux de me tromper).

PS: je pense spécifiquement aux applications où les nombres sont déjà dimensionnés et centrés (de sorte que l' inégalité de Chebychev est contraignante) dimensionnellement.

r python gpu

— user603
source

2

J'avoue être mystifié par cela, même s'il a eu plusieurs fois du mal à le comprendre: y a-t-il une question ici? "So bad" est vague et n'a pas de référent. Que cherchez-vous exactement à comprendre ou à découvrir?

— whuber

@Whuber:> Ma question était mal formulée. Cela était probablement dû au fait qu'il était né de l'ignorance: j'avais lu quelques livres blancs sur l'utilisation du GPU (bien que, malheureusement, il s'avère que ce ne soit pas la référence de la commande R de GPUtools) et ne comprenais pas pourquoi tous les tests avaient été effectués. en DP. Je vais reformuler la question (et le titre).

— user603

5

D'après le fichier d'aide de GPUtools , il semble que ce useSingle=TRUEsoit la valeur par défaut pour les fonctions.

— ars
source

@kwak: Je trouve la réponse ci-dessus utile, mais elle ne répond vraiment pas à la question posée - "la précision simple est-elle si mauvaise?" Vous devriez peut-être reformuler votre question?

— csgillespie

@csgellespie: vous avez totalement raison. Je reformulerai cette question afin qu'elle puisse être utilisée par les futurs lecteurs. En effet, la formulation était particulièrement mauvaise.

— user603

4

Parce qu'avant les GPU, il n'y avait aucun sens pratique d'utiliser des réels uniques; vous n'avez jamais trop de précision et la mémoire n'est généralement pas un problème. Et la prise en charge uniquement des doubles a simplifié la conception de R. (Bien que R supporte la lecture / l'écriture de réels simples.)
Oui, car Python vise à être plus compatible avec les langages compilés. Pourtant, vous avez raison, il est possible que les wrappers des bibliothèques R effectuent une conversion à la volée (cela prend bien sûr du temps mais c'est un problème mineur); vous pouvez essayer d'envoyer des e-mails aux responsables des packages GPU pour demander ces modifications.

3

Je suppose que par programmation GPU, vous voulez dire la programmation de cartes NVIDIA? Dans ce cas, les appels de code sous-jacents depuis R et python sont vers C / CUDA .

La raison simple pour laquelle une seule précision est offerte est que c'est ce que la plupart des cartes GPU prennent en charge.

Cependant, la nouvelle architecture nvidia Fermi prend en charge la double précision. Si vous avez acheté une carte graphique nvidia cette année, c'est probablement un Fermi. Même ici, les choses ne sont pas simples:

Vous obtenez un léger coup de performance si vous compilez avec une double précision (un facteur de deux si je me souviens bien).
Sur les cartes Fermi moins chères, NVIDIA a intentionnellement désactivé la double précision. Cependant, il est possible de contourner cela et d'exécuter des programmes en double précision. J'ai réussi à le faire sur ma GeForce GTX 465 sous Linux.

Pour répondre à la question dans votre titre, "La précision simple est-elle OK?", Cela dépend de votre application (désolé réponse merde!). Je suppose que tout le monde utilise maintenant la double précision, car cela ne donne plus de résultats.

Quand j'ai essayé les GPU, la programmation est soudainement devenue beaucoup plus compliquée. Vous devez vous soucier de choses comme:

déformer et organiser votre mémoire correctement.
#threads par noyau.
le débogage est horrible - il n'y a pas de déclaration d'impression dans les déclarations du noyau GPU
manque de générateurs de nombres aléatoires
Précision simple.

— csgillespie
source

@ccgillespie:> je pense que ma question a peut-être été mal formulée. Dans le package que je vois (GPUtools, magma), la double précision semble être utilisée en standard (avec la perte de performances que vous décrivez). Je me demandais pourquoi la précision unique n'est pas proposée en option.

— user603

@kwak: Les valeurs de double précision doivent être converties en simple précision par l'encapsuleur. L'emballage essayait juste d'être utile.

— csgillespie

@ccgillespie:> oui, mais il semble que le wrapper présente des coûts de performance dépassant le facteur 2 que vous citez (encore une fois, corrigez-moi si je me trompe) et dans certains cas, aucun avantage tangible (je peux penser à de nombreuses applications dans stat si l'arithmétique SP FP serait acceptable). Je me demandais s'il était logique de demander une option pour désactiver ledit wrapper.

— user603

2

@kwak: En jetant un œil au fichier d'aide de GPUtools, il semble que cela useSingle=TRUEsemble être la valeur par défaut dans les fonctions. Est-ce que j'ai râté quelque chose?

— ars

@csgillespie: Souvenez-vous, jusqu'à une date relativement récente, la plupart des cartes nvidia ne pouvaient tout simplement pas faire de calcul en double précision. Le facteur de 2 coups est ce que j'ai observé en utilisant du code C / CUDA brut. Avoir un wrapper python / R peut aggraver la situation.

— csgillespie

1

La grande majorité des GPU en circulation ne prennent en charge que la virgule flottante simple précision.

En ce qui concerne la question du titre, vous devez regarder les données que vous manipulerez pour déterminer si la précision simple vous suffit. Souvent, vous constaterez que les célibataires sont parfaitement acceptables pour> 90% des données que vous gérez, mais échoueront spectaculairement pour les 10% restants; sauf si vous avez un moyen facile de déterminer si votre ensemble de données particulier échouera ou non, vous êtes bloqué en utilisant la double précision pour tout.

— Benjamin Chambers
source

Pouvez-vous élaborer un peu? Il semble que certains algorithmes itératifs (inversion de matrice, décomposition QR) semblent bien fonctionner. Je suis également curieux de savoir si l'inexactitude de SP devient plus un problème pour les opérations impliquant des baies plus grandes.

— user603

Il comporte deux parties: 1) Que représentent les données? 2) Comment traitez-vous les données? Si vous regardez des milliers de points de données d'une étude médicale, la simple précision serait probablement suffisante pour quantifier le bien-être des patients, et je doute que vous en ayez jamais besoin. La géométrie, d'autre part, peut nécessiter une précision simple ou double selon votre échelle et votre zoom. Le calcul de la trajectoire d'une sonde vers Saturne nécessiterait toujours des doubles, car même de petites erreurs pourraient considérablement affecter le résultat. Vous devez regarder les données et décider quelles sont vos tolérances.

— Benjamin Chambers

1

Cela dépendra de la stabilité numérique de l'algorithme que vous utilisez et de la façon dont le problème est conditionné. N'oubliez pas que la double précision vous donne accès à des nombres plus petits et plus grands.

— James

1

Pas nécessairement des nombres plus petits ou plus grands; rappelez-vous, nous avons affaire à virgule flottante. Au contraire, il vous permet d'utiliser des nombres plus grands et plus petits les uns par rapport aux autres, tout en préservant les chiffres significatifs.

— Benjamin Chambers

1

OK, une nouvelle réponse à une vieille question mais encore plus pertinente maintenant. La question que vous posez concerne la précision finie, normalement le domaine de l'analyse du signal et des mathématiques expérimentales.

Les flotteurs à double précision (DP) nous permettent de prétendre qu'il n'existe pas de problèmes de précision finie, comme nous le faisons avec la plupart des problèmes mathématiques du monde réel. En mathématiques expérimentales, il n'y a pas de faux semblant.

Les flotteurs à simple précision (SP) nous obligent à considérer le bruit de quantification. Si nos modèles d'apprentissage automatique rejettent intrinsèquement le bruit, comme les réseaux de neurones (NN), les réseaux de convolution (CNN), les réseaux résiduels (ResN), etc., alors SP donne le plus souvent des résultats similaires à DP.

Les flotteurs à demi-précision (HP) (désormais pris en charge dans la boîte à outils cuda 7.5) nécessitent la prise en compte des effets de quantification (bruit et arrondi). Très probablement, nous verrons bientôt des flotteurs HP dans les boîtes à outils d'apprentissage automatique courantes.

Il existe des travaux récents pour créer des calculs de précision inférieure dans des flottants ainsi que des nombres de précision fixes. L'arrondi stochastique a permis à la convergence de fonctionner avec les CNN tandis que la solution diverge sans elle. Ces articles vous aideront à améliorer votre compréhension des problèmes liés à l'utilisation de nombres à précision finie dans l'apprentissage automatique.

Pour répondre à vos questions:

SP n'est pas si mal. Comme vous le faites remarquer, c'est deux fois plus rapide, mais cela vous permet également de mettre plus de couches en mémoire. Un avantage est d'économiser des frais généraux pour obtenir des données sur et hors du GPU. Les calculs plus rapides et les frais généraux inférieurs entraînent des temps de convergence plus courts. Cela dit, HP, pour certains problèmes, sera meilleur dans certaines parties du réseau et pas dans d'autres.

Il me semble que de nombreuses boîtes à outils d'apprentissage automatique gèrent les SP et les DP. Peut-être que quelqu'un d'autre avec un éventail plus large d'expérience avec les boîtes à outils ajoutera son nickel.
Python prendra en charge ce que prend en charge la boîte à outils gpu. Vous ne voulez pas utiliser de types de données python car vous exécuterez alors un script interprété sur le processeur.

Notez que la tendance dans les réseaux de neurones est maintenant d'aller avec des couches très profondes, avec des exécutions de plus de quelques jours sur les clusters de GPU les plus rapides.

— r3mnant
source