ÉTUDE SUR LES BOUCLES (DO LOOP, WHILE, UNTIL)

Commentaire de DeadlyPredator le 07/09/2004 05:07:38

OUPS, UNE TERRIBLE ERREUR C'EST GLISSÉE. Dans la section sur ou placer la condition dans la boucle, les résultats ont été intervertis. Cette erreur à été corrigée.

Commentaire de man15372 le 07/09/2004 13:20:38

Vraiment n'importe quoi.
Désolé mais mais comment peut tu être aussi affirmatif avec des résultat qui quoi que lancer successivement dans le même code, ne peuvent en aucun cas être comparé.
Je m'explique :
Commen peut tu être certain que ton processeur n'est pas utilisé par une appli ou un service est entre deux.
Non mais franchement, ce genre de test au résultat foireux , tu peut l'exécuter autant de fois que tu voudras tu n'obtiendra jamais les même résultat.
Et dans le meilleur des cas tu n'a qu'a inverser l'ordre de tes comparaisons et là, tout tombe à l'eau.
Désolé mais cela n'apporte pas d'eau au moulin VB.

Commentaire de MadLucas le 08/09/2004 01:48:14

Conseil:

Fait rouler ton code dans une boucle pendant une nuit et tire une conclusion à partir d'une moyenne.  PLus tu as de résultats dans ton calcul moyen, plus tu te rapprocheras de la réalité.

Autre truc...  Compile et observe le code assembleur avec un debugger..  la plupart du temps, on peut connaître la vrai performance d'une boucle en comparant son code compilé.

Et finalement, tu dois faire ton test sur une application compilé et non et interprétation (Run) ..  Seul le .exe est valable.

MadLucas

Commentaire de azerty25 le 08/09/2004 12:27:43

man15372 : tu crois que le gens, entreprises, magazines, etc vont se faire chier à enlever une par une les résistances,  condensateurs, puces et j'en passe qui gère par exemple le son pour faire un test d'une carte graphique sous prétexte qu'ils en ont pas besoin ? Je crois pas, ici c'est pareil, du moment que la configuration d'un test à l'autre, programme éxécuté et j'en passe ne change pas, les tests sont valables, c'est pas la comparaisons de 2PCs qui nous intéresse ici mais celle de code sur le même PC, c'est donc tout à fait valable.

Commentaire de fkx le 08/09/2004 13:14:22

Dites, tous les gens, là...
Vous savez que, en ASM du moins, la boucle la plus rapide est le FOR ?
Moi, je serais d'avis qu'on compare au moins une fois les performances d'un FOR.
C'est d'ailleurs ce que j'ai fait pour vous (mais aussi pour moi).

J'ai réalisé ce test avec lngDuree = 1000000000 (1 milliard) sur un Windows 2003 Server avec un bi-processeur 2x2,8GHz (bah, désolé mais j'avais pas moins puissant sous la main, alors...)
Séquence 1 :
    lngLastMesure = GetTickCount
    Do
        I = I + 1
    Loop Until I = lngDuree
    MsgBox GetTickCount - lngLastMesure

Séquence 2 :
    lngLastMesure = GetTickCount
    For I = 1 To lngDuree
    Next
    MsgBox GetTickCount - lngLastMesure

Et maintenant.............
LE résultat :
          1094ms pour le Do...Loop (résultat assez stable)
          1500ms pour le For...Next (résultat fluctuant)

Ma conclusion :
VB n'a pas l'air très doué en optimisation de rapidité...
Je pensais honnêtement que le for serait le plus radide. Quelle ne fut pas ma déception...

En espérant que ce petit test soit profitable à tout le monde, je souhaite à tout le monde "Bonne Prog !"

        FKX

Commentaire de EBArtSoft le 08/09/2004 13:33:05 administrateur CS

Tient je savais pas qu'en ASM il existait
une instruction FOR ?

@+

PS : personne n'a montré de teste utilisant le GOTO
j'aimerais bien voir le bench [;)]

Commentaire de MadLucas le 08/09/2004 15:29:26

héhé,  Salut EBartSoft...

En effet, le FOR c'est du haut niveau..  je crois que Monsieur voulait dire plutôt "le code ASM généré par un FOR en VB".

Pour le GOTO, j'ai déjà testé.  J'ai pas les chiffres, mais en gros, le GOTO est remplacé par un JUMP en ASM et c'est le plus rapide selon moi.  Le vrai problème avec le GOTO dans le code source c'est qu'il n'a pas de structure logique et qu'il renvois n'importe où dans le code.  C'est "anti-OO" et c'est un manque dans un bon design.  Cependant, je suis d'avis qu'un GOTO bien placé dans une même fonction et qui réfère à une étiquette (et non un numéro de ligne) peut optimiser, voir même faciliter un code.  Mais bon, c'est de dernier recours car le GOTO est vide de sens et ne sert souvent que son concepteur.

