Virgule flottante vs les calculs d'entiers sur le matériel moderne

Je suis en train de faire quelques critiques pour les performances en C++, et nous sommes actuellement en utilisant des calculs avec des entiers pour les problèmes qui sont de nature à virgule flottante parce que "son plus rapide". Cela provoque beaucoup de problèmes gênants et ajoute beaucoup de gênant code.

Maintenant, je me souviens avoir lu sur la façon dont les calculs en virgule flottante ont été si lent à environ vers l'386 jours, où je crois (IIRC) qu'il y avait une option de co-proccessor. Mais sûrement aujourd'hui avec d'autant plus complexes et les plus puissants Processeurs, il ne fait aucune différence dans la "vitesse" si faire de point flottant ou entier de calcul? Surtout étant donné que les temps de calcul minuscule par rapport à quelque chose comme causant un pipeline de décrochage ou chercher quelque chose dans la mémoire principale?

Je sais que la bonne réponse est la référence sur le matériel cible, ce serait un bon moyen de tester cela? J'ai écrit deux petits programmes C++ et comparer les temps d'exécution avec le "temps" sur Linux, mais le temps d'exécution est trop variable (n'a pas d'aide, je suis en cours d'exécution sur un serveur virtuel). Court de passer toute ma journée consécutive, des centaines de points de référence, faire des graphiques, etc. est-il quelque chose que je peux faire pour obtenir un raisonnable test de la vitesse relative? Toutes les idées ou les pensées? Suis-je complètement tort?

Les programmes que j'ai utilisé comme suit, ils ne sont pas identiques par tous les moyens:

#include <iostream>
#include <cmath>
#include <cstdlib>
#include <time.h>

int main( int argc, char** argv )
{
    int accum = 0;

    srand( time( NULL ) );

    for( unsigned int i = 0; i < 100000000; ++i )
    {
        accum += rand( ) % 365;
    }
    std::cout << accum << std::endl;

    return 0;
}

Programme 2:

#include <iostream>
#include <cmath>
#include <cstdlib>
#include <time.h>

int main( int argc, char** argv )
{

    float accum = 0;
    srand( time( NULL ) );

    for( unsigned int i = 0; i < 100000000; ++i )
    {
        accum += (float)( rand( ) % 365 );
    }
    std::cout << accum << std::endl;

    return 0;
}

Merci d'avance!

Edit: La plate-forme je me soucie est régulier x86 ou x86-64 fonctionnant sur Linux de bureau et les machines Windows.

