Pourquoi ne pas GCC optimiser unununununun (aaa)(aaa)?

Je fais un certain optimisation numérique sur une application scientifique. Une chose que j'ai remarqué, c'est que GCC permettra d'optimiser l'appel pow(a,2) par la compilation en a*a, mais l'appel pow(a,6) n'est pas optimisé et fait appel une fonction de la bibliothèque pow, ce qui a considérablement ralentit les performances. (En revanche, Le Compilateur Intel C++ , exécutable icc, permettra d'éliminer l'appel de la bibliothèque pour pow(a,6).)

Ce que je suis curieux de savoir, c'est que quand j'ai remplacé pow(a,6) avec a*a*a*a*a*a à l'aide de GCC 4.5.1 et options "-O3 -lm -funroll-loops -msse4", il utilise 5 mulsd instructions:

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13

alors que si j'écris (a*a*a)*(a*a*a), il va produire

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm13, %xmm13

qui réduit le nombre d'instructions de multiplication de 3. icc a un comportement similaire.

Pourquoi les compilateurs ne pas reconnaître cette optimisation truc?

Ce n' "reconnaissant pow(a,6)" signifie?
Je suis surpris gcc ne pas optimiser ce. Les années 1970 compilateur FORTRAN j'ai utilisé sur CDC Cyber n'a ce genre de transformation, même sans sélectionner d'optimisation. Je pense que les Unix V6 (c. 1978) C compilateur fait lorsque l'optimisation est activée, si de nombreuses optimisations il n'a été à enregistrer le code de l'espace, une denrée précieuse en ces jours.
Euh... vous savez que aaaaaa et (aaa)*(aa*a) ne sont pas la même chose avec des nombres à virgule flottante, n'est-ce pas? Vous aurez à utiliser -funsafe-math ou -ffast-math ou quelque chose pour que.
Je vous suggère de lire "Ce que Chaque informaticien Devriez Savoir Sur l'Arithmétique à virgule Flottante" par David Goldberg: download.oracle.com/docs/cd/E19957-01/806-3568/... après quoi vous aurez une compréhension plus complète de la fonctionnalité tar pit que vous avez juste entré en!
Une question parfaitement justifiée. 20 ans auparavant, j'ai posé la même question d'ordre général, et en écrasant que seul goulet d'étranglement, réduit le temps d'exécution d'une simulation de Monte Carlo à partir de 21 heures à 7 heures. Le code dans la boucle interne a été exécuté 13 milliards de fois dans le processus, mais il a obtenu la simulation en cours de nuit de la fenêtre. (voir la réponse ci-dessous)
Peut-être jeter (a*a)*(a*a)*(a*a) dans le mélange, trop. Même nombre de multiplications, mais probablement plus exacte.
Pour commencer, comment cela est optimisé dépend grandement de ce type a a...
Shameless plug: en plus de Goldberg de papier, je suggère la lecture de la mine, hal.archives-ouvertes.fr/file/index/docid/281429/filename/...
en fait, un bon optimiseur pourrait prendre un peu plus loin. a*a seulement besoin d'être effectuée qu'une fois. Les résultats pouvaient être réutilisés assez facilement à le réduire à seulement 3 opérations de multiplication.
Oui, 3, exactement le même que (a*a*a)*(a*a*a), c'est ce que j'ai proposé comme une alternative. Qu'essayez-vous de dire?

InformationsquelleAutor xis | 2011-06-21

2693

Parce que Calcul en virgule flottante n'est pas Associatif. La façon dont vous groupe les opérandes en virgule flottante multiplication a un effet sur la précision numérique de la réponse.

