A SUPPRIMER
ScSami
Messages postés
1488
Date d'inscription
mercredi 5 février 2003
Statut
Membre
Dernière intervention
3 décembre 2007
-
23 mai 2005 à 03:45
us_30 Messages postés 2065 Date d'inscription lundi 11 avril 2005 Statut Membre Dernière intervention 14 mars 2016 - 23 sept. 2005 à 21:37
us_30 Messages postés 2065 Date d'inscription lundi 11 avril 2005 Statut Membre Dernière intervention 14 mars 2016 - 23 sept. 2005 à 21:37
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/31544-a-supprimer
https://codes-sources.commentcamarche.net/source/31544-a-supprimer
23 sept. 2005 à 21:37
Merci pour ta proposition de code. IL est certain que je ne souci pas du système américain, et, surtout je ne sais pas trop comment la notation fonctionne. Que devient, par exemple le nb : 4332645465879876576543564325431645.478 , en américain ?
On pourrait étendre aussi la réflexion, en disant que si l'utilisateur rentre la décimale avec un point, on renvoi le résultat avec également un point... et inversement avec la virgule... (pour la notation normale, j'entends bien...) Mais est-ce vraiment nécessaire ? et puis si les deux nb ont chacun la notation "." et "," !?... faudra choisir...
A+
Us.
23 sept. 2005 à 09:46
j'ai un pb dans l'utilisation d'AGN :
- AGN accepte les decimaux qu'ils soient avec une "," ou un "."
- mais AGN ne renvoi son resultat qu'avec une ","
or mon ordi est en systeme americain (1,234.56 pour 1234,56)
donc il ne comprend pas la reponse d'AGN.
comme je suis souvent a cheval sur les 2 systemes, je me suis fait un bout de code pour gerer le pb... tu pourrais l'ajouter dans ton module :
Private DecSymbol As String
Private Declare Function GetLocaleInfoA Lib "kernel32" (ByVal Locale As Long, ByVal LCType As Long, ByVal lpLCData As String, ByVal cchData As Long) As Long
Private Declare Function GetSystemDefaultLCID Lib "kernel32" () As Long
Private Function GetLocalInfo(ByVal Id As Long) As String
On Error Resume Next
Dim sBuffer As String
Dim nBufferLen As Long
nBufferLen = 255
sBuffer = String$(nBufferLen, vbNullChar)
nBufferLen = GetLocaleInfoA(GetSystemDefaultLCID, Id, sBuffer, nBufferLen)
If (nBufferLen > 0) Then GetLocalInfo = Left$(sBuffer, nBufferLen - 1)
End Function
Private Function GetDecSymbol() As String
If (DecSymbol = "") Then _
DecSymbol = GetLocalInfo(&HE)
GetDecSymbol = DecSymbol
End Function
l'interet d'utiliser une variable globale DecSymbol est d'éviter dans le cas de calculs multiples que le prog aille chercher a chaque fois dans la base de registre.
7 sept. 2005 à 20:30
JE viens de faire plusieurs tests, en type Double et Décimal. Résultat : le type Double reste le plus rapide d'environ 10% par rapport au type Décimal !
Voilà !
Amicalement,
Us.
6 sept. 2005 à 22:36
JE suis accord avec toi, jusqu'à la première moitié de ton baratin... -:); Ensuite, ben... plus vraiment... En fait, tu rentres dans la très épineuse question sur l'optimisation du temps d'exécution...
Bon, UNE chose est sûr, le temps de calcul est différent selon le type de déclaration des variables. Le type Long est plus rapide (un peu) que le type Double... c'est l'objet des discusions du début... et donc la conclusion était d'utiliser le type Double, mais l'avantage par rapport à Long, en est assez faible, même s'il existe...
Ensuite pour les opérations, il semble en effet que le temps soit le même, en gros seulement... pour une même type de variable...
Pour ta remarque du type Décimal, c'est une très bonne remarque, que je testerais prochainement, surtout si le temps est vraiment comparable à deux Double...
Amicalement,
Us.
Maxime : 104 ans et toutes mes dents ! -:);
6 sept. 2005 à 13:26
6 sept. 2005 à 13:22
c'est maintenant une chose prouvee, l'algo d'us_30 est plus rapide.
j'ai largement analyse les 2 codes (c'est en fait par la lecture du code et non par un test que j'ai decouvert ton bug us, c'est pourquoi je savais d'ou venait l'erreur avant meme de la comettre).
puis j'ai realise une batterie de tests pour l'addition sur plusieurs serie de 100 nombres de taille aleatoire (entre 1 et 500000 chiffres).
pour rendre la comparaison plus exacte, j'ai en fait reecrit les 2 algo mais en simplifie, le resultat est faux mais c'est pour aller plus vite, le seule interet est de comparer sur des codes tres similaires la vitesse d'execution entre string et array :
cas #1 : en string
- redimensionnement des nombres, les 2 chaines doivent avoir la meme taille (c'est cette operation qui faite sur des string est extremement plus longue que la meme operation faite sur des tableaux)
- j'ecrit un resultat faux comme concatenation des sommes des series de 15 chiffres (ca ne prend pas en compte les retenues)
cas #2 : en array
- decoupage des nombres et affectation dans les cases des tableaux (c'est cette operation qui est beaucoup trop longue ! je l'avais dit plus haut, affecter une variable c'est plus long que de faire un calcul)
- redimensionement des tableaux (c'est extremement rapide, mais pas assez)
- j'ecrit un resultat faux comme concatenation des sommes des cases des tableaux (ca ne prend pas en compte les retenues)
voila ! en moyenne il faut 0.029s pour traiter 100 additions sur des strings alors qu'il faut 0.044 pour traiter les memes additions dur des tableaux.
comme en ce moment je m'emmerde (il faut soit que je trouve un boulot soit que je parte en voyage), j'ai realise une autre batterie de tests interessant. les temps de calculs sur des operations de base (+ - x /) sont les memes quel que soit le data type (de byte jusqu'a double)... je dis vraiment le meme, parfois plus long parfois plus court, mais la moyenne sur des dizaines de milliers de calculs donne le meme resultat pour tous ! autrement dit, us le savait deja, il vaut mieux utiliser le plus grand type de donnee pour economiser les passages dans la boucle.
mais il y a plus interessant : le rapport de temps de calcul entre variant et un type precis est 2. s'il faut une seconde pour faire une operation en byte, il en faudra une pour la faire en long ou en double mais il en faudra 2 pour la faire en variant.
connaissez vous le type decimal ? c'est un sous-type de variant qui accepte jusqu'a 28 chiffres significatifs, autrement dit 2 fois plus qu'un double. oui mais le temps de calcul est double en variant donc on n'y gagne rien... et si ! puisqu'on passe 2 fois moins souvent dans la boucle ! si vous m'avez compris, a vos compilo, on peut encore ameliorer le code d'us_30 !
4 sept. 2005 à 22:00
Amicalement,
Us.
4 sept. 2005 à 00:18
A+
Us.
3 sept. 2005 à 23:54
3 sept. 2005 à 23:44
Merci encore,
Us.
3 sept. 2005 à 20:34
tres bonne idee, bon code.
une des operation qui prend le plus de temps cpu est l'affectation de variable. autrement dit le code suivant :
dim Var1 as Long
dim Var2 as Long
dim Var3 as Long
Var1 = Len("Bonjour")
Var2 = Var1 ^ 2
Var3 = Var1 + Var2
prend plus de temps que celui-ci :
dim Var3 as Long
Var3 = Len("Bonjour") + Len("Bonjour") ^ 2
et ceci malgre la repetition de l'operation Len().
bref j'intervenais en realite pour signaler un bug :
si on fait une soustraction dont le resultat est negatif et que le premier chiffre de Nb2 est inferieur au premier chiffre de Nb1 alors AGN(Nb1, Nb2) renvoi une erreur.
par exemple AGN(8, -12)
le programme detecte qu'il s'agit d'une soustraction mais au moment de determiner lequel des membres est le plus grand, la fonction StrComp() renvoi 8>12. et c'est normal puisque StrComp fait une comparaison de texte.
21 août 2005 à 13:06
Soit j'ai bien compris, et dans ce cas, je pense avoir déjà répondu. Soit j'ai rien compris. Désolé, mais je ne connais pas le langage Delphi, ce qui ne me permet pas de bien saisir la justesse de tes propos. Si en Delphi, il suffit de coder les 4 lignes pour avoir l'opération d'addition, ou de multiplication avec des grands nombres (Jusqu'à 2 millions environ), alors je me converti sur le champ à Delphi. Et sans regret, pour VB...
Sinon, il ne faut pas s'éprendre sur la longueur du code que je propose. L'addition (le coeur du problème, et déterminant pour la durrée de l'opération) est réalisé par ceci :
'Addition
Total = String$(lgmul, z)
For t = lgmul - Multiple + 1 To 1 Step -Multiple
V1 = Mid$(Nb1, t, Multiple)
V2 = Mid$(Nb2, t, Multiple)
r = V1 + V2 + Ret
lr = Len(Str$(r))
Ret IIf(lr Multiple + 2, 1, 0)
Mid$(Total, t - lr + Multiple + 1, lr) = r
Next t
La conversion est réalisé, en fait, en interne. La lecture de NB1 ou NB2 (les deux nb à additionner) qui sont en Texte (string), sont directement convertis en nombre lors de opération pour "r". IL y a donc pas vraiment de temps perdu, en passant par une instruction pour convertir le texte en nombre... De plus, si on "tronçonne" les nombres NB1, NB2 pour les mettre dans un tableau, on est obligé de passer par ces mêmes étapes. (donc pas de gain de temps)...
Amicalement,
Us.
PS : Y'a pas de problème tu peux donner ton avis, au contraire, cela oblige à se poser des questions, pourquoi ceci et pas cela... mais en l'occurrence, je crois avoir fait pas mal le tour de la question sur ce sujet précis... même s'il est (peut-être) possible de faire un meilleur algorithme (en terme de rapidité)... et dans ce cas, j'espère le trouver...
21 août 2005 à 02:14
Dim a as BigInteger, b as BigInteger, c as BigInteger
a = big("tres tres grand nombre")
b = big("tres tres grand nombre 2")
c = addition(a,b)
d = multiplier(c,a)
C'est plus commode et pas besoin de convertir à chaque fois.
Bah c'était juste pour donner mon avis parce que je que mettre de la conversion String -> entier ralentit considérablement ton code.
Amicalement RedDevlopper.
ment le code surtout si c'est placé dans une boucle.
20 août 2005 à 21:19
Qu'entends-tu par tableau de Byte ? ... si tu sous-entends, "tronçonner" les 2 nombres à calculer dans un tableau "DIM" de variables numériques, alors non, ce n'est pas plus rapide ici... L'algorithme présenté ici, est le résultat de nombreux essais, avec différentes utilisations de fonctions... IL existe sûrement encore moyen d'augnemter la rapidité, mais pas sur le principe de base (emploi de string)...
La représentation en base 256 ou autre, n'est pas forcément le plus rapide... C'est certes, plus court pour écrire les nombres, mais il ne faut pas oublier, qu'avant de calculer dans une autre base, il faut convertir les 2 nombres dans la base de calcul, et, accessoirement convertir aussi les 2 strings, contenant les données de départ, en nombres (donc même chose dans les deux cas de figure)... et je considère pour la rapidité de l'algorithme, toutes les étapes...
L'utilisation des strings c'est révelé ici bien le meilleur (et de loin). Cela se comprend facilement, lorsqu'on décortique les étapes. L'emploi direct d'une "string" à la longueur du résultat évite toutes les opérations de réallocation... et c'est là le plus grand gain de temps... (si cette précaution n'est pas prise, alors la rapidité devient très réduite, voir mauvaise...). Ensuite, par rapport à un tableau de nombre qui "tronçonne" les deux nombres du départ, on gagne justement du temps dans les étapes de stockage dans le tableau. Cette étape (pouvait apparaitre anodine) est non négligeage (en terme de temps), elle constitue même la durée principale d'un tel algorithme... et c'est d'ailleurs ce type d'étape qui conditionne la durée dans mon autre algo pour le produit de 2 nombres... et subtilité suprême, pour le produit, c'est bien l'emploi d'un tableau qui se révèle plus rapide que l'emploi de strings... du moins tel que j'ai pu le programmer...
Enfin, bon, voilà, j'espère que ce point d'explication permettra d'éclaircir ce sujet, déjà bien discuté... et pis, va falloir que je m'y remettre sur les Grands Nombres...
Amicalement,
Us.
20 août 2005 à 17:04
ca ira plus vite pour le calcul (tu ne seras pas obligé de convertir à chaque fois string -> entier).j'avais déjà programmé ça en Delphi & assembleur ca marche très bien. J'ai pu additionner avec les 5000 premières décimales de pi avec les 5000 qui les suivent je n'ai pas eu trop de mal.
L'idéal sera de programmer dans un langage de programmation compilé (c++ par exemple) et créer une dll avec qui sera facilement utilisable en VB.
12 juin 2005 à 23:00
Le résultat de l'étude comparative m'a surpris. En effet, le type Double se révèle bien le plus rapide, mais de presque rien... Il a fallu regarder bien au-delà de 32 000 chiffres pour avoir un début significatif de différence de temps (et encore, c'est pas grand chose). Ma surprise vient justement de cette faible différence... Le type Long rattrape très bien son handicap malgré le nombre élevé de passages supplémentaires dans la boucle FOR... C'était donc bien une chose intéressante à vérifier... Si cette boucle comportait plus de calcul, l'avantage aurait été probablement pour le type 'Long'...
Maintenant, pour argumenter sur la compilation. J'ai essayé mes p'tits tests "triviaux" (S=S+1) en quelques sortes, à titre de comparaison sur VB 4 (c'est un peu ancien, je sais...) en mode "création" et compilé, et j'ai obtenu exactement les mêmes durées... De plus, ayant réalisés ces tests sur un autre PC (basé sur l'Athlon XP 2000+), j'ai pu constaté aussi le même pourcentage d'écart entre Long et Double, à savoir ce fameux 14%... Tout cela me laisse à penser qu'il existe une régularité suffissante pour que des petits programmes de tests soient significatifs pour juger de la rapidité, reste à bien contrôler les subtilités comme le dit Dnob, pour ne pas utiliser abusivement une structure mettant en jeu des accès aux données différements des programmes réels (ici avec la pile)... Néanmoins, on notera que le "sens" (Long plus rapide que Double) a toujours été respecté... Voilà, tout ce discours fait aussi un début de réflexion et de réponse à ScSami pour son idée de faire un programme de test de la vitesse... Un petit tour dans la rubrique dans Optimisation de code, montre aussi que cette idée n'est pas nouvelle... Ensuite, je rajouterais qu'il existe deux façons d'optimiser un code. Soit en améliorant la structure et l'utilisation des fonctions, soit en utilisant un meilleur algorithme. Pour ce dernier "l'addition" traité ici, on peut dire suite à l'étude du temps d'exécution, que l'algorithme est optimale, puisque mathématiquement la complexité de l'addition est linéaire. C'est bien ce qu'on observe ici. Par conséquent le seul moyen d'optimiser ce code c'est par une encore meilleur "programmation informatique" en quelque sorte...
Ensuite, pour revenir à ScSami, je pense poursuivre déjà mes problèmes de calculs avec des grands nombres, qui me permettent aussi de soulever de nombreux aspects d'optimisations sur le code, comme traité ici (et ailleurs aussi), en profitant des connaissances et des expériences des intervenants plus aguerris que moi. IL est évident qu'il faut déjà avoir fait un bon "tour" de la question sur l'optimisation avant de pouvoir prétendre faire qlq chose de sérieux sur le sujet... donc pour ma part, si qlq'un veut se lancer dans ce projet, je l'encouragerais aussi selon mes modestes moyens... et tiens, ScSami, je te renvois la question, si tu veux t'en charger, je te soutiendrais !
A+
Us.
12 juin 2005 à 16:45
Us, si tu veux t'en charger, je te soudiendrais... Au moins moralement ;-))
12 juin 2005 à 16:20
J'ai bien pris note de toutes vos remarques (nombreuses) et vous en remercie. Et je me suis pas senti agréssé, juste un peu agacé. Et s'il faut tout reprendre, et ben... je veux bien, mais à la condition que cela en vaille le coût. Mais avant de répondre en détail, je vais reprendre mon code pour permettre le test en type 'Long'... LA remarque concernant l'utilisation de la pile dans le cas trop simplifié de mes tests me semble justifié, suite justement à quelques nouveaux tests en évitant d'utiliser une constante +1. J'ai obtenu ainsi un écart de 34% au lieu de 14%, mais il reste encore difficile de bien conclure. Ceci, prouve toute de même que faire des petits programmes de tests est justifiés, mais reste à en comprendre toutes les subtilités. Et une justification m'était nécessaire, car bien mieux qu'une simple évocation face à mon argumentaire... Bref, je vais partir pour quelques temps dans une batterie de tests en tout genre... alors, A+ !
Us.
8 juin 2005 à 18:19
Pourquoi le test ne peut-il pas être valide ? dans le CPU comme vous le savez il y a une pile et des registre. Mais pour calculer avec les nombre en virgule flottante (comme les double) il y a une autre pile. Donc pour faire des calcul il faut à chaque fois copier les nombres depuis la mémoire dans la piel du FPU. Mais si on fait une boucle avec dix milliosn d'addition, et bien le nombre que l'on est en train d'additionner est dans la pile, et on lui ajoute un à chaque fois, "1" qui peut rester aussi dans la pile en permanence.
Pour le test c'est pareil on a déjà dans la pile le nombre 10 000 000et on le compare avec S. Tout ce passe dans la pile du FPU (si VB est pas trop mauvais comme je le disait).
Mais dans la réalité, dans ton programme, les données change tout le temps donc à chaque calcul il faut recharger dans la pile du FPU les nouvelles données pour faire l'addition, et c'est une opération extrêmement longue.
C'est pourquoi je dit qu'on ne peut dire que les long ou les double sont meilleur ou plus mauvais qu'au cas pas cas et donc qu'ici il faudrait tester dans ton programme. Cela ne me semble d'ailleur pas si long de modifier le programme pour qu'il utilise des long.
Ensuite il suffit de se dire que le double est un type en virgule flottante, donc à chaque opération, il y a plein de calcul pour vérifier la cohérence des calculs décimaux. C'est absolument inutiles quand on manipule des entier mais ça on ne peut pas le dire à VB (effectivement au niveau ASM c'est possible, mais hors de sujet).
Donc disont que je n'assure pas une idéologie sur une autre, mais que je pense très fortement (ailant déjà écrit le même programme) que l'utilisation des long est plus adapté.
Ensuite si tu ne veux pas te fatiguer à tester la modification, libre à toi.
Mais si tu le fait tu peut en profiter pour écrire proprement ton programme avec des constantes à la place des 15 qui train un peu partout pour justement que ce genre de modification soit très rapide à effectuer.
8 juin 2005 à 16:35
Sinon je suis, mais alors, à 100% d'accord avec toi!!! Il faut savoir considérer à sa juste porté ce que je vous ai extrait de la MSDN (DU VB6!!! Attension, ça a son importance pour la compilation!!!). Car en effet, ce qui est important c'est surtout de savoir que le type de base est le Long car, comme on l'a dit, natif pour les proces en 32 bits. C'est, on peut dire, le type "normale" (si la normalité existe!!!) duquel sont donc "dérivés" les autres types... Enfin, vous me comprenez quoi!
Alors quand la MSDN préconise d'éviter l'utilisation des types supérieurs au Long, il faut bien évidemment savoir relativiser et utiliser ses quelques neuronnes afin de comprendre le pourquoi et les cas où l'on doit tenir compte de cette préconisation !!! En effet, par exemple, il faut aussi savoir que le type Double n'est pas totalement finit (tout du moins dans la version 6 du VB). On le remarque entre autre dans les fonctions de convertion... Mais ceci ne veut pas dire qu'on NE DOIT PAS l'utiliser!!! D'ailleurs, si on ne devait vraiment pas ou s'il n'avait vraiment aucune utilité, il n'existerait pas!!! Ben vi, après tout, on peut tout coder en Long!!! Mais il est indéniable que le type Bool est aussi utile que le Byte et que le Double!!!
C'est un peu le même problème qu'avec le Goto là!!!
La programmation nous limite déjà tellement qu'il serait franchement dommage de se priver encore de quelques fonctions sous des pretextes idéologiques ou philosophiques mal fondés!!!
Mais pour revenir plus concrêtement à notre problème, je dirais juste à Dnob qu'on a que faire d'un test réel!!! Si on devait tester tout ce qui est logique, avant de créer une autoroute on bitumerait toute la France!!! ;-)
Ce que je veux dire par là c'est que Us30 a parfaitement raison sur toute la ligne... De toutes façons, hein, franchement, il faut quand même le dire une bonne fois pour toute (!!!), si on voulait vraiment optimiser ce code à fond, ben il faudrait le coder en C ou en ASM!!! Parce que, comme dit Us30, ben c'est clair que toutes les opérations entre les calculs arithmétiques prennent beaucoup de temps!!! Et il faudrait déjà commencer par là je crois!!!
Tient, d'ailleurs, je crois que les de "IF" pompent moins de TDC (Temps de calcul) que les "IIF" si je dis pas de conneries... Car les IIF évaluent toutes les expressions (True, False)... Enfin, c'est un test à faire!
Mais pour les tests de Us30, pour moi ils sont parfaitement valides (a part qu'on auraient préféré que les résultats soient exprimés en "ns" !!!). Car, si on ne change pas les instructions entre les calculs arithmétiques, étant donné que la boucle est logiquement plus longue, il suffit en effet de regarder la différence entre le Long et le Double et de la comparer avec celle entre la boucle du Double et cette du Long le tout en pourcentage comme Us l'a fait!!! Enfin, je ne vois vraiment pas où est le problème!!!
Ceci dit, c'est vrai que les tests devraient s'effectuer compilés pour être valides...
Sinon, une autre technique pourrait être envisagée... en travaillant directement sur les bits via des opérations booléens (AND, OR, ...). Enfin, ce que j'en dis moi!!!
Sinon, avec les CPU actuels, dans tous les cas je crois sincèrement qu'on a pas beaucoup de soucis à se faire!!! Je rajouterais de plus que, pour améliorer la vitesse du prog, il suffit de fermer quelques precessus inutiles voir quelques logiciels tournant en background!!! Et, pour finir, je dirais même que s'il est impossible d'obtenir le résultat instantanément, ben quoi qu'on fasse, l'utilisateur devra faire preuve de patience... alors 3 ou 4 secondes de plus ou de moins ne changerons rien pour ce dernier!! Ceci dit, on pourrait faire une étude statistique afin de déterminer la moyenne du temps qu'un utilisateur met pour aller pisser lors d'une phase d'attente afin de déterminer le temps maxi qu'un calcul doit avoir ;-)))
Enjoy
(Pour le problème d'affichage, oui, j'en ai un qui, en effet, est dû au non retour à la ligne... car j'utilises FireFox et, visiblement, le codeur HTML de CS n'a pas tout prévu ;-) Ceci dit, étant donné que j'ai copié la ligne dans mon post avant que tu ne l'as corrige dans ton commentaire, ben j'ai toujours ce fichu problème!!! Mais merci quand même de t'être donné cette peine :-)
5 juin 2005 à 11:02
ET avant de me fatiguer à réadapter mon code, il faudrait que je sois certain que cela en vaut la chandelle ! (N'oublie pas que 993 boucles en plus à exécuter sur mon exemple, c'est beaucoup beaucoup plus !). Comme tu sembles, trés bien informé sur la façon dont VB fonctionne puisse que tu dis "il est surtout faussé par la manière dont VB compile les programmes" ; peux-tu me présenter une (ou des) preuve convainquante ! Car pour l'instant il n'y a que moi qui présente des preuves montrant sur quoi sont fondés mes propos...
JE rajoute qu'en lisant certains posts dans la rubrique sur "l'optimisation de code" de ce site, on obtient des conclusions dans l'ensemble assez similaire à ce que j'ai pu constater avec des petits tests (notamment pour les boucles, preuve que cela tient la route)... Alors prouve moi d'abord que j'ai tord, car je crois avoir suffissament argumenté auparavant pour montrer que prendre un type 'Long' ici, n'est pas justifié !
Us.
4 juin 2005 à 23:53
Pour le faire vraimen il faudrait que tu écrive une versionde ton programme avec des double et une autre avec des long et que tu les compare.
donnez des temps de calcul pour un test aussi primitif ne peut pas consituer un test réel (il est surtout faussé par la manière dont VB compile les programme)
4 juin 2005 à 23:48
Voici des petits tests que je viens de réaliser... Mes remarques sont dans les commentaires...
'== DUREE MESUREE : 2,46 à 2,68 secondes
'Double 8 octets> classement : 2ième
Sub test1()
temps = Timer
Dim S As Double
Do
S = S + 1
Loop While S < 10000000
MsgBox Timer - temps
End Sub
'== DUREE MESUREE : 2,17 à 2,35 secondes
'Long 4 octets> classement : 1er
Sub test2()
temps = Timer
Dim S As Long
Do
S = S + 1
Loop While S < 10000000
MsgBox Timer - temps
End Sub
'== DUREE MESUREE : 3,19 à 3,24 secondes
'Currency 8 octets> classement : 3ième
Sub test3()
temps = Timer
Dim S As Currency
Do
S = S + 1
Loop While S < 10000000
MsgBox Timer - temps
End Sub
'== DUREE MESUREE : 3,57 secondes
'Single 4 octets> classement : 4ième
Sub test4()
temps = Timer
Dim S As Single
Do
S = S + 1
Loop While S < 10000000
MsgBox Timer - temps
End Sub
J'ai répété de nombreuses fois les tests pour mesurer le temps d'exécution...
JE note surtout que le type 'Double' est à peine plus long que 'Long', soit seulement environ 14% plus long... donc ce n'est pas beaucoup beaucoup plus long !
Dans mon code, prendre le type 'Double' est justifié ! (Lire mon post du 02/06/2005 17:12:35)...
JE PERSISTE ET SIGNE :
A savoir, sur un exemple pour l'Addition, la boucle qui est le coeur même du calcul, donc à optimiser puisse que c'est cette boucle qui détermine principalement (et de loin) le temps, est codée de la façon suivante :
=
For t = lgmul - 13 To 1 Step -14
V1 = Mid(Nb1, t, 14)
V2 = Mid(Nb2, t, 14)
r = V1 + V2 + Ret
lr = Len(Str(r))
Ret IIf(lr 16, 1, 0)
Mid(Total, t - lr + 15, lr) = r
Next t
=
Si je passe en 'Long' au lieu de 'Double', je ne puis garder comme nombre qu'une longueur de 9 chiffres maximum. Par conséquent le code deviendrait :
=
For t = lgmul - 8 To 1 Step -9
V1 = Mid(Nb1, t, 9)
V2 = Mid(Nb2, t, 9)
r = V1 + V2 + Ret
lr = Len(Str(r))
Ret IIf(lr 11, 1, 0)
Mid(Total, t - lr + 9, lr) = r
Next t
=
Calculons le nombre de passages dans la boucle 't' pour un nombre de 25000 milles chiffres...
POUR les déclarations en 'Double':
La boucle 't' fera 1785 passages... Donc autant de découpage des nombres NB1 et NB2 et du test IIF, qui comme chacun le sait, sont des opérations trés longues, par rapport à des opérations arihmétiques...
Pour les déclarations en 'Long':
La boucle 't' fera 2777 passages...
Donc entre les deux possibilités, il y a 992 passages de différences, soit + 55,6% de passages en plus ! avec le type 'Long'...
Ici l'avantage du calcul avec le type 'Long' n'existe pas ! car la plus important c'est de réduire le nombre de passage dans la boucle ! qui manipule surtout des données non numériques !
La remarque d'utiliser le type 'long' serait peut-être justifiée si la boucle faisait du vrai calcul brute... mais cela n'est pas le cas ici...
Voilà !
Us.
4 juin 2005 à 22:13
4 juin 2005 à 22:08
Ah mince ? !
Tout ce qui est dit dans MSDN est trés différent de ce que je pense... IL me reste plus qu'à tester sur des petits exemples, et conclure ensuite... car je ne suis pas convaincu !
Par ailleurs, je ne comprends pas ton dernier propos ? As-tu un problème d'affichage ? (pas moi... mais je vais mettre plutôt un saut de ligne aprés la virgule...)
Amicalement,
Us.
2 juin 2005 à 21:57
"
Utilisez des variables de type Long et des valeurs mathématiques de type Integer :
Dans les opérations arithmétiques, évitez les variables Currency, Single, et Double. Utilisez des variables de type Long chaque fois que vous le pouvez, surtout dans des boucles. Comme le type Long est le type de donnée natif du processeur 32 bits, les opérations sont très rapides ; si vous ne pouvez pas utiliser des variables de type Long, les types de données Integer ou Byte sont alors le meilleur choix. ...
"
Voilà ce que je cherchais à dire... Le type long est un type natif des proces 32 bits... ;-) Désolé pour mon bafouillage de tout à l'heure!
Enjoy
(pourquoi selon-vous cette foutue page est-elle plus large que les autres??? Moi je sais... Parce qu'il faut mettre un espace dans cette ligne du commentaire :
AGN("6125348761253847152834512873,6582736459293843847659276","-1273649871263948612372364900.65293874659283465983267435")
Après les virgules par exemple!!!).
2 juin 2005 à 18:46
Ah !! aussi autre nuance... Quand j'ai écris : "Il est à noter que pour le PC manipuler un nombre de 15 chiffres au lieu de 1 chiffre, ne lui demande pas plus de temps de calcul..." . Je voulais souligner le fait que si on utilise une variable (quel que soit le type), en quelque sorte, "remplie" avec une petite valeur comme par exemple 9, avec laquelle on fait une opération, le temps pour réaliser cette opération, n'est pas plus significativement long, que si cette variable était "remplie" avec une grande valeur. (bien sur, dans sa plage limite.)...
=
Pour les histoires de déclaration, je suis certain (après avoir souvent testé) qu'il y a une différence, souvent non négligeable lorsqu'on calcul en boucle...
JE ne sais pas exactement ce que dit Microsoft, mais (de mémoire) avec des tests sur la durée en fonction des déclarations des variables, donnent le même classement qu'avec leurs longueurs en octets...
Par exemple, le Integer ou Boolean sont des variables codée sur 2 octets. Le temps de leurs manipulations est identique... En définitive, si je classe les variables, je choisi en fonction de mes besoins de la façon suivante :
Byte : 1 octet : Valeur => 0 à 255
Boolean : 2 octets : Valeur => Vrai(=-1) ou Faux (=0)
Integer : 2 octets : Valeur => -32768 à 32767
Long : 4 octets : Valeur => -2147483648 à 2147483647
Single : 4 octets : Valeur => +/- 1,4E45
Cuurency : 8 octets : Valeur => +/- 922337203685477,5808
Double : 8 octets : Valeur entière => +/- 10^15 : Valeur scientifique : +/- 4,94E324
Voilà, c'est un peu théorique, puisse qu'il existe d'autres considérations à prendre en compte pour le choix comme je l'ai dis tout à l'heure. Néanmoins, c'est comme cela que je résonne... A tord ?
A+
Us.
2 juin 2005 à 17:24
Ceci dit, je pense que la remarque de Dnob faisait référence aux recommandations de Ms qui précise que la routine de déclaration des variables inférieurs à Long sont gérés par la routine de long... ou un truc du genre!!! En fait, il n'est pas avantageux, au niveau de la vitesse, de déclarer (et donc, d'utiliser) une variable en tant que Integer, Byte ou Boolean (si ce n'est pour leur taille) car la routine devra même faire plus d'opérations que pour Long pour faire les changements (puisque c'est la même)...
Bon, vous me dites si je dis une connerie là parce que je dis ça de tête... pi comme je sais pas exactement comment le VB gère tout ça en interne... Pardonnez-moi mon inexactitude sur ce coup!!!
Je suis certain que BruNews saurait nous exliquer tout ça mieux que je ne le saurais jamais!!!
En tous les cas, faut pas oublier qu'on peut aussi utiliser tout ce qui est en dessous de 0 dans certains types... ça peut être pratique ;-)
2 juin 2005 à 17:12
Mais bon... ta remarque est intéressante. J'avoue que je n'ai pas essayé avec le type Long, car cela me semble d'entrer de jeu plus long...
Pour que cela soit plus rapide avec des 'Long', il faudrait déjà que le calcul soit au moins deux fois plus court qu'avec des 'Double' ; (sinon il n'y a pas de gain, élémentaire !)
... mais surtout (très important !), il faut que le calcul soit aussi encore plus rapide puisse qu'on multiplie le nombre de passage dans la boucle... (puisse qu'on prend moins de chiffre)... Ce qui est absolument non négligeable, puisse dans cette boucle sont associés d'autres opérations indispensables au calcul...
C'est la raison pour laquelle que j'ai directement opté pour le type 'Double' pour l'optimisation afin de réduire le plus possible le nombre de manipulations...
Maintenant, il reste à vérifier effectivement... mais j'ai pas beaucoup de doute sur le meilleur choix...
Prochainement je ferais part du test avec 'long'...
Amicalement,
Us.
1 juin 2005 à 16:47
bah si, ça lui prend beaucoup beaucoup plus de temps, car les calcul avec les double se font dans le coprocesseur arithmétique et ça dure assez longtemps.
Essaye de réécrire ton code en replacant les double par des long (et en te limitant donc à 9 chiffres je pense) et ça devrait aller beaucoup plus vite (si VB est capable d'optimiser ça bien, je n'en suis pas sur non plus).
23 mai 2005 à 23:16
Toutefois, il est toujours possible de mettre en surbrillance et faire un copier/coller...
Us.
23 mai 2005 à 03:45
A part ça, cool, très classe !
Manque plus que les multiplications, divisions, carrés et racines et on pourra enfin en faire un contrôl ActiveX ;-)
Enjoy