Edit 2(collé à partir d'un commentaire ci-dessous): Nous avons une vaste base de code actuellement. Vraiment j'en suis venu à l'encontre de la généralisation que nous "ne doit pas utiliser float depuis entier de calcul est plus rapide" - et je suis à la recherche d'un moyen (si cela est encore vrai) pour réfuter cette prise en charge généralisée. Je me rends compte qu'il serait impossible de prédire le résultat pour nous, bref de faire tout le travail et le profilage par la suite.

De toute façon, merci à tous pour vos excellentes réponses et de l'aide. N'hésitez pas à ajouter d'autre chose :).

Ce que vous avez que votre test est trivial. Il y a aussi probablement très peu de différence dans l'assemblée, (addl remplacé par fadd, par exemple). La seule façon de vraiment obtenir une bonne mesure est d'obtenir une partie essentielle de votre véritable programme et le profil des différentes versions de l'. Malheureusement, cela peut être assez difficile sans utiliser des tonnes d'effort. Peut-être nous dire le matériel cible et de votre compilateur afin d'aider les gens, au moins, vous pré-existant de l'expérience, etc. À propos de votre entier d'utiliser, je suppose que vous pourriez faire une sorte de fixed_point classe de modèle afin de faciliter ce travail énormément.
Il y a encore beaucoup d'architectures qui n'a pas consacré de matériel de point flottant - tags expliquant les systèmes que vous aimez, vous aider à obtenir de meilleures réponses.
C'est un bon point. Pour le moment, nous avons une grande base de code, et je suis en train de faire l'argument selon lequel il serait essentiellement la même "vitesse" dans tous les cas. En espérant trouver des preuves pour étayer mon point de vue - pour justifier le travail de la commutation. De toute façon merci pour le modèle de classe d'idée, je vais essayer ça.
Norum bon point, je m'inquiète au sujet de la x86 ou x86-64 machines de bureau fonctionnant sous Linux et Windows
Je crois que le matériel dans mon HTC Hero (android) n'a pas de FPU, mais le matériel dans le Google NexusOne (android) n'. quelle est votre cible? desktop/server pc? les netbooks (possible bras+linux)? les téléphones?
Si vous voulez rapide FP sur x86, essayez de compiler avec l'optimisation de l'ESS et de génération de code. L'ESS (quelle que soit la version) peut faire au moins float ajouter, soustraire et multiplier en un seul cycle. Diviser, mod, et des fonctions supérieures sera toujours lent. Notez également que float obtient le boost de vitesse, mais généralement double ne l'est pas.
Point fixe entier se rapproche de la FP à l'aide de plusieurs opérations sur entiers de garder les résultats de déborder. C'est presque toujours plus lente que la simple utilisation de la extrêmement capable Unités modernes de bureau Cpu. par exemple, MAD, le point fixe, décodeur mp3, est plus lent que libmpg123, et même si c'est de la bonne qualité pour un point fixe décodeur, libmpg123 a encore moins de l'erreur d'arrondi. wezm.net/technical/2008/04/mp3-decoder-libraries-compared pour les tests de performances sur un PPC G5.
Voir ceci: nicolas.limare.net/pro/notes/2014/12/12_arit_speed

InformationsquelleAutor maxpenguin | 2010-03-31

c++floating-point x86 x86-64

31

Hélas, je ne peux que vous donner un "ça dépend" de réponse...

De mon expérience, il ya beaucoup, beaucoup de variables à la performance...surtout entre integer & calcul en virgule flottante. Il varie fortement d'processeur processeur (même au sein de la même famille comme x86) parce que les différents processeurs différents "pipeline" de long. Aussi, certaines opérations sont généralement très simples (comme ailleurs) et ont une accélération de la route par le processeur, et d'autres (comme la division) prendre beaucoup, beaucoup plus.

Le grand autre variable est là que les données résident. Si vous n'avez que quelques valeurs à ajouter, puis toutes les données peuvent résider dans le cache, où ils peuvent être rapidement envoyé sur le CPU. Une très, très lent opération de virgule flottante qui dispose déjà de données dans le cache sera plusieurs fois plus rapide que sur un nombre entier d'opération où un nombre entier doit être copiés de la mémoire système.

Je suppose que vous vous poser cette question parce que vous travaillez sur une critique pour les performances de l'application. Si vous développez pour l'architecture x86, et vous avez besoin de plus de performances, vous voudrez peut-être regarder dans l'aide de l'ESS extensions. Cela peut grandement accélérer virgule flottante simple précision arithmétique, la même opération peut être effectuée sur plusieurs données à la fois, plus il y a un autre* banque de registres de l'ESS opérations. (J'ai remarqué dans votre deuxième exemple que vous avez utilisé "flotter" au lieu de "double", me faisant penser que vous êtes en utilisant un seul de mathématiques de précision).

*Remarque: l'Utilisation de l'ancien instructions MMX serait de ralentir les programmes, parce que ces vieux instructions en fait utilisé les mêmes registres que la FPU, ce qui rend impossible à utiliser à la fois la FPU et MMX en même temps.
- Et sur certains processeurs FP mathématiques peuvent être plus rapides que les math entier. Le processeur Alpha avait un FP diviser instruction, mais pas un nombre entier, donc division entière a dû être fait dans le logiciel.
- Informations grand ici, merci.
- Va SSEx aussi d'accélérer la double précision arithmétique? Je suis désolé, je ne suis pas trop familier avec l'ESS
- SSE2 (base de référence pour x86-64) a emballé double-precision FP. Avec seulement deux 64 bits doubles par registre, le potentiel de gain est plus petit que float pour le code que vectorizes bien. Scalaire float et double utiliser des registres XMM sur x86-64, avec l'héritage x87 seulement utilisé pour long double. (Donc @ Dan: non, les registres MMX n'entrent pas en conflit avec la normale registres FPU, parce que la normale FPU sur x86-64 est l'ESS unité. MMX serait inutile, parce que si vous pouvez le faire entier SIMD, vous voulez de 16 octets xmm0..15 au lieu de 8 octets mm0..7, et les Processeurs modernes ont pire MMX que l'ESS débit.)
- Mais MMX et SSE*/AVX2 entier instructions font concurrence pour les mêmes unités d'exécution, donc, en utilisant les deux à la fois n'est presque jamais utile. Utilisez simplement le plus large XMM / YMM versions pour obtenir plus de travail. À l'aide de SIMD entier et FP dans le même temps, en concurrence pour les mêmes registres, x86-64, 16 d'entre eux. Mais le débit total des limites de dire que vous ne pouvez pas obtenir deux fois plus de travail fait en utilisant entier et FP unités d'exécution en parallèle.
InformationsquelleAutor Dan
47

Par exemple (plus petit nombre, sont plus rapides),