En conséquence, la plupart des compilateurs sont très conservateurs au sujet de la réorganisation des calculs en virgule flottante, sauf s'ils peuvent être sûr que la réponse reste la même, ou à moins que vous leur dites que vous ne se soucient pas de l'exactitude numérique. Par exemple: l'option -fassociative-math de gcc qui permet de gcc pour réassocier les opérations en virgule flottante, ou même la -ffast-math option qui permet encore plus agressif compromis de précision par rapport à la vitesse.
- Oui. Avec -ffast-math il est en train de faire une telle optimisation. Bonne idée! Mais depuis notre code concerne plus de précision que la vitesse, il peut être préférable de ne pas la transmettre.
- IIRC C99 permet au compilateur de faire ce genre de "dangereux" FP optimisations, mais GCC (sur autre chose que le x87) fait une tentative raisonnable à la suite de la norme IEEE 754 - il pas d'erreur "limites"; il n'existe qu'une seule bonne réponse,.
- Les détails de mise en œuvre de pow sont ni ici ni là; cette réponse n'a même pas de référence pow.
- la base de mon argument était que toute convergence de routine, dépendante sur le même matériel de point flottant comme une série de multiplications, ne pourrait pas être plus précis. Cela s'avère ne pas être vrai, parce que la convergence des routines de tricher, dans le bon sens. Ils interpoler entre précalculées les valeurs de la table qui se trouvent sur des puissances de 2 limites. L'erreur dans l'interpolation est donc très faible. Je vais aussi vous dire que pour les petites puissances, comme 6, d'une puissance entière de la fonction n'est juste ainsi. Encore, si vous étiez un compilateur de l'écrivain, je suis sûr que vous les mettiez ces optimisations dans la pow().
- Donc ma question est ... est-ce à dire que le Compilateur Intel est d'effectuer l'optimisation au détriment de la précision et de l'exactitude? Ou faut-il trouver un autre moyen d'optimiser tout en s'assurant de l'exactitude?
- La CPI par défaut permettant de ré-association. Si vous souhaitez obtenir standard conforme comportement, vous devez définir -fp-model precise avec la CPI. clang et gcc défaut de conformité w.r.t. réassociation.
- ce n'est pas vraiment -fassociative-math serait inaccurrate; c'est juste que a*a*a*a*a*a et (a*a*a)*(a*a*a) sont différents. Ce n'est pas au sujet de l'exactitude; c'est à propos de conformité aux normes et strictement la répétabilité des résultats, p. ex. les mêmes résultats sur un compilateur. Les nombres à virgule flottante sont déjà pas exact. Il n'est inappropriée pour compiler avec -fassociative-math.
- Si vous voulez l'exactitude, préférez (ununa)*(auna). Les raisons possibles sont plus équilibrés tailles des opérandes, ununununa >> a (>> beaucoup plus grand que), et moins d'opérations, de réduire le nombre de troncatures.
InformationsquelleAutor
642

Lambdageek souligne à juste titre que, parce que l'associativité n'est pas valable pour les nombres à virgule flottante, le "optimisation" de a*a*a*a*a*a à (a*a*a)*(a*a*a) peut modifier la valeur. C'est pourquoi il est rejeté par C99 (sauf si expressément autorisé par l'utilisateur, via le compilateur drapeau ou pragma). Généralement, l'hypothèse est que le programmeur a écrit ce qu'elle a fait pour une raison, et le compilateur doit la respecter. Si vous voulez (a*a*a)*(a*a*a), d'écrire cela.

