performance des 'cast'

Version imprimable

04/12/2006, 13h54
me_myself

performance des 'cast'

Bonjour,

J'ai de nombreux calculs où je dois soit faire un calcul de doubles casté dans un integer, ou soit inversement faire une opération comme une division d'integers vers un double.

Rien de bien compliqué certes, mais multiplié par des millions d'opérations, cela peut y avoir des variations considérables de temps de calcul.

Quels sont toutes les différentes options et leur 'coût' en temps de calcul?

Merci d'avance

bv
04/12/2006, 15h20
loufoque

Un cast créé une nouvelle variable, éventuellement temporaire.
04/12/2006, 15h42
me_myself

OK, mais si je ne fais pas un cast explicite, je laisse le compilateur faire, il me donne un warning (possible data loss) mais évidemment ça marche.

Mais comment faire proprement et le plus efficacement?

Merci

bv
04/12/2006, 16h02
Médinoc

L'affectation d'un nombre à virgule flottante dans un entier, avec ou sans cast explicite, entrainera toujours la conversion à un moment ou à un autre.

"On" m'a dit qu'une conversion entre flottant et entier était plus couteuse qu'une simple opération de calcul flottant, et qu'il fallait réduire les conversions au minimum...
04/12/2006, 18h51
Jan Rendek

Citation:

Envoyé par me_myself

OK, mais si je ne fais pas un cast explicite, je laisse le compilateur faire, il me donne un warning (possible data loss) mais évidemment ça marche.

Mais comment faire proprement et le plus efficacement?

Merci
bv

Implicite ou explicite, la transformation d'un entier en double ou l'inverse sera rigoureusement la même. Le cast explicite indique au compilo que tu connais les conséquences (nombre tronqué, etc...), ce qui rend le warning inutile.

La seule solution c'est de revoir l'algorithme pour limiter les transtypages au strict minimum.

Le plus rapide double-to-int du monde :-)

Si tu dois vraiment faire du cast de double vers int en grande quantite, je te recommande cette petite merveille:
(Pour ceux qui voient vraiment pas comment ca peut marcher, au point de croire que ca marche pas, je ne saurais trop recommander de faire un essai)
Code:

1 2 3 4 5 6 7 8 9 10 11 #define D2I_CONVERSION_FACTOR (1.5 * 4503599627370496.0) inline int d2i(double val) { union { int i[2]; double d; } dlong; dlong.d = val + D2I_CONVERSION_FACTOR; return dlong.i[0]; }
C'est plus rapide qu'un cast standard par un facteur de 8, et meme plus rapide qu'un cast en assembleur du genre:
Code:

1 2 3 4 5 6 7 double d; int val; __asm { fld qword ptr[d] fistp dword ptr[val] }
J'ai verifie moi-meme.

les limitations du truc:
-Tres difficile a comprendre (je peux filer une explication si tu cale et que ca t'interesse).
-Les ints doivent etre en 32 bits
-Les doubles doivent etre en representation standard (1/11/52)
-Marche tel quel uniquement sur une machine big-endian
-Pas du tout du tout de verification ou de traitement d'erreurs.
Les trois premieres peuvent etre contournees, la derniere non :-)

Il est possible de faire la fonction inverse ;-)

Ça joue sur la représentation standard.
Je suppose que ton D2I_CONVERSION_FACTOR sert à forcer l'exposant à une valeur connue...

Je me rappelle avoir écrit une macro qui, au lieu de passer par une union, faisait du transtypage de pointeur pour pouvoir accéder aux données du double en tant qu'entier...
Code:

1 2 3 4 5 6 7 8 9 10 #define DBL2LONG_0(dbl) (reinterpret_cast< long *>(&(dbl))[0]) #define DBL2LONG_1(dbl) (reinterpret_cast< long *>(&(dbl))[1]) #ifdef BIG_ENDIAN //Ou tout autre #define dépendant de l'endianness #define DBL2LONG_H(dbl) DBL2LONG_0(dbl) #define DBL2LONG_L(dbl) DBL2LONG_1(dbl) #else #define DBL2LONG_H(dbl) DBL2LONG_1(dbl) #define DBL2LONG_L(dbl) DBL2LONG_0(dbl) #endif
De là, si le double est en représentation standard, on peut accéder à sa mantisse et à son exposant...