64-bit Intel Xeon X5550 @ 2.67 GHz, gcc 4.1.2 -O3
```
short add/sub: 1.005460 [0]
short mul/div: 3.926543 [0]
long add/sub: 0.000000 [0]
long mul/div: 7.378581 [0]
long long add/sub: 0.000000 [0]
long long mul/div: 7.378593 [0]
float add/sub: 0.993583 [0]
float mul/div: 1.821565 [0]
double add/sub: 0.993884 [0]
double mul/div: 1.988664 [0]
```
32-bit Dual Core AMD Opteron(tm) Processor 265 @ 1.81 GHz, gcc 3.4.6 -O3
```
short add/sub: 0.553863 [0]
short mul/div: 12.509163 [0]
long add/sub: 0.556912 [0]
long mul/div: 12.748019 [0]
long long add/sub: 5.298999 [0]
long long mul/div: 20.461186 [0]
float add/sub: 2.688253 [0]
float mul/div: 4.683886 [0]
double add/sub: 2.700834 [0]
double mul/div: 4.646755 [0]
```
Comme Dan a souligné, même une fois que vous normaliser la fréquence de l'horloge (qui peut être trompeur dans lui-même dans le pipeline dessins), résultats varient énormément basé sur l'architecture du PROCESSEUR (individuel ALU/FPU performance, ainsi que réelle nombre d'ALUs/Upc disponible par cœur dans superscalar dessins qui influe sur la façon dont de nombreux opérations indépendantes, peut exécuter en parallèle -- le dernier facteur n'est pas exercé par le code ci-dessous que toutes les opérations ci-dessous sont successivement dépendante.)

Pauvre homme FPU/ALU opération de référence:
```
#include <stdio.h>
#ifdef _WIN32
#include <sys/timeb.h>
#else
#include <sys/time.h>
#endif
#include <time.h>
#include <cstdlib>
double
mygettime(void) {
# ifdef _WIN32
struct _timeb tb;
_ftime(&tb);
return (double)tb.time + (0.001 * (double)tb.millitm);
# else
struct timeval tv;
if(gettimeofday(&tv, 0) < 0) {
perror("oops");
}
return (double)tv.tv_sec + (0.000001 * (double)tv.tv_usec);
# endif
}
template< typename Type >
void my_test(const char* name) {
Type v  = 0;
//Do not use constants or repeating values
// to avoid loop unroll optimizations.
//All values >0 to avoid division by 0
//Perform ten ops/iteration to reduce
// impact of ++i below on measurements
Type v0 = (Type)(rand() % 256)/16 + 1;
Type v1 = (Type)(rand() % 256)/16 + 1;
Type v2 = (Type)(rand() % 256)/16 + 1;
Type v3 = (Type)(rand() % 256)/16 + 1;
Type v4 = (Type)(rand() % 256)/16 + 1;
Type v5 = (Type)(rand() % 256)/16 + 1;
Type v6 = (Type)(rand() % 256)/16 + 1;
Type v7 = (Type)(rand() % 256)/16 + 1;
Type v8 = (Type)(rand() % 256)/16 + 1;
Type v9 = (Type)(rand() % 256)/16 + 1;
double t1 = mygettime();
for (size_t i = 0; i < 100000000; ++i) {
v += v0;
v -= v1;
v += v2;
v -= v3;
v += v4;
v -= v5;
v += v6;
v -= v7;
v += v8;
v -= v9;
}
//Pretend we make use of v so compiler doesn't optimize out
// the loop completely
printf("%s add/sub: %f [%d]\n", name, mygettime() - t1, (int)v&1);
t1 = mygettime();
for (size_t i = 0; i < 100000000; ++i) {
v /= v0;
v *= v1;
v /= v2;
v *= v3;
v /= v4;
v *= v5;
v /= v6;
v *= v7;
v /= v8;
v *= v9;
}
//Pretend we make use of v so compiler doesn't optimize out
// the loop completely
printf("%s mul/div: %f [%d]\n", name, mygettime() - t1, (int)v&1);
}
int main() {
my_test< short >("short");
my_test< long >("long");
my_test< long long >("long long");
my_test< float >("float");
my_test< double >("double");
return 0;
}
```
- pourquoi avez-vous mix mult et de la div? Ne devrait-elle pas être intéressant si mult est peut-être (ou attendre?) beaucoup plus rapide, puis la div?
- La Multiplication est beaucoup plus rapide que la division de deux entiers et à virgule flottante cas. Le rendement de la Division dépend aussi de la taille des nombres. J'ai l'habitude de supposer que la division est de ~15 fois plus lent.
- pastebin.com/Kx8WGUfg j'ai pris votre test et séparées de chaque opération pour son propre boucle et a ajouté volatile pour s'en assurer. Sur Win64, le FPU est pas utilisé et MSVC ne génère pas de code, de sorte qu'il compile en utilisant mulss et divss XMM instructions, qui sont 25x plus vite que la FPU en Win32. Machine de Test Core i5 520 M @ 2.40 GHz
- mais attention, fp ops v va rapidement atteindre 0 ou +/-inf très très rapidement, ce qui peut ou peut ne pas l'être (théoriquement) est traitée comme un cas spécial/fastpatheed par certains fpu implémentations.
- Dans mon expérience sur mon CPU 32-bit integer multiplication est de 1 cycle tops attendu que la division tend à se rapprocher de 8 cycles, donc c'est une très mauvaise idée de mélanger les deux. De même pour les chars, énorme différence dans la performance. Aussi certains de vos tests sont clairement optimisé entièrement (quand vous voyez 0 cycles...).
- La division est en effet plus lent, mais mes résultats (sur 22nm core I7) montrent division entière est 8 fois plus lent que l'entier de la multiplication, qui floating point de la division est seulement deux fois plus lent qu'à virgule flottante de multiplication et de division à virgule flottante est en quelque sorte deux fois plus vite que le nombre entier de la division, je suppose en raison de MMX.
- Cette "référence" n'a pas de parallélisme de données pour l'exécution des ordres, parce que chaque opération se fait avec le même accumulateur (v). Sur les récents d'Intel conçoit, fracture n'est pas canalisée à tous (divss/divps a 10-14 cycle de latence, et le même réciproque de débit). mulss cependant est de 5 cycle de latence, mais peut émettre une à chaque cycle. (Ou deux par cycle sur Haswell, depuis le port 0 et 1 port pour tous les deux ont un multiplicateur pour FMA).
- x87 FP mathématiques n'est pas lent. Le compilateur ne peut pas auto-vectorisation lors du ciblage, et sa pile de base de fonctionnement prend les instructions supplémentaires, mais fmul a les mêmes 5 cycle de latence et de 1 cycle recip débit qui mulss a. Les horaires pour fadd match addss, trop. Voir agner.org/optimize pour l'instruction des tables.
- J'ai démonté ce, et il semble que les compilateurs sont beaucoup mieux à l'optimisation de flotteur de type int. Lorsque vous faites une comparaison équitable, d'ajouter et de addss dans une boucle en langage d'assemblage, ajouter surpasse addss par 25 fois!
- Juste une remarque que @JamesDunne pastebin peut être compilé avec g++ -fpermissive -O3 -o benchmark-pc benchmark-pc.c où benchmark-pc.c est ce que j'ai sauvé le pastebin que
InformationsquelleAutor vladr
19