Qui peut être difficile à écrire, mais, pourquoi ne pouvons-le compilateur just do [ce que vous considérez être la chose lorsque vous utilisez pow(a,6)? Parce que ce serait l' mal chose à faire. Sur une plate-forme avec une bonne bibliothèque de mathématiques, pow(a,6) est beaucoup plus précis que ce soit a*a*a*a*a*a ou (a*a*a)*(a*a*a). Simplement de fournir quelques données, j'ai couru une petite expérience sur mon Mac Pro, la mesure de la pire des erreurs dans l'évaluation d'un^6 pour tous flottante simple précision chiffres entre [1,2):
```
worst relative error using    powf(a, 6.f): 5.96e-08
worst relative error using (a*a*a)*(a*a*a): 2.94e-07
worst relative error using     a*a*a*a*a*a: 2.58e-07
```
À l'aide de pow au lieu d'une multiplication de l'arbre réduit l'erreur lié par un facteur de 4. Les compilateurs ne doit pas (et ne sont généralement pas) de faire des "optimisations" qui augmentent d'erreur sauf s'ils sont autorisés à le faire par l'utilisateur (par exemple, via -ffast-math).

Noter que GCC fournit __builtin_powi(x,n) comme une alternative à pow( ), ce qui devrait générer une ligne de multiplication de l'arbre. L'utiliser si vous le souhaitez, faire des compromis précision pour les performances, mais ne souhaitez pas activer fast-math.
- Notez également que Visual C++ fournit un "renforcée" version " de pow(). En appelant _set_SSE2_enable(<flag>) avec flag=1, il va utiliser le SSE2, si possible. Cela réduit la précision par un peu, mais améliore la vitesse (dans certains cas). MSDN: _set_SSE2_enable() et pow()
- Avec une bonne bibliothèque de mathématiques, il en ira de même pour le double (et en fait, pour une variable de type point).
- à l'aide de SSE2 n'a pas besoin nécessairement de réduire la précision, même. Plus moderne des bibliothèques de mathématiques sur x86 utilisation de l'ESS quand il est disponible, et beaucoup d'entre elles fournissent des résultats très précis.
- La documentation MSDN lui-même indique qu'il peut être une perte de précision lorsque les instructions SSE2 sont utilisés (comme ils le sont par défaut) en raison de l'intermédiaire des registres d'être 80bit sur la FPU et 64 bits lors de l'utilisation de SSE2.
- Toute perte de précision est due à la mise en œuvre Microsoft, pas de la taille des registres utilisés. Il est possible de livrer un correctement arrondie pow en utilisant uniquement des registres 32 bits, si la bibliothèque de l'écrivain est donc motivé. Il y a de l'ESS à base de pow des implémentations plus exact que la plupart des x87 implémentations basées, et il y a aussi des implémentations d'un compromis entre la précision de la vitesse.
- Bien sûr, vous pouvez faire une mesure plus précise de la mise en œuvre à l'aide de rien 8bit registres et un petit tableau. Cependant, j'ai été et je suis encore plus précisément parler de Visual C++de mise en œuvre de pow(). "Pourrait" et "possible" ne sont pas "EST" 🙂
- Bien sûr, je voulais juste préciser que la réduction de la précision est due à des choix faits par la bibliothèque des écrivains, pas intrinsèque à l'utilisation de l'ESS.
- Je suis curieux de savoir ce que vous utilisé comme le "gold standard" ici pour le calcul des erreurs relatives -- je serait normalement attendu à ce qu'elle serait a*a*a*a*a*a, mais ce n'est apparemment pas le cas! 🙂
- depuis que je suis en comparant simple précision des résultats, double-précision suffit pour un gold standard de l'erreur à partir d'unununununcalculées en double est très plus petite que l'erreur de de la seule précision des calculs.
- Trois observations. (a) +1. C'est une très belle réponse. (b) Un meilleur étalon-or: std::pow((long double)a,6). (c) Il existe une troisième voie: l'utilisation de double précision pour les calculs, par exemple l'appel à Szabolcs de power modèle de fonction par power<6,double>(a). Maintenant, vous obtenez une demi-ULP précision (comme un float résultat), mais avec seulement une petite perte de performance (1,4 fois plus long que a*a*a*a*a*a comme un float). Comparer avec l'énorme performance de pénalité (32.4 fois plus de temps sur ma machine) que les résultats de l'appel std::pow(float,float).
- Long Double serait de ne rien faire sur MSVC de la mise en œuvre, et plus d'un autre; type pun double long double. Vous devez assurez-vous que long double a été bien pris en charge avant de dire que c'est un meilleur étalon-or.
- Peut-être jeter (a*a)*(a*a)*(a*a) dans le mélange, trop. Même nombre de multiplications, mais probablement plus exacte.
- "Généralement, l'hypothèse est que le programmeur a écrit ce qu'elle a fait pour une raison, et le compilateur doit la respecter. Si vous voulez (ununa)*(auna), d'écrire cela." ce raisonnement, tout ce qui pourrait/devrait être oublié depuis la première macro-capable assembleurs...
- Ce serait génial si vous pouviez partager le code source du programme responsable de l'erreur relative de la table, là.
InformationsquelleAutor Stephen Canon
165

Un autre cas semblable: la plupart des compilateurs n'optimise pas a + b + c + d à (a + b) + (c + d) (c'est une optimisation depuis la seconde expression peut être canalisée mieux) et de l'évaluer en tant que donnée (c'est à dire que (((a + b) + c) + d)). C'est aussi en raison de cas de coin:
```
float a = 1e35, b = 1e-5, c = -1e35, d = 1e-5;
printf("%e %e\n", a + b + c + d, (a + b) + (c + d));
```
Ce sorties 1.000000e-05 0.000000e+00
- Ce n'est pas exactement la même. Changin l'ordre des multiplications/divisions (à l'exclusion de la division par 0) est plus sûr que changin afin de somme/soustraction. À mon humble avis, le compilateur doit essayer d'associer des multis./les divs. parce que faire que de réduire le nombre total d'opérations et à côté le gain de performance ther est aussi un gain de précision.
- Il n'est pas plus sûre. Multiplier et diviser sont les mêmes que l'addition et la soustraction de l'exposant, et de modifier l'ordre peut facilement causer temporaires à dépasser la portée possible de l'exposant. (Pas exactement le même, car l'exposant ne pas souffrir de la perte de précision... mais la représentation est encore assez limité, et la réorganisation peut conduire à irreprésentable valeurs)
- Je pense que vous êtes absent de certains de calcul d'arrière-plan. Multplying et diviser 2 nombres introduire le même montant d'erreur. Alors que la soustraction / addition de 2 nombres peuvent introduire une plus grosse erreur surtout quand les 2 chiffres sont des ordres de grandeur différents, donc il est plus sûr de re-arrangin mul/fracture de sous/ajouter, car il introduire un changement mineur dans l'erreur finale.
- le risque est différent avec mul/div: la Réorganisation effectue un changement négligeable dans le résultat final, ou l'exposant déborde à un certain point (où il ne serait pas avant), et le résultat est différentes massivement (potentiellement +inf ou 0).
- Imposant une précision de gain de manière imprévisible, est très problématique.
InformationsquelleAutor sanjoyd
79

