9
votes

Quel casting est plus rapide static_cast () ou int ()

Essayez de voir quelle moulage est plus rapide (pas nécessaire mieux): nouveau boîtier C ++ ou ancienne mode de style C. Des idées?


5 commentaires

Vous pouvez toujours écrire un script de référence. Il suffit de faire 10 millions de statiques_cast et de 10 millions d'INT, et voyez laquelle il faut plus de temps. mon devinez est qu'ils compileront à la même instruction d'assemblage.


Ne tenant compte du fait qu'ils compilent presque certainement la même chose sur tous les compilateurs, pourquoi cela serait-il important? Sauf si vous avez connu des problèmes de performance, vous écrivez pour être clair et évitez les microoptimisations plus difficiles à lire, probablement inutiles de toute façon. Utilisez static_cast ().


Les moulages de style C sont définis en termes de moulages de style C ++ (et de moulages de style C peuvent se lancer vers des bases privées ...). Donc, ils sont en fait assez équivalent. Personne n'a une performance de stimuler l'autre.


Pour ce que ça vaut, int (10,4) n'est pas une coulée de style C, car ce n'est pas valide c (il appelle la fonction int () avec un argument). Le casting "C-style" est (int) 10.4 .


@Chris: TRUE, mais la distribution de type fonction est exactement équivalente à la distribution de style C.


7 Réponses :


2
votes

Regardez l'ensemble à l'aide de chaque méthode. S'il diffère, utilisez un profileur.


0 commentaires

34
votes

Il ne devrait y avoir aucune différence sur tout si vous comparez int () code> à fonctionnalité em> fonctionnalité de static_cast () code>.

Utilisation de VC2008: P>

    double d = 10.5;
013A13EE  fld         qword ptr [__real@4025000000000000 (13A5840h)] 
013A13F4  fstp        qword ptr [d] 
    int x = int(d);
013A13F7  fld         qword ptr [d] 
013A13FA  call        @ILT+215(__ftol2_sse) (13A10DCh) 
013A13FF  mov         dword ptr [x],eax 
    int y = static_cast<int>(d);
013A1402  fld         qword ptr [d] 
013A1405  call        @ILT+215(__ftol2_sse) (13A10DCh) 
013A140A  mov         dword ptr [y],eax 


4 commentaires

Cela n'a pas l'air sexy pour moi :) Un sexy utiliserait des instructions SSE sans impliquer le FPU du tout :) (Je pensais que SSE a été utilisé par défaut dans VC déjà).


@Andreyt il fait :) Le code de la réponse a été produit en mode de débogage. Si vous essayez de le compiler avec des optimisations, utilisez des instructions SSE.


-1 (si je pouvais). Ce n'est évidemment pas. Votre réponse prouve que c'est la même chose que dans une certaine version de VS2008.


Est-ce que la plate-forme est dépendante? Différent compilateur peut-il traiter ces deux types de casting différemment?



1
votes

Ils sont identiques à ceux qui sont résolus pendant la compilation du temps lui-même et il n'y a pas de frais généraux d'exécution. Même s'il y avait une différence, je ne me dérangerais pas vraiment trop sur ces minuscules optimisations (pas même micro).


0 commentaires

4
votes

Aucune différence que ce soit.

Lorsqu'il s'agit de telles constructions de base en tant que casting unique, une fois que deux constructions ont le même sens sémantique, leur performace sera parfaitement identique et le code de la machine généré pour ces constructions sera identique.


0 commentaires

-2
votes

Lorsque vous avez le choix fait une petite différence pour le code, je choisirais celui qui semble plus familier aux programmeurs ultérieurs. La création de code plus facile à comprendre par d'autres vaut toujours la peine d'être envisagée. Dans ce cas, je tiens à int (...) pour cette raison.


2 commentaires

Pourquoi supposeriez-vous que Int (...) sera plus familier, cependant? Cela semble en fait ne pas être valable en C, étant peut-être plutôt un appel "pseudo-constructeur" de C ++. - En outre, en n'étant pas explicite sur le type de casting, pourquoi devrait-il rendre le code plus facile à comprendre?


Les moulages ne sont rien à redire et devrait donc être facile à repérer. C'est ce que sont les lancers de style C ++.



3
votes

Je crois que le résultat réel est défini la mise en œuvre. Vous devriez vérifier dans votre version de compilateur. Mais je crois que cela donnera le même résultat dans la plupart des compilateurs modernes. Et en C ++, vous ne devriez pas utiliser C-Cast, à la place, utilisez C ++ CASTS - Cela vous permettra de trouver des erreurs à l'heure de la compilation.


1 commentaires

Les problèmes de performance ne sont pas définis par la mise en œuvre (en fait, la norme n'impose aucune performance du tout, autrement que Big-O pour les opérations de conteneur)



0
votes

Comme la plupart des gens disent que, on espère que c'était la même vitesse, bien que vous soyez à la merci de votre compilateur ... et ce n'est pas toujours une situation très heureuse. Lisez sur des histoires de guerre.

Selon votre compilateur et le modèle particulier du noyau de processeur que le programme exécute sur la vitesse de float f; int i (f); , float f; int i = (int) f; et float f; int i = static_cast (f); et leur ILK (y compris les variations impliquant des types doubles, longs et non signés) peuvent être atroceusement lents - un ordre de grandeur pire que vous attendez. Le compilateur peut émettre des instructions modifiant les modes de processeur internes provoquant la jetée des pipelines d'instructions. C'est en fait un bogue dans l'élément d'optimisation du compilateur. J'ai vu des cas où l'on souffre des coûts de tri de 40 horloques mentionnés dans Cette analyse , à quel point vous avez un goulot d'étranglement majeur, inattendu et irritant avec AFAIK, aucune solution générique entièrement agréable, robuste et générique. Il existe des alternatives impliquant des assembleurs mais afaik ils ne rondent pas de point flottant entier de la même manière que les moulages. Si quelqu'un le sait mieux, je suis intéressé. J'espère que ce problème est / sera prochainement confiné aux compilateurs / matériels hérités, mais vous avez besoin de votre esprit sur vous.

P.s. Je ne peux pas atteindre ce lien car mon pare-feu bloque comme des jeux liés à des jeux, mais Un cache Google de celui-ci suffit pour démontrer que son auteur en sait plus que je faire.


0 commentaires