05/12/2006, 00h01
bricerive

Bien vu

Tu as raison, bravo.
Un peu plus de details:
4503599627370496.0 = 2^52
donc D2I_CONVERSION_FACTOR est egal a 2^52 + 2^51
Comme tu l'as compris, en ajoutant ca a un double (pas trop grand en valeur absolue), on force la mantisse a etre pile poil arrondie a l'int le plus proche par le FPU.
Ensuite il suffit d'y acceder directement avec l'union (ou avec le double cast comme dans ta macro).
J'adore :-)

Question subsidiaire: pourquoi "2^52+2^51" et pas simplement "2^52"
05/12/2006, 07h11
Médinoc

Pour forcer le second bit à 1, car le premier est implicite ?
05/12/2006, 10h00
JolyLoic

3 pièce(s) jointe(s)

Parmi les inconvénients de cette méthode, j'ajouterai :
- Aucune garantie que ça fasse quoi que ce soit. Ecrire dans un membre d'une union et lire dans un autre est un comportement indéfini. Il se peut que ça marche sur une certaine machine, avec une certaine version d'un compilateur, avec certaines options de compilation, pendant certaines phases de la lune, mais rien n'est moins sur.

Là où je suis surpris, c'est quand tu annonces un rapport 8... A la base, ce n'est qu'une manipulation basique de la représentation des flottants, et on pourrait imaginer que c'est justement ce genre de manipulation que fait la conversion de base. Pris d'un doute, j'ai donc fait des tests (compilateur visualC++2005, options de compilaton par défaut en release)...

Déjà, le résultat n'est pas le même qu'un simple cast en int. Un cast tronque, ta méthode fait autre chose.

Pour des petits nombres positifs, en enlevant 0.5 à la valeur passée, on se ramène dans le cas où les valeurs produites sont identiques. Il faut ajouter 0.5 pour une valeur petite négative. Pour des grand nombres, proches des entiers de taille maximale, des erreurs subsistent, que je n'ai pas voulu corriger... L'écart entre les deux méthodes est au plus d'une unité.

Avec ce test, ta méthode est plus lente de 15% à 25% que la méthode de base. Sans ce test (en se limitant à des nombres positifs), elle est plus rapide de 10% à 20%. Les variations dépendent de si je fais beaucoup d'itérations sur des petits jeus de données, ou moins d'itération sur des plus grand (moins bonne utilisation de la mémoire, qui vient masquer les différences, ce qui tend à dire que dans une utilisation classique, la différence sera probablment elle aussi masquée par d'autres aspects)

On est quoi qu'il en soit loin du *8 sur cette architecture.

Voici mon code de test, si certains veulent s'amuser avec ou le critiquer :
Pièce jointe 7364

Pièce jointe 7365

Pièce jointe 7366
05/12/2006, 10h26
Jan Rendek

Le code le plus tordu pour amélioré la vitesse du transtypage n'est à utiliser qu'APRES avoir revu et corrigé l'algorithme initial.
Le gain en temps de ce type de code 'funky' est souvent marginal sur l'algo revu et corrigé.
05/12/2006, 15h56
thewho

Bonjour,

@ bricerive:

Je ne vais pas critiquer ton code, mais tes affirmations:

J'ai testé les performances, car tes affirmations me paraissaient un peu trop optimistes, pour ne pas dire fausses (sans perdre de vue que les performances sont directement liées à la qualité de l'implémentation du compilateur, un peu moins dépendant pour la partie assembleur, en principe)