Fortran (conçu pour le calcul scientifique) est doté d'un pouvoir d'opérateur, et pour autant que je sais compilateurs Fortran est généralement de l'optimiser sensibilisation pour les puissances entières d'une manière similaire à ce que vous décrivez. C/C++ malheureusement, n'ont pas une puissance de l'opérateur, seulement une fonction de la bibliothèque pow(). Ce qui n'empêche pas les compilateurs intelligentes de traitement de pow spécialement et de l'informatique dans un moyen plus rapide pour des cas particuliers, mais il semble qu'ils le font moins souvent ...

Il y a quelques années j'ai essayé de le rendre plus pratique pour calculer les puissances entières d'une manière optimale, et est venu avec ce qui suit. C'est C++, C pas bien, et dépend encore le compilateur d'être un peu intelligent sur la façon d'optimiser/inline choses. De toute façon, j'espère que vous trouverez peut-être utile dans la pratique:
```
template<unsigned N> struct power_impl;

template<unsigned N> struct power_impl {
    template<typename T>
    static T calc(const T &x) {
        if (N%2 == 0)
            return power_impl<N/2>::calc(x*x);
        else if (N%3 == 0)
            return power_impl<N/3>::calc(x*x*x);
        return power_impl<N-1>::calc(x)*x;
    }
};

template<> struct power_impl<0> {
    template<typename T>
    static T calc(const T &) { return 1; }
};

template<unsigned N, typename T>
inline T power(const T &x) {
    return power_impl<N>::calc(x);
}
```
_{Précisions pour les curieux: ce n'est pas de trouver la solution optimale pour calculer les puissances, mais depuis trouver la solution optimale est un problème NP-complet de problème et c'est seulement la peine de le faire pour les petites puissances, de toute façon (par opposition à l'aide pow), il n'y a aucune raison de s'embêter avec les détails.}

Puis il suffit de l'utiliser comme power<6>(a).

Cela rend plus facile pour le type de pouvoirs (pas besoin de préciser 6 as avec les parenthèses), et vous permet d'avoir ce genre d'optimisation sans -ffast-math dans le cas où vous avez quelque chose de précision dépendante comme compensée sommation (un exemple où l'ordre des opérations est indispensable).

Vous pouvez probablement aussi oublier que c'est le C++ et l'utiliser dans le programme C (si on compile avec un compilateur C++).

J'espère que cela peut être utile.

EDIT:

C'est ce que je reçois de mon compilateur:

Pour a*a*a*a*a*a,
```
    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
```
Pour (a*a*a)*(a*a*a),
```
    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm0, %xmm0
```
Pour power<6>(a),
```
    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
```
- Trouver la puissance optimale de l'arbre peut être difficile, mais puisque c'est seulement intéressante pour les petites puissances, la réponse est évidente pour précalculer une fois (Knuth fournit un tableau jusqu'à 100) et de l'utilisation qui codé en dur de la table (c'est ce que gcc n'en interne pour powi).
- Sur les processeurs modernes, la vitesse est limitée par le temps de latence. Par exemple, le résultat d'une multiplication peut être disponible après cinq cycles. Dans cette situation, de trouver le moyen le plus rapide de créer de l'énergie pourrait être plus délicate.
- Vous pouvez également essayer de trouver la puissance de l'arbre qui donne la plus faible à la limite supérieure de la relative de l'erreur d'arrondi, ou le plus bas par rapport à la moyenne de l'erreur d'arrondi.
- Boost a aussi la prise en charge, par exemple, boost::math::pow<6>(n); je pense qu'il essaie même de réduire le nombre de multiplications par l'extraction de facteurs communs.
- Belle idée ! J'ai déjà fait ça pour factoriel precomputing.
- Notez que le dernier est équivalent à (a**2)**3
InformationsquelleAutor Szabolcs
59

GCC n'a réellement d'optimiser a*a*a*a*a*a à (a*a*a)*(a*a*a) lorsque a est un entier. J'ai essayé avec cette commande:
```
$ echo 'int f(int x) { return x*x*x*x*x*x; }' | gcc -o - -O2 -S -masm=intel -x c -
```
Il y a beaucoup de gcc drapeaux, mais rien de compliqué. Ils signifient: Lire depuis l'entrée standard stdin; utilisation O2 niveau d'optimisation; la sortie de l'assemblée la liste de langues au lieu d'une binaire; l'inscription doit utiliser Intel assemblée de la syntaxe du langage; l'entrée est en langage C (généralement de langue est déduite à partir de l'entrée de l'extension de fichier, mais il n'y a pas d'extension de fichier lors de la lecture de l'entrée standard stdin); et d'écrire sur la sortie standard stdout.

Voici la partie importante de la production. J'ai annoté avec quelques commentaires en indiquant ce qui se passe dans la langue de l'assembly:
```
; x is in edi to begin with.  eax will be used as a temporary register.
mov  eax, edi  ; temp = x
imul eax, edi  ; temp = x * temp
imul eax, edi  ; temp = x * temp
imul eax, eax  ; temp = temp * temp
```
Je suis en utilisant le système de GCC sous Linux Mint 16 Petra, un dérivé d'Ubuntu. Voici la version de gcc:
```
$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
```
Que d'autres affiches ont noté, cette option n'est pas possible en virgule flottante, parce que l'arithmétique à virgule flottante n'est pas associatif.
- C'est légal, pour l'entier de multiplication, car en complément à deux de débordement est un comportement indéterminé. Si il va y avoir un dépassement de capacité, il va arriver quelque part, indépendamment de la réorganisation des opérations. Ainsi, les expressions avec aucun débordement évaluer les mêmes, les expressions qui dépassent sont comportement indéfini, donc c'est ok pour le compilateur pour modifier le point de débordement se produit. gcc le fait avec unsigned int, trop.
InformationsquelleAutor picomancer
51

Parce qu'un 32 bits à virgule flottante nombre - comme 1.024 - n'est pas 1.024. Dans un ordinateur, 1.024 est un intervalle: de (1.024-e) (1.024+e), où "e" représente une erreur. Certaines personnes ne parviennent pas à réaliser que cela et croire aussi que * dans*un est synonyme de multiplication des nombres en précision arbitraire, sans qu'il y ait des erreurs liées à ces numéros. La raison pour laquelle certaines personnes ne parviennent pas à réaliser que cela est peut-être le calcul les calculs qu'ils ont exercé dans les écoles élémentaires: le fait de travailler uniquement avec l'idéal numéros sans erreurs attachées, et de croire que c'est OK pour ignorer simplement "e" lors de l'exécution de la multiplication. Ils ne voient pas le "e" est implicite dans "float a=1.2", "un*un*un" semblable à l'codes C.

Devrait majorité des programmeurs reconnaître (et être capable de s'exécuter sur) l'idée que C une expression un*un*un*un*un*un n'est pas réellement de travail idéal avec des chiffres, le compilateur GCC serait alors LIBRE d'optimiser "un*un*un*un*un*un" à dire "t=(a*a); t*t*t", ce qui nécessite un plus petit nombre de multiplications. Mais malheureusement, le compilateur GCC ne sais pas si le programmeur écrit le code, pense que "a" est un nombre avec ou sans erreur. Et donc, GCC ne feront que le code source ressemble - parce que c'est ce que GCC voit avec son "œil nu".

... une fois que vous savez quel genre de programmeur vous sont, vous pouvez utiliser le bouton "-ffast-math" commutateur de dire à GCC "Hey, GCC, je sais ce que je fais!". Cela permettra de GCC pour convertir un*un*un*un*un*un dans un autre morceau de texte, il semble différent d'un*un*un*un*un*un - mais encore calcule un nombre de l'intervalle d'erreur d'un*un*un*un*un*un. C'est OK, puisque vous savez déjà que vous travaillez avec des intervalles, pas idéal numéros.
- Les nombres à virgule flottante sont exactes. Ils sont tout simplement pas nécessairement exactement ce que vous attendiez. En outre, avec la technique de l'epsilon est elle-même une approximation de la façon d'aborder les choses dans la réalité, parce que la véritable erreur est relative à l'échelle de la mantisse, c'est à dire, vous êtes normalement jusqu'à environ 1 LSB, mais qui peut augmenter à chaque opération effectuée si vous n'êtes pas prudent afin de consulter numérique analyste avant de faire quelque chose de non négligeable avec virgule flottante. Utiliser une bibliothèque digne de ce nom si vous le pouvez.
- La norme exige que les calculs en virgule flottante de rendement le résultat plus fidèle possible de ce que serait le résultat si la source opérandes ont des valeurs exactes, mais cela ne signifie pas qu'ils ont réellement représenter valeurs exactes. Il est dans de nombreux cas, plus utile à l'égard de 0,1 f comme étant (1,677,722 +/- 0.5)/16,777,216, qui devrait être affiché avec le nombre de chiffres après la virgule implicite par cette incertitude, que de le considérer comme quantité exacte (1,677,722 +/- 0.5)/16,777,216 (qui devrait être affiché à 24 chiffres après la virgule).
- La norme IEEE-754 est assez clair sur le point de données en virgule flottante ne représentent des valeurs exactes; les clauses 3.2 - 3.4 sont les sections pertinentes. Vous pouvez, bien sûr, choisir de les interpréter autrement, tout comme vous vous pouvez choisir d'interpréter int x = 3 en ce sens que x est 3+/-0.5.
- Je suppose que cela dépend de ce que tu veux dire par "représenter". Dans la plupart des applications, les variables sont utilisées pour modéliser des choses concrètes. Dans une simulation physique, par exemple, ils peuvent représenter la X, Y et Z les composants d'objets divers, de positions et de vitesses, etc. Si je dis Distance = Math.Sqrt((x2-x1)*(x2-x1)+(y2-y1)*(y2-y1)+(z2-z1)*(z2-z1)), le but de Distance est de représenter la distance Euclidienne entre (x1,y1,z1) et (x2,y2,z2). Il est peu probable que le nombre précis stockées dans Distance sera la précision de la distance Euclidienne entre deux points, mais...
- Je suis entièrement d'accord, mais cela ne signifie pas que Distance n'est pas exactement égale à sa valeur numérique; il signifie que la valeur numérique n'est qu'une approximation certaine quantité physique modélisé.
- ...néanmoins l'usage classique serait de dire que Distance représente cette valeur, ou peut-être Distance représente quelque chose qui est à toutes fins pratiques "assez proche" de la valeur, plutôt que d'indiquer explicitement que Distance représente la précision en virgule flottante valeur numérique qui aurait des résultats de l'exécution de ladite séquence d'opérations. Du point de vue du matériel, effectuer les calculs de primitives (multiplie, ajoute, sqrt, etc.) les quantités doivent être évalués exactement, mais pour le consommateur, ils représentent des approximations.
- Mon point est que si le code effectue someSingle = 1.0/10.0, le résultat sera d'autant plus précise que le consommateur va attendre; si le code effectue someDouble = 1.0f/10.0f, le résultat va être désactivé par de nombreux ordres de grandeur de plus que les consommateurs qui ont connu le float quantités qui s'est passé pour représenter les valeurs précises qui serait de nature à attendre. Si un Double est jeté à l' Float et jamais jeté en arrière, l'utilisateur aura pas de surprises au niveau de la précision. Les Conversions de Float à Double, cependant, sont beaucoup plus susceptibles d'avoir des "surprises".
- Pour l'analyse numérique, votre cerveau va vous remercie si vous interpréter des nombres à virgule flottante non pas comme des intervalles, mais comme des valeurs exactes (qui se trouvent être pas exactement les valeurs que vous voulez). Par exemple, si x est quelque part ronde 4.5 avec une erreur inférieure à 0,1, et de vous calculer (x + 1) - x, l ' "intervalle" interprétation vous laisse avec un intervalle de 0,8 à 1,2, tandis que la "valeur exacte" interprétation vous dit le résultat sera 1 avec une erreur d'au plus 2^(-50) en double précision.
InformationsquelleAutor
32

Pas d'affiches ont mentionné la contraction des expressions flottantes encore (ISO standard C, 6.5p8 et 7.12.2). Si le FP_CONTRACT pragma est fixé à ON, le compilateur est autorisé à l'égard d'une expression telle que a*a*a*a*a*a comme une seule opération, comme si on l'évalue exactement avec un seul arrondissement. Par exemple, un compilateur peut le remplacer par un interne en fonction de la puissance qui est à la fois plus rapide et plus précis. Ceci est particulièrement intéressant que le comportement est en partie contrôlé par le programmeur directement dans le code source, tandis que les options du compilateur fourni par l'utilisateur final peut parfois être utilisé de manière incorrecte.

L'état par défaut de la FP_CONTRACT pragma la mise en œuvre est définie, de sorte qu'un compilateur est autorisé à faire de telles optimisations par défaut. Ainsi, portable code qui doit suivre strictement la norme IEEE 754 règles devraient explicitement définie à OFF.

Si un compilateur ne supporte pas cette pragma, il doit être prudent en évitant toute optimisation, dans le cas où le promoteur a choisi de la mettre à l' OFF.

GCC ne prend pas en charge cette pragma, mais avec les options par défaut, on suppose qu'il est ON; ainsi, pour les cibles avec un matériel FMA, si l'on veut empêcher la transformation a*b+c de fma(a,b,c), on a besoin de fournir une option comme -ffp-contract=off (à définir explicitement le pragma pour OFF) ou -std=c99 (à demander à GCC de se conformer à certaines C version standard, ici C99, donc suivez le paragraphe ci-dessus). Dans le passé, cette dernière option n'était pas la prévention de la transformation, ce qui signifie que GCC n'était pas conforme sur ce point: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
- Longue durée de vie populaire questions parfois montrer leur âge. Cette question a été posée et répondue en 2011, lors de la CCG pourrait être excusé de ne respectant pas exactement le récent standard C99. Bien sûr, maintenant, c'est 2014, de sorte GCC... ahem.
- Ne devriez-vous pas de réponse relativement récente à virgule flottante questions accepté de répondre au lieu de cela, si? toux stackoverflow.com/questions/23703408 la toux
- Je trouve ça... inquiétant que gcc ne pas mettre en œuvre le C99 à virgule flottante pragmas.
- pragmas sont, par définition, en option à mettre en œuvre.
- Mais si un pragma n'est pas mis en œuvre, sa valeur par défaut doit être le plus contraignant pour la mise en œuvre. Je suppose que c'est ce que David pensait. Avec GCC, c'est maintenant fixe pour FP_CONTRACT si l'on utilise un ISO C en mode: il n'est toujours pas mis en œuvre le pragma, mais dans un C ISO mode, il suppose que le pragma est éteint.
InformationsquelleAutor vinc17
28

Comme Lambdageek souligné flotteur de la multiplication n'est pas associatif et vous pouvez obtenir moins de précision, mais aussi lorsqu'obtenir une meilleure précision, vous pouvez faire valoir à l'encontre de l'optimisation, parce que vous voulez une déterministe de l'application. Par exemple, dans le jeu de simulation de client/serveur, où chaque client a pour simuler le même monde que vous voulez les calculs en virgule flottante d'être déterministe.
- À virgule flottante est toujours déterministe.
- seulement lorsque le compilateur ne pas réorganiser les choses, peut-être de façon différente selon la version de compilateur, de la machine cible, etc.
- Non, c'est toujours déterministe alors. Aucun caractère aléatoire est ajouté dans tout les sens du terme.
- Il semble assez clair Bjorn ici est d'utiliser 'déterministe' dans le sens du code donnant le même résultat sur les différentes plates-formes et différentes versions de compilateur, etc (variables externes qui peuvent être indépendants de la volonté du programmeur) - par opposition à l'absence de réelle numérique aléatoire au moment de l'exécution. Si vous êtes en soulignant que ce n'est pas un bon usage de la parole, je ne vais pas argumenter avec ça.
- À l'exception, même dans votre interprétation de ce qu'il dit, c'est toujours mal; c'est tout le point de la norme IEEE 754, pour fournir des caractéristiques identiques pour la plupart (si pas tous) des opérations sur l'ensemble des plateformes. Maintenant, il n'a fait aucune mention de plates-formes ou des versions de compilateur, ce qui serait une préoccupation valable, si vous voulez, toute opération sur chaque serveur distant/client à l'identique....mais ce n'est pas évident de sa déclaration. Un mot pourrait être "fiable similaire" ou quelque chose.
- vous perdez tout le temps, y compris votre propre, en arguant de la sémantique. Son sens est clair.
- L'ensemble de point de normes EST de la sémantique; son sens n'était décidément pas clair.
InformationsquelleAutor Bjorn
28

Je n'aurais pas prévu ce cas être optimisé à tous. Il ne peut pas être très souvent lorsqu'une expression contient des sous-expressions qui peuvent être regroupés pour supprimer toutes les activités. Je m'attends à ce compilateur écrivains à investir de leur temps dans des zones qui seraient plus susceptibles d'entraîner des améliorations notables, plutôt que de couvrir un rarement rencontré de cas de bord.

J'ai été surpris d'apprendre de l'autre des réponses que cette expression pourrait en effet être optimisé avec le bon compilateur commutateurs. Soit l'optimisation est trivial, ou c'est un cas limite de un beaucoup plus commun de l'optimisation, ou le compilateur écrivains ont été extrêmement complet.

Il n'y a rien de mal à donner des trucs pour le compilateur comme vous l'avez fait ici. C'est une étape normale et attendue de la part de la micro-optimisation des processus de réorganiser les états et les expressions pour voir quelles différences ils apportent.

Tandis que le compilateur peut être justifiée en considérant les deux expressions de livrer des résultats incohérents (sans les commutateurs appropriés), il n'y a pas besoin pour vous d'être lié par cette restriction. La différence sera incroyablement minuscule - de sorte que si la différence de vous, vous ne devriez pas utiliser la norme arithmétique à virgule flottante en premier lieu.
- Comme indiqué par un autre intervenant, c'est faux, au point d'être absurde; la différence peut être autant que la moitié de 10% du coût, et si elle est exécutée dans une boucle serrée, qui se traduira par de nombreuses instructions perdu pour l'obtenir ce qui pourrait être une quantité insignifiante de davantage de précision. Dire que vous ne devriez pas être en utilisant la norme FP lorsque vous faites un monte-carlo est un peu comme dire que vous devriez toujours utiliser un avion pour obtenir à travers le pays; il ignore la plupart des externalités. Enfin, ce n'est PAS rare, de l'optimisation des morts de l'analyse de code et de code de réduction/refactor est très commun.
InformationsquelleAutor Mark Ransom
28

Des fonctions de la bibliothèque comme "prisonnier de guerre" sont généralement soigneusement conçus pour donner le minimum d'erreur possible (dans le cas générique). Ceci est habituellement réalisé l'approximation des fonctions splines (d'après Pascal le commentaire le plus fréquent de la mise en œuvre semble être l'utilisation d' L'algorithme de Remez)

fondamentalement l'opération suivante:
```
pow(x,y);
```
a une erreur inhérente à environ la même ordre de grandeur que l'erreur dans une seule multiplication ou de la division.

Alors que l'opération suivante:
```
float a=someValue;
float b=a*a*a*a*a*a;
```
a une erreur inhérente qui est supérieure de plus de 5 fois l'erreur d'une seule multiplication ou de la division (parce que vous êtes la combinaison de 5 multiplications).

Le compilateur doit être vraiment attention à la nature de l'optimisation, il est en train de faire:
1. si l'optimisation de pow(a,6) à a*a*a*a*a*a il peut améliorer les performances, mais de réduire considérablement la précision des nombres à virgule flottante.
2. si l'optimisation de a*a*a*a*a*a à pow(a,6) il peut effectivement réduire la précision, parce que "a" est une valeur spéciale qui permet la multiplication sans erreur (une puissance de 2 ou certaines petit nombre entier)
3. si l'optimisation de pow(a,6) à (a*a*a)*(a*a*a) ou (a*a)*(a*a)*(a*a) il y a encore peut être une perte de précision par rapport à pow fonction.
En général, vous savez que pour arbitraire de valeurs à virgule flottante de "prisonnier de guerre" a une meilleure précision que n'importe quelle fonction vous pourrait éventuellement écrire, mais dans certains cas, plusieurs multiplications pouvez avoir plus de précision et de performance, c'est au développeur de choisir ce qui est le plus approprié, éventuellement commenter le code, de sorte que personne d'autre n'aurait "optimiser" le code.

La seule chose qui a du sens (opinion personnelle, et, apparemment, le choix du CCAG wichout tout particulier de l'optimisation ou le compilateur drapeau) pour optimiser devrait remplacer "pow(a,2)" avec une "*un". Ce serait la seule saine d'esprit, chose un fournisseur de compilateur doit faire.
- downvoters devraient se rendre compte que cette réponse est parfaitement bien. Je peux citer des dizaines de sources et de la documentation à l'appui de ma réponse et je suis probablement plus impliqués avec précision en virgule flottante de toute downvoter serait. Il est parfaitement raisonnable de StackOverflow ajouter les informations manquantes autres réponses ne couvre pas, donc, être poli et d'expliquer vos raisons.
- Il me semble que Stephen la réponse de Canon couvre ce que vous avez à dire. Vous semblez insister pour que libms sont mis en œuvre avec des splines: ils ont plus généralement l'utilisation de l'argument de la réduction (en fonction de la fonction en cours de réalisation), plus un seul polynôme dont les coefficients ont été obtenus par la plus ou moins sophistiqués variantes de l'algorithme de Remez. La douceur à des points de jonction n'est pas considéré comme un objectif qui doit être poursuivi pour libm fonctions (si ils finissent assez précis, ils sont automatiquement tout à fait lisse de toute façon quel que soit le nombre de pièces le domaine a été divisé en).
- La deuxième partie de votre réponse complètement à côté du point que les compilateurs sont censés produire du code qui implémente ce que le code source dit, période. Aussi, vous utilisez le mot “précision” quand vous voulez dire “précision”.
- Merci pour vos commentaires, j'ai légèrement corrigé la réponse, quelque chose de nouveau est toujours présent dans les 2 dernières lignes ^^
InformationsquelleAutor GameDeveloper
21

Il y a déjà un peu de bonnes réponses à cette question, mais par souci d'exhaustivité, je tenais à préciser que l'article applicable de la norme C est 5.1.2.2.3/15 (qui est le même que l'article 1.9/9 (C++11). Cette section précise que les opérateurs ne peuvent être regroupés que si elles sont vraiment associatif ou commutative.

InformationsquelleAutor Rastaban
12

gcc pouvez faire cette optimisation, même pour les nombres à virgule flottante. Par exemple,
```
double foo(double a) {
  return a*a*a*a*a*a;
}
```
devient
```
foo(double):
    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm1, %xmm0
    ret
```
avec -O -funsafe-math-optimizations. Cette réorganisation viole la norme IEEE-754, cependant, il exige que le drapeau.

Entiers signés, comme Peter Cordes souligné dans un commentaire, peut faire cette optimisation sans -funsafe-math-optimizations car il détient exactement quand il n'y a pas de débordement et si il y a débordement de vous obtenir un comportement indéfini. Ainsi, vous obtenez
```
foo(long):
    movq    %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rax, %rax
    ret
```
avec juste -O. Pour des entiers non signés, il est encore plus facile puisqu'ils travaillent mod des puissances de 2, et donc peuvent être réorganisés librement, même dans le visage de débordement.
- Godbolt lien avec lit double, int et unsigned. gcc et clang à la fois d'optimiser tous les trois la même façon (avec -ffast-math)
- Merci!
InformationsquelleAutor Charles

Vous devez vous connecter pour publier un commentaire.