Il y a probablement une différence significative dans le vrai monde de vitesse entre le point fixe et de mathématiques à virgule flottante, mais l'théorique meilleur des cas, le débit de l'ALU vs FPU est complètement hors de propos. Au lieu de cela, le nombre d'entier et registres à virgule flottante (réel registres, de ne pas enregistrer des noms) sur votre architecture qui ne sont pas utilisées autrement par votre calcul (par exemple pour le contrôle en boucle), le nombre d'éléments de chaque type qui s'inscrivent dans une ligne de cache, les optimisations possibles en considérant les différentes sémantique pour l'entier vs calcul en virgule flottante, ces effets vont dominer. Les dépendances de données de votre algorithme joue ici un rôle important, de sorte qu'aucune comparaison générale prédit que l'écart de performances sur votre problème.

Par exemple, integer l'addition est commutative, donc si le compilateur voit une boucle comme vous avez utilisé pour un indice de référence, en supposant que les données aléatoires a été préparé à l'avance, de sorte qu'il ne serait pas masquer les résultats), il peut dérouler la boucle et de calculer les sommes partielles sans dépendances, puis les ajouter lorsque la boucle se termine. Mais avec virgule flottante, le compilateur doit faire les opérations dans le même ordre que vous avez demandé (vous avez de la séquence de points de il y, de sorte que le compilateur doit garantir le même résultat, ce qui les empêche de réorganisation) il y a donc une forte dépendance à l'égard de chaque addition sur le résultat de la précédente.