De plus, il n'existe aucune situation où le GOTO est indispensable et il peut facilement être remplacé par un code mieux structuré qui facilitera la conceptualisation "OO".


MadLucas

Commentaire de man15372 le 08/09/2004 18:42:01

Pour répondre à azerty25,
Quand tu veut comparer deux choses il faut que ces deux choses soit dans les même conditions.
Donc avec les même éléments perturbateurs.
Et donc pour être sur que les deux parties de ce test soient jouées dans les mêmes conditions et à défaut de pouvoir être certain que rien ne viennent perturber soit l'un soit l'autre, la seule solution c'est de revenir à un état le plus proche du neutre (cf les solutions que j'ai déja énuméré plus haut).

Petite comparaison bien qu'un peu eloignée :
Irai tu à comparer la tenue de route d'un véhicule (A) sur autoroute par temps sec, avec 0 % de vent,etc...
avec un autre véhicule (B)  qui lui roule lui aussi sur cette même route mais par temps pluvieux avec un fort vent latéral.

Soit:
Véhicule (A): Code partie 1
Véhicule (B): Code partie 2
Pluie du véhicule (B): Process ou services consommateur de CPU
Vent latéral du véhicule (C): Idem

Donc SVP messieurs lors de tests de comparaisons quels qu'ils soient, essayer de mettre ces deux éléments le plus possible dans les même conditions avant d'annoncer quelques résultats que ce soit.

Par avance merci.

Commentaire de MadLucas le 08/09/2004 19:25:23

Salut Huugooo,

Tu dit:

"... Vous saviez qu'une boucle For est plus rapide avec un Integer qu'avec un Byte (sisi essaie donc avec 5 boucles imbriquées de 0 à 255) alors qu'un byte prend moins de place en mémoire ? Va savoir pourquoi... "

Et bien la réponse est la suivante, le processeur calcul avec des LONG, et les integer de VB sont des modèles SHORT plus proche du LONG que peut être un BYTE.

Lorsque tu utilises un BYTE, le processeur doit le reconvertir en LONG pour faire la boucle, ce qui est un tantinet plus long.

Fait ce test, utilise un LONG à la place du INTEGER.  Dans la plupart des cas, le LONG va être soit équivalent, soit plus performant..  Et en plus, il sera beaucoup plus stable que le INTEGER car il n'a pas besoin d'être converti.



MadLucas

Commentaire de bouv le 08/09/2004 20:19:14

Huugooo >> Voici un extrait de la MSDN.

Type de donnée numérique           Vitesse

Long                                               La plus rapide
Integer  
Byte  
Single  
Double  
Currency                                         La plus lente


Par contre 255 * 255 = 65 025 alors que le type Long prend jusqu'a 2 147 483 647. Donc la je vois pas j'ai fais le test avec d'autres types et toujours pareil. Si qq1 a une explication.

Enfin, voici un autre extrait de la MSDN concernant les boucles :


La possibilité de définir et d'utiliser des collections d'objets est un des points forts de Visual Basic. Les collections sont très utiles mais vous devez les utiliser à bon escient pour obtenir les meilleures performances :

Utilisez l'instruction For Each...Next, plutôt que l'instruction For...Next.

Évitez d'utiliser les arguments Before et After lorsque vous ajoutez des objets à une collection.

Utilisez des collections à clés plutôt que des tableaux, pour des groupes d'objets du même type.


Les collections permettent d'itérer sur elles-mêmes à l'aide d'une boucle entière For...Next. Toutefois, la structure For Each...Next est plus lisible et, dans beaucoup de cas, plus rapide. Comme l'itération For Each...Next est mise en ½uvre par le créateur de la collection, la vitesse réelle varie d'un objet de collection à l'autre. Cependant cette itération est rarement plus lente que l'itération For...Next car la mise en ½uvre la plus simple est une itération For...Next de style linéaire. Dans certains cas, comme le créateur de la collection peut utiliser une mise en ½uvre plus complexe qu'une itération linéaire, l'instruction For Each...Next peut s'avérer beaucoup plus rapide.

La page est assez longue mais interressante, tapez "optimisation du code" dans la case rechercher et vous aurez tout.

Bonne prog
++

Commentaire de bouv le 08/09/2004 20:30:24

ouaip, je viens de m'en rendre compte j'ai survolé ça bcp trop vite desolé.

Oh mais j'y pense, un projet est fourni avec la MSDN qui permet de tester differente methode d'arriver au meme resultat et compare les vitesses necessaires.
Je pourrai faire un autre post mais si tu (DeadlyPredator) me donne ton mail je peux te l'envoyer pour que tu l'ajoute et qu'il complete ta source, cela pourrai etre interressant.