(tests faits sur un Athlon XP 2600, Windows, compilateur mingw, pas d'optimisation, résultats très similaires en activant les optimisations)

- Ca va plus vite que le cast classique d'un facteur 2.5

- MAIS en utilisant l'assembleur (celui que tu as donné), le rapport de vitesse s'inverse !

Je vais quand même critiquer un peu ton code : pourquoi cette définition

Code:

#define D2I_CONVERSION_FACTOR (1.5 * 4503599627370496.0)

au lieu de

Code:

#define D2I_CONVERSION_FACTOR 6755399441055744.0

Après tout, c'est un astuce pour gagner en vitesse, pourquoi faire une multiplication dans le calcul, alors qu'on peut la faire en avance ?
05/12/2006, 16h39
JolyLoic

Citation:

Envoyé par thewho

Je vais quand même critiquer un peu ton code : pourquoi cette définition

Code:

#define D2I_CONVERSION_FACTOR (1.5 * 4503599627370496.0)

au lieu de

Code:

#define D2I_CONVERSION_FACTOR 6755399441055744.0

Après tout, c'est un astuce pour gagner en vitesse, pourquoi faire une multiplication dans le calcul, alors qu'on peut la faire en avance ?

Parce que c'est plus clair ? (bon, là, ya quand même une constante pas hyper lisible, mais bon...). Je ne connais pas de compilateur qui, en mode optimisé, ne génèrerait pas le même code avec les deux écritures.
05/12/2006, 16h43
JolyLoic

Citation:

Envoyé par thewho

(tests faits sur un Athlon XP 2600, Windows, compilateur mingw, pas d'optimisation, résultats très similaires en activant les optimisations)

- Ca va plus vite que le cast classique d'un facteur 2.5

Ca m'étonne qu'il y ait peu de rapports entre les versions de base et optimisées. C'est quand même une fonction tellement courte qu'on pourrait s'attendre à ce que l'inlining ait de l'effet. Pour le rapport de 2.5, il est loin de mes mesures. Serait-il possible de poster ton code, car comme l'a dit je ne sais plus qui, il ne faut jamais croire un benchmark qu'on n'a pas trafiqué soi-même...
05/12/2006, 17h27
thewho

Bonjour,

Citation:

Envoyé par JolyLoic

Parce que c'est plus clair ? (bon, là, ya quand même une constante pas hyper lisible, mais bon...). Je ne connais pas de compilateur qui, en mode optimisé, ne génèrerait pas le même code avec les deux écritures.

C'est pour aller vite, la clarté est accessoire, et peut être établie avec une petite ligne de commentaire.
Mais il est vrai que normalement le pré-compilateur doit s'occuper de ça, mais ce n'est pas garanti (chez moi, j'observe une différence entre les 2 définitions, faible, mais reproductible).

Pour le code, il faut attendre que je sois rentré.
05/12/2006, 18h38
thewho

Bonjour,

Effectivement, les vitesses proches en optimisant ou non m'intriguaient quand même un peu.

Je viens de vérifier, et je m'aperçois que j'avais utilisé un mauvais batch (j'en ai défini quelques uns pour me faciliter la vie, pas toujours écrire la même chose)

Donc rectification :

Dans tous les cas avec optimisation, le cast gagne sur l'astuce

même si ce n'est pas énorme en gain.

Pour le code, comme c'est carrément brouillon (pour rester poli !), car c'est un programme qui ne me sert qu'à faire des tests, et ça finit par être très encombré.
Ça va me demander un peu de travail pour la mise au net, mais pour résumer :

- les temps d'exécution sont mesurés avec QueryPerformanceCounter sur un grand nombre de boucles, sans que je prenne la peine de tenir compte du temps passé à boucler, puisqu'il est le même dans les 2 mesures, à optimisations égales.
05/12/2006, 18h45
bricerive

J'essaye de ratrapper mon retard

Citation:

Pour forcer le second bit à 1, car le premier est implicite ?

C'est en fait pour être certain de rester avec la mantisse alignée sur le bit 0 quand on a des doubles négatifs.

Citation:

- Aucune garantie que ça fasse quoi que ce soit. Ecrire dans un membre d'une union et lire dans un autre est un comportement indéfini. Il se peut que ça marche sur une certaine machine, avec une certaine version d'un compilateur, avec certaines options de compilation, pendant certaines phases de la lune, mais rien n'est moins sur.

Tu as raison. On peut un peu réduire ce problème en utilisant le réinterpret_cast suggèré par Médinoc, mais de toute façon, le truc entier dépend d'un tas de conditions similaires: c'est un hack!

Citation:

Déjà, le résultat n'est pas le même qu'un simple cast en int. Un cast tronque, ta méthode fait autre chose

Tu as raison, je me suis mal exprimé: c'est pour faire une conversion double vers int en arrondi, c'est en général ce dont tu as besoin pour faire du calcul. L'arrondi est exact.

Citation:

Sans ce test (en se limitant à des nombres positifs), elle est plus rapide de 10% à 20%.

C'est le rapport que j'avais mesuré entre la version d2i et la version assembleur. Ce gain (que je trouve étonnant, personellement) semble être réellement une différence basique entre le add et le fistp.

Citation:

Les variations dépendent de si je fais beaucoup d'itérations sur des petits jeus de données, ou moins d'itération sur des plus grand (moins bonne utilisation de la mémoire, qui vient masquer les différences, ce qui tend à dire que dans une utilisation classique, la différence sera probablment elle aussi masquée par d'autres aspects)

Bien entendu. N'importe quelle tentative d'optimisation de cette conversion souffrira de ce genre de problème. Comprends moi, je ne dis pas qu'il faut optimiser du code de cette manière, je file juste un hack qui peut aider dans certains cas particuliers. Ça m'a personnelement servi dans un cas particulier. Je n'en ai pas fait une recommendation auprès de Boost :-)

Citation:

On est quoi qu'il en soit loin du *8 sur cette architecture.

Dans la mesure que j'avais faite qui donnait ce résultat, l'assembleur géneré par VC8 appelait une fonction (de la runtime lib, je crois) au lieu d'inliner l'operation, d'où le rapport plus élevé. Je ne me suis pas vraiment attardé sur le pourquoi du comment. Je vais voir si je peux retrouver mon code de test qui est peut-être érroné.

Citation:

- MAIS en utilisant l'assembleur (celui que tu as donné), le rapport de vitesse s'inverse !

Il n'y a pas de secret. L'assembleur doit être différent (celui géneré pour d2i). Il faudrait comparer le code généré dans ton cas avec le mien.

Citation:

Après tout, c'est un astuce pour gagner en vitesse, pourquoi faire une multiplication dans le calcul, alors qu'on peut la faire en avance ?

Tous les compilateurs réduisent ce genre d'expression au moment de la compilation (optimisée). C'était juste un indice pour le lecteur qui voulait comprendre ce qui se passe au niveau de la représentation du double.

Bon je vais m'arrêter là. Juste une petite remarque. À la base, j'essayais juste de filer un coup de main. Je pensais pas me faire assaillir de la sorte :aie:
05/12/2006, 19h22
thewho

Bonjour,

Personne ne t'a assailli. Il ne faut pas être paranoïaque et tout comprendre comme une agression (:mouarf:)
05/12/2006, 22h22
Médinoc

Pour le coût de la conversion, on m'a dit (mais j'ignore sur quelle architecture exactement) qu'une conversion entre flottants et entiers néccessitait de reconfigurer la FPU, sachant qu'il faudrait ensuite la reconfigurer dans l'autre sens pour refaire une opération flottante...

Ainsi, sans optimisations de calcul vectoriel, la conversion d'une liste de flottants en liste d'entiers aurait nécessité deux reconfigurations par nombres.

Mais j'ignore quelle confiance accorder à cette information car l'ami qui m'a dit ça travaille sur plusieurs architectures, dont certaines embarquées, et je ne crois pas qu'il m'avait spécifiquement désigné une architecture x86...

Bonjour,

Citation:

Envoyé par Médinoc

Pour le coût de la conversion, on m'a dit (mais j'ignore sur quelle architecture exactement) qu'une conversion entre flottants et entiers néccessitait de reconfigurer la FPU, sachant qu'il faudrait ensuite la reconfigurer dans l'autre sens pour refaire une opération flottante...

Ainsi, sans optimisations de calcul vectoriel, la conversion d'une liste de flottants en liste d'entiers aurait nécessité deux reconfigurations par nombres.

Mais j'ignore quelle confiance accorder à cette information car l'ami qui m'a dit ça travaille sur plusieurs architectures, dont certaines embarquées, et je ne crois pas qu'il m'avait spécifiquement désigné une architecture x86...

Sur certaines FPU, peut-être, mais par exemple les processeurs Intel ne le nécessitent pas, il n'y a qu'à appeler la bonne fonction.
Par contre, on peut régler la manière dont se fait l'arrondi, etc..., mais en pratique on utilise pratiquement toujours la configuration par défaut, et quand ce n'est pas le cas, le programmeur qui travaille proprement se doit de rétablir cette configuration.

JolyLoic m'avait demandé mon code de test, le voici:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 #include <iostream> #include <stdarg.h> #include <windef.h> #include <winbase.h> #include <string> using namespace std; typedef long long int_64; //#define D2I_CONVERSION_FACTOR (1.5 * 4503599627370496.0) #define D2I_CONVERSION_FACTOR 6755399441055744.0 inline int d2i(double val) { union { int i[2]; double d; } dlong; dlong.d = val + D2I_CONVERSION_FACTOR; return dlong.i[0]; } // la fonction qui fait le test void tt(void) { // nombre de boucles à faire #define NB 100000000 LARGE_INTEGER t1,t2,t3,t4; // pour stocker les points de QueryPerformanceCounter // encadrant les boucles double d = -12345.1234665; int n1 = 0, n2 = 0; // boucle utilisant "l'astuce" d2i QueryPerformanceCounter(&t1); for (int i=0;i<NB;++i) { n1 = d2i(d); } QueryPerformanceCounter(&t2); // boucle utilisant le cast classique, ou l'assembleur // (commenter/décommenter la version à tester) QueryPerformanceCounter(&t3); for (int i=0;i<NB;++i) { // pour tester le cast classique //n2 = (int)d; // pour tester en assembleur __asm__ ( "fldl %[orig]\n\t" "fistpl %[dest]\n\t" : [dest] "=g" (n2) : [orig] "m" (d) : ); } QueryPerformanceCounter(&t4); // calcul des durées et du rapport, et affichage des résultats int_64 r12 = t2.QuadPart - t1.QuadPart; int_64 r34 = t4.QuadPart - t3.QuadPart; double rapport; if (r34) { rapport = (double)r12/(double)r34; } else { rapport = -1; } cout<<"special : "<<r12<<", cast : "<<r34<<", rapport (astuce/cast) = "<<rapport<<endl; if (n1!=n2) { cout<<"error (n1 = "<<n1<<") != (n2 = "<<n2<<")"<<endl; cout<<"n1 = "<<n1<<", n2 = "<<n2<<endl; } else { cout<<"bravo, n1 == n2 = "<<n1<<endl; } } int main() { tt(); return 0; }
Comme vous pouvez le voir, aux simples tests de vitesse, j'ajoute à la sortie des tests sur la validité des résultats, vieille habitude qui devrait être générale.

Ça va faire hurler Emmanuel "C'est pas portable !", mais comme j'utilise des API Windows, et il faut bien utiliser les types allant avec (LARGE_INTEGER).

05/12/2006, 23h13
Mat.M
Citation:

Envoyé par bricerive

(Pour ceux qui voient vraiment pas comment ca peut marcher, au point de croire que ca marche pas, je ne saurais trop recommander de faire un essai)
Code:

1 2 3 dlong.d = val + D2I_CONVERSION_FACTOR; }
Je suis très très sceptique sur le fait que cela soit plus performant
:roll:

Citation:

Envoyé par JolyLoic

Parmi les inconvénients de cette méthode, j'ajouterai :
- Aucune garantie que ça fasse quoi que ce soit. Ecrire dans un membre d'une union et lire dans un autre est un comportement indéfini. Il se peut que ça marche sur une certaine machine, avec une certaine version d'un compilateur, avec certaines options de compilation, pendant certaines phases de la lune, mais rien n'est moins sur.

:ccool: 100% d'accord mais quel est le rapport avec les phases de la lune ?

Citation:
Envoyé par thewho
JolyLoic m'avait demandé mon code de test, le voici:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 [...] #include <iostream> double d = -12345.1234665; int n1 = 0, n2 = 0; // boucle utilisant "l'astuce" d2i QueryPerformanceCounter(&t1); for (int i=0;i<NB;++i) { n1 = d2i(d); } [...]
Ce que je n'aime pas trop dans ce genre de code de test, c'est qu'en convertissant toujours la même valeur dans une boucle, il me semble qu'un compilateur optimisant un minimum aggressivement peut très bien décider de générer du code équivalent à :
Code:

1 2 double d = -12345.1234665; int n1 = -12345;
C'est pour cette raison que mon code est plus complexe afin de lui faire convertir plein de valeurs, et d'essayer de le perdre un peu. En fait, ce qui est difficile dans ce genre de tests, c'est qu'on veut que le compilateur soit hyper agressif dans son optimisation du code à tester, et hyper conservatif dans le code de test lui même...

Quelques precisions

Re-moi :P

(Pardon pour les accents, je suis sur un Qwerty)

J'ai retrouve mon code de test et l'ai reduit au maximum pour comparer uniquement ce qui nous interesse.

En conclusion, la version assembleur et le d2i tournent a la meme vitesse a peu pres 3 fois plus vite que le cast.

L'output est:
Code:

1 2 3 4 5 double to int timings 3.078 -> using cast direct 1.500 -> using d2i fast 1.500 -> using asm direct 6.078 -> TOTAL
Ce test est avec VC8 full-optim sur un dual-core a 2Ghz.
Les mesures que j'ai faites auparavant etaient sur un Pentium 4 a 1.6Ghz, sur cette machine il y avait une difference de 10/20% entre d2i (un fadd plus un fstp) et le fistp et un rapport de 8 avec le cast (mais j'avais peut-etre active le modele floating point precis /fp:precise). Ce test est avec le modele fast (/fp:fast).
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 #define D2I_CONVERSION_FACTOR (1.5 * 4503599627370496.0) int _tmain(int argc, _TCHAR* argv[]) { const int iterations=500000000; mylib::Timer timer; volatile double theDouble=13.1; volatile int theInt, guard1[4]; for (int i=0; i<iterations; i++) theInt = static_cast<int>(theDouble); timer.Step("using cast direct"); for (int i=0; i<iterations; i++) *reinterpret_cast<volatile double *>(&theInt) = theDouble + D2I_CONVERSION_FACTOR; timer.Step("using d2i fast"); for (int i=0; i<iterations; i++) { __asm { fld qword ptr[theDouble] fistp dword ptr[theInt] } } timer.Step("using asm direct"); std::string report; timer.Report("double to int timings", report); std::cout << report; return 0; }
La boucle generee pour le cast est:
Code:

1 2 3 4 5 6 theInt = static_cast<int>(theDouble); 00402121 fld qword ptr [esp+14h] 00402125 call _ftol2_sse (4099D0h) 0040212A sub esi,1 0040212D mov dword ptr [esp+1Ch],eax 00402131 jne main+61h (402121h)
Pour la version assembleur:
Code:

1 2 3 4 5 6 7 8 __asm { fld qword ptr[theDouble] fistp dword ptr[theInt] } 004022A0 fld qword ptr [esp+14h] 004022A4 fistp dword ptr [esp+1Ch] 004022A8 sub eax,1 004022AB jne main+1E0h (4022A0h)
Pour la version d2i:
Code:

1 2 3 4 5 6 *reinterpret_cast<volatile double *>(&theInt) = theDouble + D2I_CONVERSION_FACTOR; 00402221 sub eax,1 00402224 fld qword ptr [esp+14h] 00402228 fadd st,st(1) 0040222A fstp qword ptr [esp+1Ch] 0040222E jne main+161h (402221h)
Pour finir, j'insiste sur le fait qu'avec le define que j'utilise, il n'y aura qu'une multiplication faite au moment de la COMPILATION. Il suffit de regarder le code genere par ton compilateur.

06/12/2006, 01h18
bricerive
Citation:
Envoyé par JolyLoic

Ce que je n'aime pas trop dans ce genre de code de test, c'est qu'en convertissant toujours la même valeur dans une boucle, il me semble qu'un compilateur optimisant un minimum aggressivement peut très bien décider de générer du code équivalent à :

Code:

1 2 double d = -12345.1234665; int n1 = -12345;

C'est pour cette raison que mon code est plus complexe afin de lui faire convertir plein de valeurs, et d'essayer de le perdre un peu. En fait, ce qui est difficile dans ce genre de tests, c'est qu'on veut que le compilateur soit hyper agressif dans son optimisation du code à tester, et hyper conservatif dans le code de test lui même...
Je suis d'accord, et c'est peut-etre ce qui se passe pour le code de test de thewho... i l faut regarder le code genere.
Pour mon code, j'ai simplement specifie que les variables sont volatiles, ce qui garanti que l'optimisation ne peut rien sortir de la boucle.
06/12/2006, 02h33
thewho
Bonjour,
Citation:
Envoyé par JolyLoic

Ce que je n'aime pas trop dans ce genre de code de test, c'est qu'en convertissant toujours la même valeur dans une boucle, il me semble qu'un compilateur optimisant un minimum aggressivement peut très bien décider de générer du code équivalent à :

Code:

1 2 double d = -12345.1234665; int n1 = -12345;

C'est pour cette raison que mon code est plus complexe afin de lui faire convertir plein de valeurs, et d'essayer de le perdre un peu. En fait, ce qui est difficile dans ce genre de tests, c'est qu'on veut que le compilateur soit hyper agressif dans son optimisation du code à tester, et hyper conservatif dans le code de test lui même...
C'est un fait, mais avec pas mal de boucles, tu t'en aperçois immédiatement, et tu peux faire autre chose à ce moment là.

Mais l'avantage, c'est qu'en dehors du temps nécessaire à la boucle elle-même, on mesure le temps effectivement nécessaire à la fonction (à peu près).
06/12/2006, 06h27
JolyLoic
Citation:
Envoyé par bricerive

En conclusion, la version assembleur et le d2i tournent a la meme vitesse a peu pres 3 fois plus vite que le cast.

L'output est:

Code:

1 2 3 4 5 double to int timings 3.078 -> using cast direct 1.500 -> using d2i fast 1.500 -> using asm direct 6.078 -> TOTAL
J'ai exécuté ton code sur ma machine, et j'ai comme valeurs :
Code:

1 2 3 using cast direct : 2.812 using d2i fast : 0.719 using asm direct : 0.484
En ajoutant le test de positivité pour faire une tronquation, d2i fast redevient plus long, avec environ 4s. Les résultats sont cohérents avec les miens, avec un écart plus marqué du fait qu'on fait moins d'opérations. Par contre, chez moi, la version assembleur est plus rapide.
06/12/2006, 10h27
bricerive

Citation:

Envoyé par JolyLoic

Les résultats sont cohérents avec les miens, avec un écart plus marqué du fait qu'on fait moins d'opérations. Par contre, chez moi, la version assembleur est plus rapide.

Je pense que la comparaison assembleur contre d2i dépend enormément du CPU. D'où ces différences.

En conclusion:
-Si tu veux faire un cast (tronquer), utilise le cast - sauf si ton appli tourne en mode precis (/fp:precise) auquel cas d2i ira plus vite.
-Si tu veux faire un round (arrrondi), utilise d2i (ou l'assembleur, mais c'est encore moins lisible et portable).
06/12/2006, 15h49
thewho

Bonjour,

Bien entendu, ce qu'il faut utiliser dépend du programme.

Il ne faut pas oublier que nous discutons certes d'un facteur de temps d'environ 2 à 3, mais sur une opération seulement, qui dans tous les cas reste rapide par rapport à d'autres.

Même avec de très nombreux appels, il est probable que le reste du calcul soit largement prédominant pour le temps d'exécution.