LES DEUX OPÉRATEURS DE DIVISION
violent_ken
Messages postés
1812
Date d'inscription
mardi 31 mai 2005
Statut
Membre
Dernière intervention
26 octobre 2010
-
14 mai 2007 à 22:59
draluorg Messages postés 625 Date d'inscription vendredi 23 avril 2004 Statut Membre Dernière intervention 25 novembre 2010 - 15 mai 2007 à 14:21
draluorg Messages postés 625 Date d'inscription vendredi 23 avril 2004 Statut Membre Dernière intervention 25 novembre 2010 - 15 mai 2007 à 14:21
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/42696-les-deux-operateurs-de-division
https://codes-sources.commentcamarche.net/source/42696-les-deux-operateurs-de-division
15 mai 2007 à 14:21
Je ne savais pas que le compilo de Vb faisait ce genre d'optimisations. Enfin il suffit de declarer en global Long1 et Long2 et ca passe....
Merci pour l'info je la retiendrai celle la!! :)
++
15 mai 2007 à 13:53
Concernant la division réelle "/", ce n'est pas simplement la division (fld fdiv) en boucle, car il y a aussi l'appelle de la fonction __vbaFpI4 pour convertir le résultat en entier! En effet, la variable qui stocke le résultat est de type Long, d'ou une opération supplémentaire de conversion Double vers Long. Une fois redéfini en type Double, on gagne plus de 2,5 de vitesse.
Bref, au final, en modifiant le code avec ces remarques, le résultat est :
- La division entière "" lorsqu'on travail sur des entiers est notre référence.
- La division réelle "/" lorsqu'on travail sur des entiers est 6 fois plus lente.
- La division réelle "/" lorsqu'on travail avec des réelles est 2 fois plus lente.
Le choix du type de division est aussi important que la précision souhaitée et les variables utilisées !
15 mai 2007 à 09:14
Tout a été dit sur cette source mais je voudrais juste dire que j'aime toujours les commentaires de Brunews :
""/" provoque tranfert des 2 opérandes en FPU (avec conversion induite) et génère un FDIV pour reconvertir ST(0) en long."
J'adore.. j'y pige rien mais c'est pas "de la bouillie de chat"! ^^
++
Moustachu
15 mai 2007 à 01:26
15 mai 2007 à 01:21
"1000 / 5" par exemple est illico transcrit en "200" à la compilation, c'est pas de la bouillie de chat un compilo C, rudement bien foutu.
15 mai 2007 à 01:13
En effet ce n'est pas la source indispensable, mais je trouvais important de mettre mettre en evidence la difference de temps d'execution car j'ai vraiment été étonné de voir une telle différence.
Mais comme je l'ai dit, c'est a vous de juger de la pertinence de cette source et si vous estimez qu'elle ne l'est pas n'hesitez pas a la supprimer.
Pour le compilo C, j'avais deja lu cette information, c'est pas tres pratique pour tester une routine... Comment kon fait alors ?
++
15 mai 2007 à 01:02
On peut effectivement dire que ce n'est pas la source indispensable.
Comme je te vois maintenant sur cppfrance, j'en profite pour te rappeler de ne jamais transcrire ce genre de test en C, le compilo ne génèrerait strictement aucun code de boucle car il zappe tout code inutile avant de produire le listing asm.
15 mai 2007 à 00:19
15 mai 2007 à 00:09
tu t'es trompé dans ta description
15 mai 2007 à 00:04
ps : au dessus de 50'000 d'itérations c'est moins représentatif, les petits proc (1Ghz) s'essoufflent donc mettent plus de temps que l'opération n'en demande
bonne soirée
14 mai 2007 à 23:46
PCPT> la source n'a aucun interret en effet, mais c'est ce qu'elle demontre qui en a!
Pour le GetTickCount eh bah sur 100000000 itterations c'est plus que suffisent surtout pour ce petit exemple...
"il faut aussi comparer en compilé ;)"
Eh bah vi forcement, un bench se fait toujours compilé!
Enfin apres si tu estimes que cette source n'as pas sa place a toi de voir...
++
14 mai 2007 à 23:30
pas sur que çà vaille une source :$
et le bench avec GetTickCount... pas précis et il faut aussi comparer en compilé ;)
et comparer le Fix() aussi.
bref, pas tip top :-(
14 mai 2007 à 22:59
Il est bon de noter que \ a une plage de valeurs limitée par rapport à /.
Exemple :
Private Sub Command5_Click()
MsgBox CLng(Int(10000000000# / 5))
MsgBox CLng(10000000000# \ 5)
End Sub
@+