Vous êtes susceptible d'ajustement en plus des opérandes entiers dans le cache à la fois. Si le point fixe de la version pourrait surpasser la version float par un ordre de grandeur, même sur une machine où la FPU a théoriquement un débit plus élevé.
- +1 pour mettre en évidence comment naïf de référence peuvent rendement 0-le temps des boucles en raison de déroulé de la constante de type entier opérations. De plus, le compilateur ne peut pas complètement ignorer le boucle (entier ou FP) si le résultat n'est pas réellement utilisé.
- La conclusion est : on doit l'appeler une fonction ayant la boucle de la variable comme argument. Depuis, je pense, pas de compilateur pourrait être en mesure de voir que la fonction ne fait rien et que l'appel peut être ignoré. Puisqu'il y a un appel de la surcharge, seules les différences de temps == ( float temps entier de temps ) sera importante.
- raison pour downvote?
- De nombreux compilateurs n'éliminer les appels à vide de fonctions, comme un effet secondaire de l'in-lining. Vous devez faire un effort pour l'en empêcher.
- L'OP sonnait comme s'il parlait à l'aide d'entiers pour des choses où FP serait un ajustement plus naturel, alors qu'il faudrait plus de code entier pour obtenir le même résultat que la FP code. Dans ce cas, il suffit d'utiliser la PF. Par exemple, sur le matériel avec une FPU (par exemple une unité centrale de bureau), point fixe, entier MP3 décodeurs sont plus lents (et un peu plus les erreurs d'arrondi) de virgule flottante décodeurs. Point fixe, implémentations de codecs principalement existent pour s'exécuter sur des stripped-down Processeurs ARM sans FP matériel, ne font que ralentir émulé FP.
InformationsquelleAutor Ben Voigt
18

Plus est beaucoup plus rapide que rand, de sorte que votre programme est (surtout) inutile.

Vous avez besoin pour identifier les points sensibles de la performance et ne cessent de modifier votre programme. Il semble que vous avez des problèmes avec votre environnement de développement qui devront être résolus en premier. Il est impossible d'exécuter votre programme sur votre PC pour un petit problème réglé?

Généralement, de tenter FP emplois avec l'arithmétique des nombres entiers est une recette pour le ralentir.
- Ouais, ainsi que la conversion à partir d'un rand nombre entier à un flotteur en virgule flottante, la version. Toutes les idées sur la meilleure façon de tester ce?
- Si vous essayez de profil de vitesse, regardez POSIX est timespec_t ou quelque chose de similaire. Record de l'heure au début et à la fin de la boucle et de la différence. Déplacez ensuite le rand la génération de données en dehors de la boucle. Assurez-vous que votre algorithme obtient toutes ses données à partir de baies et met toutes ses données dans des tableaux. Que devient votre algorithme en lui-même, et obtient de l'installation, malloc, résultat de l'impression, de tout, mais le changement de tâche et les interruptions de votre profilage de la boucle.
- la question est de savoir ce que vous testez. Artem a supposé que vous faites des graphiques, Carl considérer si vous êtes sur une plate-forme intégrée sans FP, je suppose que vous êtes le codage de la science pour un serveur. Vous ne pouvez pas généraliser ou "écrire" points de référence. Les repères sont échantillonnées à partir du travail réel de votre programme. Une chose que je peux vous dire, c'est qu'il ne restera pas "essentiellement la même vitesse" si vous touchez à la performance-élément essentiel dans votre programme, quelle qu'elle soit.
- bon point, et la bonne réponse. Nous avons une vaste base de code actuellement. Vraiment j'en suis venu à l'encontre de la généralisation que nous "ne doit pas utiliser float depuis entier de calcul est plus rapide" - et je suis à la recherche d'un moyen (si cela est encore vrai) pour réfuter cette prise en charge généralisée. Je me rends compte qu'il serait impossible de prédire le résultat pour nous, bref de faire tout le travail et le profilage par la suite. De toute façon, merci pour votre aide.
InformationsquelleAutor Potatoswatter
13

TIL Cela varie un peu (beaucoup). Voici quelques résultats à l'aide du compilateur gnu (btw j'ai aussi vérifié par la compilation sur les machines, gnu g++ 5.4 de xenial est un enfer de beaucoup plus rapide que 4.6.3 de linaro précis)

Intel core i7 4700MQ xenial
```
short add: 0.822491
short sub: 0.832757
short mul: 1.007533
short div: 3.459642
long add: 0.824088
long sub: 0.867495
long mul: 1.017164
long div: 5.662498
long long add: 0.873705
long long sub: 0.873177
long long mul: 1.019648
long long div: 5.657374
float add: 1.137084
float sub: 1.140690
float mul: 1.410767
float div: 2.093982
double add: 1.139156
double sub: 1.146221
double mul: 1.405541
double div: 2.093173
```
Intel i3 2370M a des résultats similaires
```
short add: 1.369983
short sub: 1.235122
short mul: 1.345993
short div: 4.198790
long add: 1.224552
long sub: 1.223314
long mul: 1.346309
long div: 7.275912
long long add: 1.235526
long long sub: 1.223865
long long mul: 1.346409
long long div: 7.271491
float add: 1.507352
float sub: 1.506573
float mul: 2.006751
float div: 2.762262
double add: 1.507561
double sub: 1.506817
double mul: 1.843164
double div: 2.877484
```
Intel(R) Celeron(R) 2955U (Acer C720 Chromebook de course xenial)
```
short add: 1.999639
short sub: 1.919501
short mul: 2.292759
short div: 7.801453
long add: 1.987842
long sub: 1.933746
long mul: 2.292715
long div: 12.797286
long long add: 1.920429
long long sub: 1.987339
long long mul: 2.292952
long long div: 12.795385
float add: 2.580141
float sub: 2.579344
float mul: 3.152459
float div: 4.716983
double add: 2.579279
double sub: 2.579290
double mul: 3.152649
double div: 4.691226
```
DigitalOcean 1 GO de Gouttelettes Intel(R) Xeon(R) CPU E5-2630L v2 (exécutant fidèle)
```
short add: 1.094323
short sub: 1.095886
short mul: 1.356369
short div: 4.256722
long add: 1.111328
long sub: 1.079420
long mul: 1.356105
long div: 7.422517
long long add: 1.057854
long long sub: 1.099414
long long mul: 1.368913
long long div: 7.424180
float add: 1.516550
float sub: 1.544005
float mul: 1.879592
float div: 2.798318
double add: 1.534624
double sub: 1.533405
double mul: 1.866442
double div: 2.777649
```
AMD Opteron(tm) Processor 4122 (précis)
```
short add: 3.396932
short sub: 3.530665
short mul: 3.524118
short div: 15.226630
long add: 3.522978
long sub: 3.439746
long mul: 5.051004
long div: 15.125845
long long add: 4.008773
long long sub: 4.138124
long long mul: 5.090263
long long div: 14.769520
float add: 6.357209
float sub: 6.393084
float mul: 6.303037
float div: 17.541792
double add: 6.415921
double sub: 6.342832
double mul: 6.321899
double div: 15.362536
```
Il utilise le code de http://pastebin.com/Kx8WGUfg comme benchmark-pc.c
```
g++ -fpermissive -O3 -o benchmark-pc benchmark-pc.c
```
J'ai couru plusieurs fois, mais cela semble être le cas général, les numéros sont les mêmes.