Voila ++

Commentaire de philheiz le 08/09/2004 21:42:58

Très bien cette discussion !
Une question: en règle générale, est il mieux de déclarer i as Long ou as Integer ?

En ce qui me concerne je déclare systématiquement as Long, mais je suis toujours étonné de voir que MS déclare la plupart des entiers comme Integer (typiquement dans la procédure event d'un array de controles, Index est toujours un Integer).

Commentaire de MadLucas le 08/09/2004 22:28:03

Bonjour Philheiz,

Je te suggère d'utiliser le type LONG pour les raisons suivantes:


- Les LONG sont plus stable que les INTEGER.  Par exemple, dans une boucle de test, GetThickCount renvois la même valeur à chaque fois avec un LONG mais change de valeur avec un INTEGER.

- Les types LONG peuvent plus facilement être utilisés avec des appels API.  Attention, les LONG doivent être changés par des INTEGER dans VB7 avec les appels API.

- Les BYTES, INTEGERS, BOOL utilisent moins de mémoire.  Cependant, Win32 est 32bits et le type LONG est forcément plus rapide.  Si tu utilises un INTEGER, Win32 doit le reconvertir pour le traiter.

Mais bon, les différences sont vraiement très minime entre un INTEGER et un LONG.  De changer les types INTEGER pour LONG ne va pas optimiser pour la peine la vitesse de l'application.  Cependant, de déclarer des INTEGER à la place des LONG quand c'est possible résuit de moitié la mémoire nécessaire.  Donc, "stick with the INTEGER" en VB6 quand c'est possible, l'optimisation mémoire ici donnera de meilleurs résultats que l'optimisation "vitesse" avec le LONG.



MadLucas

Commentaire de fkx le 09/09/2004 13:03:18

EBArtSoft :

Effectivement, la boucle FOR n'existe PAS en ASM
(Merci MadLucas, tu as tout à fait compris ce que je voulais dire !)

Pour plus de détails, une boucle for est codée comme suit en ASM :

     mov ECX, <nb itérations> // Initialisation du compteur

     debut:                              // étiquette de début deboucle
     // traitement(s)
     loop debut                       // boucle jusqu'à ce que ECX = 0

Ce qui est plus rapide que

     mov ECX, <nb itérations>
     debut:
     // traitement(s)
     dec CX
     cmp CX, 0
     jnz debut

...qui est une implémentation possible pour
i=<nb itérations>
Do
    ' Traitements
Loop Until i=0

(Remarque : VB ne le fait surement pas comme ça...)

Voilà... j'espère que cette petite explication sera profitable à un maximum de personnes.
Bonne prog à tous !

Commentaire de fkx le 09/09/2004 15:21:13

Certes, mon cher EBArtSoft, certes...
Mais si tu mets une valeur en dur dans ECX, il faudrait être idiot pour mettre 0... avoue-le !
Par contre, si tu récupères une valeur quelquonque (par exemple dans un registre ou dans la pile, ou même ailleurs), tu peux effectivement tester cette valeur.
Merci quand même de la remarque !

Commentaire de EBArtSoft le 09/09/2004 16:12:52 administrateur CS

fkx> par idiotie ou par etourderie le resultat serais desastreux ;)

Bon comme tout le monde y va de son petit test voici le mien :

'---------------------------------------
' Pour le code suivant :
'---------------------------------------

    Dim i As Long
    i = 10
Label1:
    Call Test  'Fonction contenant un doevents
    i = i - 1
    If i Then GoTo Label1

'--------------------------------
' Voici le code asm :
'--------------------------------

  00040 e8 00 00 00 00 call Test
  00045 be 09 00 00 00 mov esi, 9
$L25:
  0004a e8 00 00 00 00 call Test
  0004f 4e dec esi
  00050 75 f8 jne SHORT $L25

Le compilo a même abregé mes souffrances en ajouant un premier appel a "Test" avant de faire la boucle il est sympa non ? Bon aller treve de plaisanteries on a tout de même plein de projets en attente.

Pour le resultat : no comment

@+

Commentaire de BruNews le 10/09/2004 11:16:18 administrateur CS

DEC modifie bien eflags, on peut donc effectuer le test de saut illico derriere.

Commentaire de BruNews le 10/09/2004 11:50:19 administrateur CS

Il est sorti un petit bouquin "Assembleur x86" chez CampusPress par Jean-Bernard Emond qu'on trouve a 9.50 euros. Il couvre toutes les instructions jusqu'au P4, a ce prix et en format poche, c'est vraiment tres bien.

Commentaire de EBArtSoft le 10/09/2004 12:40:20 administrateur CS

BruNews> La vache je l'ai eu pour 10¤ je me suis faire arnaquer ! ;) Excelent livre je confirme.

@+