Une exception notable semble être en ALU mul vs FPU mul. L'Addition et la soustraction semblent carrément différent.

Voici ci-dessus sous forme graphique (cliquer pour agrandir, la baisse est plus rapide et préférable):

Mise à jour pour accueillir @Peter Cordes

https://gist.github.com/Lewiscowles1986/90191c59c9aedf3d08bf0b129065cccc

i7 4700MQ Linux Ubuntu Xenial 64 bits (tous les correctifs pour 2018-03-13 appliquée)
```
    short add: 0.773049
short sub: 0.789793
short mul: 0.960152
short div: 3.273668
int add: 0.837695
int sub: 0.804066
int mul: 0.960840
int div: 3.281113
long add: 0.829946
long sub: 0.829168
long mul: 0.960717
long div: 5.363420
long long add: 0.828654
long long sub: 0.805897
long long mul: 0.964164
long long div: 5.359342
float add: 1.081649
float sub: 1.080351
float mul: 1.323401
float div: 1.984582
double add: 1.081079
double sub: 1.082572
double mul: 1.323857
double div: 1.968488
```
AMD Opteron(tm) Processor 4122 (précis, DreamHost d'hébergement mutualisé)
```
    short add: 1.235603
short sub: 1.235017
short mul: 1.280661
short div: 5.535520
int add: 1.233110
int sub: 1.232561
int mul: 1.280593
int div: 5.350998
long add: 1.281022
long sub: 1.251045
long mul: 1.834241
long div: 5.350325
long long add: 1.279738
long long sub: 1.249189
long long mul: 1.841852
long long div: 5.351960
float add: 2.307852
float sub: 2.305122
float mul: 2.298346
float div: 4.833562
double add: 2.305454
double sub: 2.307195
double mul: 2.302797
double div: 5.485736
```
Intel Xeon E5-2630L v2 @ 2.4 GHz (Trusty 64 bits, DigitalOcean VPS)
```
    short add: 1.040745
short sub: 0.998255
short mul: 1.240751
short div: 3.900671
int add: 1.054430
int sub: 1.000328
int mul: 1.250496
int div: 3.904415
long add: 0.995786
long sub: 1.021743
long mul: 1.335557
long div: 7.693886
long long add: 1.139643
long long sub: 1.103039
long long mul: 1.409939
long long div: 7.652080
float add: 1.572640
float sub: 1.532714
float mul: 1.864489
float div: 2.825330
double add: 1.535827
double sub: 1.535055
double mul: 1.881584
double div: 2.777245
```
- gcc5 peut-être auto-vectorizes quelque chose qui gcc4.6 n'a pas? Est benchmark-pc la mesure de certains combinaison de débit et de latence? Sur votre Haswell (core i7 4700MQ), entier multiplier est de 1 pour l'horloge de débit, de 3 cycle de latence, mais entier add/sub est de 4% de l'horloge de débit, 1 cycle de latence (agner.org/optimize). Donc, vraisemblablement, il y a beaucoup de la boucle de la surcharge de la dilution de ces chiffres pour l'add et mul à venir si près (long ajouter: 0.824088 vs. long mul: 1.017164). (gcc par défaut est de ne pas dérouler les boucles, sauf pour le déroulage de très faibles nombres d'iterations).
- Et BTW, pourquoi ne pas tester int, seulement short et long? Sur Linux x86-64, short est de 16 bits (et donc partielle-registre des ralentissements dans certains cas), tandis que long et long long sont à la fois 64 bits types. (C'est peut-être conçu pour Windows où x86-64 utilise toujours 32 bits long? Ou peut-être il est conçu pour le mode 32 bits.) Sur Linux, le x32 ABI a 32 bits long en mode 64 bits, donc si vous avez les librairies installées, utilisez gcc -mx32 le compilateur pour ILP32. Ou simplement l'utiliser -m32 et de regarder la long numéros.
- Et vous devriez vraiment vérifier si votre compilateur auto-vectorisé quoi que ce soit. par exemple, à l'aide de addps sur les registres xmm au lieu de addss, faire 4 FP ajoute en parallèle dans une instruction aussi rapide que scalaire addss. (Utiliser -march=native pour permettre l'utilisation quels que soient les ensembles d'instructions de votre CPU prend en charge, non seulement le SSE2 de référence pour x86-64).
- merci de laisser les graphiques montrant les 15 le côté, comme il est illustratif de la performance.
- Je vais essayer de regarder demain, je vous remercie pour votre diligence.
- J'ai mis à l'échelle de l'ensemble des cartes d'une même hauteur, car la question concerne virgule flottante vs entier, pas des processeurs différents vs les uns des autres. La chose principale source de préoccupation dans les différents processeurs est la différence relative, pas absolue de la performance. Votre appel si.
- J'ai toujours l'impression que je comprenais de moins en regardant les relativement échelle graphique, mais peut-être il ya une place pour les deux si il est étiqueté? I <3 votre contribution.
- J'ai regardé la source de référence. Il ne v *= foo; ou v += foo dans un déroulé (par 4) en boucle où foo est une variable d'exécution (mais invariant de boucle). C'est donc la mesure de la latence de ne pas le débit, mais bien de la différence entre add et mul est caché par l'aide de volatile v de sorte que le compilateur doit stocker/recharger à l'intérieur de la boucle; au lieu de voir 3x le temps de latence pour cette chaîne de dépendances, vous ne voyez 5+1 vs 5+3. À l'aide de volatile Type sink = v; à l'intérieur de la boucle de la force pour stocker tous les résultats séparément, mais lui permettre de garder v dans un registre. Vous pouvez également utiliser inline l'asm à l'évasion...
- fantaisie de bifurquer l'essentiel de l'information et de liaison, donc j'ai la moitié d'une idée de quoi vous parlez (c'est un autre code, juste compilé, maintenant modifié avec les résultats, vous êtes voler des avions au dessus de ma tête)
InformationsquelleAutor MrMesees
7

Deux points à prendre en considération -

Matériel moderne peuvent se chevaucher instructions, les exécuter en parallèle et de les réorganiser afin d'utiliser au mieux le matériel. Et aussi, toute virgule flottante programme est susceptible d'avoir d'importantes entier travaillent trop, même si c'est seulement pour le calcul des indices dans les tableaux, compteur de boucle, etc. donc, même si vous avez une lente instruction à virgule flottante, il peut bien être en cours d'exécution sur une autre peu de matériel coïncidé avec certains de l'entier de travail. Mon point étant que, même si les instructions en virgule flottante sont lents qu'un entier, l'ensemble de votre programme peut s'exécuter plus rapidement, car il peut faire usage de plus de matériel.

Comme toujours, la seule façon d'en être sûr est de profil de votre programme.

Deuxième point est que la plupart des Processeurs, de nos jours, instructions SIMD pour virgule flottante qui peut fonctionner sur plusieurs valeurs à virgule flottante tous en même temps. Par exemple, vous pouvez charger 4 flotteurs en un seul ESS s'inscrire et le faire 4 multiplications sur toutes en même temps. Si vous pouvez réécrire certaines parties de votre code pour utiliser les instructions SSE ensuite, il semble probable qu'il sera plus rapide que pour un entier version. Visual c++ fournit un compilateur fonctions intrinsèques pour ce faire, voir http://msdn.microsoft.com/en-us/library/x5c07e2a(v=VS.80).aspx pour obtenir certaines informations.
- Il convient de noter que sur Win64, le FPU instructions ne sont pas générés par le MSVC compilateur plus. À virgule flottante est toujours en utilisant des instructions SIMD là. Cela rend pour une grande vitesse de divergence entre Win32 et Win64 concernant les flops.
- Entier SIMD est tout aussi viable qu'à virgule flottante SIMD
InformationsquelleAutor jcoder
4

Sauf si vous écrivez du code qui sera appelé millions de fois par seconde (comme, par exemple, tracer une ligne à l'écran dans une application graphique), entier contre l'arithmétique à virgule flottante est rarement le goulot d'étranglement.

La première étape pour les questions d'efficacité est le profil de votre code pour voir où le run-time est vraiment passé. La commande linux pour ce qui est gprof.

Edit:

Mais je suppose que vous pouvez toujours mettre en oeuvre l'algorithme de dessin de la ligne à l'aide de nombres entiers et les nombres à virgule flottante, appeler un grand nombre de fois et voir si cela fait une différence:

http://en.wikipedia.org/wiki/Bresenham's_algorithm
- Les applications scientifiques utilisent la PF. Le seul avantage de la PF est que la précision de l'échelle-invariant. C'est comme la notation scientifique. Si vous connaissez l'ampleur des chiffres déjà (par exemple, que la longueur de la ligne est un nombre de pixels), FP est écarté. Mais avant de vous faire de dessin de la ligne, ce n'est pas vrai.
InformationsquelleAutor Artem Sokolov
4

Aujourd'hui, les opérations sur entiers sont généralement un peu plus vite que d'opérations en virgule flottante. Donc si vous pouvez faire un calcul avec les mêmes opérations en entiers et à virgule flottante, utilisez entier. CEPENDANT vous dites: "Ce qui provoque tout un tas de problèmes gênants et ajoute beaucoup de gênant code". Cela sonne comme vous avez besoin de plus d'opérations parce que vous utiliser l'arithmétique des nombres entiers au lieu de la virgule flottante. Dans ce cas, la virgule flottante courir plus vite parce que
- dès que vous avez besoin de plus entier des opérations, vous avez probablement besoin de beaucoup plus, de sorte que le léger avantage de vitesse est plus consommés par les activités supplémentaires
- à virgule flottante code est plus simple, ce qui signifie qu'il est plus rapide d'écrire le code, ce qui signifie que si c'est la vitesse critique, vous pouvez passer plus de temps à l'optimisation du code.
- Il y a beaucoup de spéculation sauvage ici, pas de comptabilité pour l'une des effets secondaires présents dans le matériel, qui, souvent, dominent les temps de calcul. Pas un mauvais point de départ, mais elle doit être vérifiée à chaque application particulière via le profilage, ne l'enseigne pas comme parole d'évangile.
InformationsquelleAutor gnasher729
3

J'ai couru un test qui vient d'ajouter 1 au nombre au lieu de rand(). Résultats (sur un système x86-64) étaient:
- court: 4.260 s
- int: 4.020 s
- long long: 3.350 s
- float: 7.330 s
- double: 7.210 s
- Source, options de compilation, et le calendrier de la méthode? Je suis un peu surpris par les résultats.
- Même boucle que l'OP avec "rand( ) % 365" est remplacé par "1". Pas d'optimisation. Du temps à l'utilisateur de "temps" de la commande.
- "L'optimisation" est la clé. Vous n'avez jamais de profil avec l'optimisation éteint, toujours de profil en mode "release".
- Dans ce cas, cependant, l'optimisation des forces de l'op à se produire, et est fait délibérément -- la boucle est là pour dilater le temps d'une taille raisonnable de la mesure. À l'aide de la constante de 1 supprime le coût de rand(). Suffisamment intelligent compilateur optimisant serait de voir 1 ajouté 100,000,000 fois avec aucun moyen de sortir de la boucle et ajoutez simplement 100000000 en une seule op. Ce genre de truc autour de l'objectif, n'est-ce pas?
- faire de la variable volatile. Même une puce optimisation du compilateur devrait honorer les multiples ops ensuite.
InformationsquelleAutor dan04
3

Virgule flottante, la version sera beaucoup plus lent, si il n'y a aucun reste de l'opération. Depuis que tous les adds sont séquentiel, le cpu ne sera pas capable de paralléliser la sommation. Le temps de latence sera critique. FPU ajouter de la latence est généralement de 3 cycles, tout entier ajouter est de 1 cycle. Cependant, le diviseur pour le reste de l'opérateur sera probablement de la partie critique, car il n'est pas entièrement canalisée moderne de la cpu. donc, en supposant que la fracture est/reste instruction consomment la majeure partie du temps, l'écart en raison d'ajouter de la latence sera petit.

InformationsquelleAutor Goran D
-1

En fonction de ce oh-so-fiable "quelque chose que j'ai entendu", de retour dans les vieux jours, entier de calcul ont été d'environ 20 à 50 fois plus rapide que la virgule flottante, et ces jours-ci, c'est moins de deux fois plus rapide.
- Veuillez envisager de chercher à ce nouveau offrant plus d'avis (surtout étant donné que l'opinion semble voler dans le visage des faits recueillis)
- Bien que cette réponse n'est pas très utile, je dirais qu'il est compatible avec les tests que vous avez faits. Et l'historique de trivia est probablement trop belle.
InformationsquelleAutor James Curran

Vous devez vous connecter pour publier un commentaire.

Mise à jour pour accueillir @Peter Cordes