Discussion :

[electroremy]

Bonjour,

VB.NET propose différentes façon de faire les choses... qu'est-ce qui est le plus rapide ?

J'ai fait un benchmark maison et les résultats sont très instructifs.

J'ai ensuite optimisé quelques uns de mes programmes (déjà optimisés du point de vue algo et mathématiques) qui se sont alors montrés entre 5 et 25 fois plus rapide ... c'est super mais ça veut dire aussi qu'avant je codais en VB.NET comme une merde

Mon programme de benchmark est ici en pièce jointe avec le code source : VB-NET-BENCH.zip

Qu'en pensez-vous ? Avez-vous des autres idées de fonction VB à tester ?

Voici le résultat du benchmark :

NB : les tests ont été réalisés avec le fichier .EXE release ; dans le projet Option Explicit est à ON et Option Strict est à ON également

=== VERIF CHAINE NULLE ===
Nombre de tests : 30.000.000
106ms : If s <> ""
158ms : If s <> vbNullString
24ms : If len(s) <> 0
33ms : If Not String.IsNullOrEmpty(s)
16ms : If s.Length <> 0

=== CRÉATION CHAINE NULLE ===
Nombre de tests : 60.000.000
47ms : s = ""
33ms : s = vbNullString
33ms : s = String.Empty

=== CONCATENATION CHAINE ===
Nombre de tests : 50.000
442ms : s1 = s1 & "a"
426ms : s1 &= "a"
0ms : s2.Append("a") : s1 = s2.ToString
Nombre de tests : 5.000
0ms : s2.Append("a" & "b" & "c" & "d" & "e" & "f" & "g" & "h" & "i" & "j") : s1 = s2.ToString

=== COMPARAISON CHAINE avec s1 = s2 ===
Nombre de tests : 2.000.000
11ms : s1 = s2
184ms : String.Compare(s1, s2) = 0
5ms : String.CompareOrdinal(s1, s2) = 0
4ms : String.Equals(s1, s2)

=== COMPARAISON CHAINE avec s1 <> s2 ; len(s1) = len(s2) ===
Nombre de tests : 2.000.000
50ms : s1 = s2
174ms : String.Compare(s1, s2) = 0
18ms : String.CompareOrdinal(s1, s2) = 0
13ms : String.Equals(s1, s2)

=== COMPARAISON CHAINE avec s1 <> s2 ; len(s1) <> len(s2) ===
Nombre de tests : 2.000.000
41ms : s1 = s2
178ms : String.Compare(s1, s2) = 0
17ms : String.CompareOrdinal(s1, s2) = 0
4ms : String.Equals(s1, s2)

=== COMPARAISON CHAINE IGNORER CASSE avec s1 = s2 ===
Nombre de tests : 2.000.000
445ms : UCase(s1) = UCase(s2)
416ms : s1.ToUpper = s2.ToUpper
225ms : UCase(s1) = s2
181ms : String.Compare(s1, s2, True) = 0
6ms : String.Equals(s1, s2, StringComparison.OrdinalIgnoreCase)

=== COMPARAISON CHAINE IGNORER CASSE avec s1 <> s2 ; len(s1) = len(s2) ===
Nombre de tests : 2.000.000
454ms : UCase(s1) = UCase(s2)
417ms : s1.ToUpper = s2.ToUpper
224ms : UCase(s1) = s2
175ms : String.Compare(s1, s2, True) = 0
65ms : String.Equals(s1, s2, StringComparison.OrdinalIgnoreCase)

=== COMPARAISON CHAINE IGNORER CASSE avec s1 <> s2 ; len(s1) <> len(s2) ===
Nombre de tests : 2.000.000
455ms : UCase(s1) = UCase(s2)
420ms : s1.ToUpper = s2.ToUpper
224ms : UCase(s1) = s2
183ms : String.Compare(s1, s2, True) = 0
8ms : String.Equals(s1, s2, StringComparison.OrdinalIgnoreCase)

=== APPELS BYVAL BYREF - VALEURS DANS CALL ===
Nombre de tests : 100.000.000
78ms : Call Sub1(A As Integer, B As Double, C As String)
55ms : Call Sub2(ByVal A As Integer, ByVal B As Double, ByVal C As String)
55ms : Call Sub3(ByRef A As Integer, ByRef B As Double, ByRef C As String)
55ms : Call Sub4(ByVal A As Integer, ByVal B As Double, ByRef C As String)

=== APPELS BYVAL BYREF - VARIABLES ===
Nombre de tests : 100.000.000
70ms : Call Sub1(A As Integer, B As Double, C As String)
55ms : Call Sub2(ByVal A As Integer, ByVal B As Double, ByVal C As String)
55ms : Call Sub3(ByRef A As Integer, ByRef B As Double, ByRef C As String)
55ms : Call Sub4(ByVal A As Integer, ByVal B As Double, ByRef C As String)

=== COLLECTION VS LIST(OF ) / FOR EACH ===
Nombre de tests : 1.000.000
213ms : Collection - Construction et For Each
94ms : List(Of ) - Construction et For Each

=== COLLECTION VS LIST(OF ) / .ITEM(I) ===
Nombre de tests : 10.000
200ms : Collection - Construction et For i
0ms : List(Of ) - Construction et For i

=== LIST(OF ) : FOR EACH / FOR I .ITEM(I) ===
Nombre de tests : 10.000.000
58ms : For Each
15ms : For i

=== OPÉRATEURS += ===
Nombre de tests : 50.000.000
56ms : x = x + 1
41ms : x += 1

=== OPÉRATEURS -= ===
Nombre de tests : 50.000.000
62ms : x = x - 1
41ms : x -= 1

=== OPÉRATEURS *= ===
Nombre de tests : 50.000.000
72ms : x = x * 3
55ms : x *= 3

=== OPÉRATEURS /= ===
Nombre de tests : 50.000.000
45ms : x = x / 3
29ms : x /= 3

=== / CTE VS * CTE ===
Nombre de tests : 100.000.000
72ms : z = x / 2
55ms : z = x * 0.5

=== / VAR VS * VAR ===
Nombre de tests : 100.000.000
78ms : z = x / y
54ms : z = x * y

=== / VAR VS * VAR II ===
Nombre de tests : 10.000.000
208ms : zi = xi / y avec y = i
61ms : zi = xi * y avec y = 1/i

=== FONCTIONS MATHÉMATIQUES ===
Nombre de tests : 80.000.000
15ms : +
15ms : -
10ms : *
112ms : /
100ms : SQRT
528ms : SIN
624ms : COS
776ms : TAN
476ms : LOG
416ms : ASIN
452ms : ACOS
872ms : ATAN

A +

[Pol63]

il faut en effet tester différentes manières de faire quelque chose quand on a besoin de performances
le stringbuilder est connu pour la concaténation

après les temps donnés ne sont pas fixes, quand on essaye plusieurs fois quelque chose le temps change
et x = x + 1 et x += 1 n'ont aucune raison d'être différent en performance, étant compilés de la même manière (enfin l'inverse serait étonnant)
(parfois l'un est plus rapide que l'autre, parfois l'inverse)
donc quand les temps sont proches on ne peut pas forcément en déduire une différence de performance

le mieux pour faire des comparaisons et une moyenne sur plusieurs (beaucoup ?) essais (sans forcément compter le 1er, qui peut contenir le temps de compilation)

[Graffito]

Quand on recherche la performance, on a parois intérêt à remplacer une procédure système de haut niveau par des procédures maison.

Récément pour améliorer les performances d'une lecture de fichier binaire d'entiers, j'ai remplacé le BinaryReader par des ReadBytes suivis de recomposition des entiers depuis les octets lus ==> performance plus que doublée.

Edit: As-tu compilé en version "Debug" ou en "Release" ?

[sevyc64]

Moi, perso, là en première lecture, il y a 2 points qui m'interpellent

- les appels de fonctions : Je ne comprend pas la différence de temps entre les call sub1 et call sub2, les 2 étant strictement identique (les byval sont implicite dans le call sub1, le compilateur agit comme s'ils y étaient)
- le second point c'est les temps à 200 voire 400ms sur des instructions pour tant relativement simples

Quoiqu'il y aurait aussi à débattre sur le fait de continuer à utiliser des instructions VB6 en .Net tel que les vbNullString ou UCase
Tu dis

dans le projet Option Explicit est à ON et Option Strict est à ON également

et moi je rajoute dans tous mes projets, et impose dans les projets que je gère Interdiction d'utiliser la librairie Microsoft.VisualBasic

[Pol63]

Quoiqu'il y aurait aussi à débattre sur le fait de continuer à utiliser des instructions VB6 en .Net tel que les vbNullString ou UCase

déjà dit mais les 3/4 des fonctions héritées de vb6 sont soit des instructions du langage soit utilisent les fonctions du framework (dixit code source), ce ne sont alors que des raccourcis, donc rien de mal à ca je pense

[Sehnsucht]

Note: je n'ai pas regardé le code (flemme de télécharger + ouvrir un zip on va dire )

Pour moi l'intérêt d'un tel bench est relative quand on voit par exemple un écart de 20ms sur 50000000 de tests soit 4e-7ms par test en moyenne ou 80000000 d'Atan qui prenne 872ms soit 1.09e-5ms par Atan je me demande ce qu'on veut vraiment gagner par cette approche.

Surtout que certains tests me paraissent biaisé en amont, par exemple pour s2.Append("a" & "b" & "c" & "d" & "e" & "f" & "g" & "h" & "i" & "j") il y a de fortes chances que le compilo (ou le JIT) concatène ces littéraux en amont de l'exécution réelle du code. De même qu'il faudrait vérifier le code généré (voire le code JITté ou encore le résultat d'un NGEN) vérifier si la mesure n'est pas perturbée par autre chose (venant du système) si l'on a bien lancé une fois chaque tests sans mesure (pour laisser le JIT faire son boulot lors de la première exécution) ...

Après il y a encore d'autres choses qui peuvent jouer, si on désactive la gestion des overflows sur les opérations numériques ça aura vraisemblablement un impact par exemple.

Mais surtout il n'y a pas que la vitesse que l'on peut chercher à optimiser, il y a la mémoire (la "pression" sur le GC notamment), la bande-passante, les accès (réseaux, fichier etc.) bref tout ça pour dire que l'optimisation ça se fait après détection d'un réel problème (ralentissement, latence) dans une section de code critique (parce vouloir gagner 100ms sur de l'UI ça sert à rien) analyse de cette section, profilage, etc. et une fois qu'on a trouvé le où et le pourquoi on peut envisager quelles solutions s'offrent à nous, là, pour moi, c'est un peu mettre la charrue avant les boeufs.

Quant au sujet des "méthodes VB6" c'est certes un sujet maintes fois abordé, et je suis à cheval entre sevyc64 et Pol63 (je devrais peut-être ajouter un 63.5 à la fin de mon pseudo ) je n'ai rien contre ce sont des méthodes .Net (et certaines ont même des recommandations dans la MSDN [des articles qui commencent à dater, je le concède] parce que faisant des vérifications avant d'appeler les méthodes .Net classique ; elles peuvent court-circuiter l'exécution et se révéler plus performantes et/ou plus propices à être optimisées par le JIT (mais je dirais qu'on s'en fiche surtout parce que c'est que quand on a décelé un problème qu'on en cherche la cause comme dit précédemment).
Le seul, cas où je rejoins sevyc64 c'est par rapport à l'approche pour les débutants qui ont tendance à en abuser (croyant souvent qu'il s'agit de fonctions libres) et perdent ainsi de vue (ou s'éloignent avant même d'y entrer) la conception orientée objets.
De toute façon, souvent, même sans le savoir on utilise cet espace de nom (du moins sa partie "CompilerServices") par exemple lorsque l'on fait If chaine1 = chaine2 Then

[DonQuiche]

J'ai fait un benchmark maison et les résultats sont très instructifs.

A mes yeux les résultats sont surtout très prévisibles.

Par exemple il n'est pas étonnant que vérifier la longueur de la chaîne (un champ à lire) soit plus rapide que comparer un à un deux chaînes de caractères (au moins deux champs à lire avec une chaîne vide, peut-être quatre ou six, avec en plus une comparaison par référence au début). Du coup il serait peut-être davantage bénéfique pour toi d'examiner les sources de la bibliothèque dotnet ou d'approfondir tes connaissances sur la façon dont ces langages sont exécutés par le processeur. Voire de faire un peu d'assembleur, d'autant que c'est amusant.


Au passage choisir entre multiplication et division est rarement significatif. Dans des programmes réels cela peut même ne faire aucune différence. Si tu veux vraiment optimiser tu as trois pistes :
* Utiliser de meilleurs algorithmes et structures de données. En particulier chercher un moyen pour faire moins de traitements (calculs incrémentaux, mémoisation, etc).

* Optimiser l'agencement de la mémoire. En effet les programmes sont bien souvent dominés par les temps d'accès à la mémoire car durant le temps qu'il faut pour lire une seule ligne depuis la RAM (64 octets - 16 Int32) le CPU peut exécuter 400 additions ! Une part essentielle de l'optimisation consiste donc à organiser tes données en mémoire de telle façon que tout tienne en cache et que les accès soient séquentiels. Pour cela tu peux remplacer tes classes par des structures dans un tableau, scinder certains types en plusieurs autres selon le moment où chaque donnée est utilisée (par exemple les jeux séparent les composantes des sommets en plusieurs tableaux : un tableau pour les positions, un tableau pour les normales, un tableau pour les coordonnées textures, etc), t'efforcer d'avoir un code séquentiel (donc pas d'appel virtuel), etc. Un billet sur le sujet et un site plus poussé.

* La parallélisation. Aujourd'hui les CPU ont six à huit coeurs, demain ce seront douze à seize, puis encore davantage. Se pencher sur des micro-optimisations tout en n'utilisant qu'un seul thread serait absurde. Et le calcul sur GPU est aussi une très bonne piste pour les problèmes qui s'y prêtent (y compris ceux qui ne s'y prêtent pas parfaitement ! Les GPU ne sont plus aussi manchots avec les branchements conditionnels).


Ces pistes peuvent te permettre de réduire très significativement les temps d'exécution. Bien plus que ton approche (sans doute fausse par ailleurs, voir ci-dessous).

Je mesure le temps avec monStopWatch.ElapsedMilliseconds ; donc c'est pas bon ?

C'est le bon choix. Par contre as-tu pensé à faire un "tour de chauffe" (warm-up) ? C'est à dire à exécuter une première fois le code avant de lancer le benhcmark, pour être sûr que le JIT a déjà compilé cette méthode ? Ça expliquerait certains résultats étranges où la première mesure est toujours un peu plus longue qu'elle ne le devrait, sans doute parce qu'elle inclut la durée de la compilation JIT.

oui c’est pour ça que j’ai fait ce bench, car les applis sur lequels je bosse possèdent des fonctions gourmandes en calcul

Le message très important qu'il a cherché à te faire passer c'est qu'on n'optimise pas une application en saupoudrant quelques astuces un peu partout. On l'optimise en identifiant d'abord très précisément les parties qui sont lentes et quelles opérations sont en cause. Une fois que c'est fait tu t'attaques à ce point précis.

En somme : utilise un profileur.

- les appels de fonctions : Je ne comprend pas la différence de temps entre les call sub1 et call sub2, les 2 étant strictement identique (les byval sont implicite dans le call sub1, le compilateur agit comme s'ils y étaient)
- le second point c'est les temps à 200 voire 400ms sur des instructions pour tant relativement simples

a) Je parie sur l'absence de tour de chauffe, comme je viens de l'expliquer juste au-dessus.

b) Ces temps sont évidemment pour des itérations très nombreuses. En pratique une division ne prend environ qu'une nanoseconde de nos jours, et un appel de méthode quelques nanosecondes. En-dessous de la centaine de millions d'instructions par seconde ton CPU bronche à peine. Et tu peux aller bien au-delà.

Bon, oui, en gardant à l'esprit que la mesure a une marge d'erreur de +/-20ms
(18,2ms pour être exact mais même Microsoft communique de moins en moins sur l'exactitude de cette valeur et indique souvant 20ms environ)

C'est un peu comme les sondages d'élections, un tel est devant avec 0.2% d'avance mais 0,2% à +/-0,5.

15,6 ms en fait (1/60ème de seconde) mais ce n'est que la valeur par défaut. Il est possible de démarrer windows en réclamant une horloge plus précise et, par ailleurs, dès lors qu'une application dans le système instancie un timer multimédia l'horloge du système passe, il me semble, à 100µs, ce qui affecte toutes les applications. Ce qui explique que certains jeux soient soudains plus fluides en ouvrant un lecteur vidéo en arrière-plan.

La plupart des logiciels même les plus gourmands ne savent que faire de toute la débauche de puissance de nos machines actuelles.

Ah ça non !

Que tu dises que la plupart des logiciels n'ont plus besoin d'optimiser, oui, tout à fait. Mais crois bien que nombre d'applications adoreraient avoir des CPU cent fois plus puissants. Et à ce niveau ce serait encore loin d'être une débauche de puissance dont on ne saurait que faire ! Outils de développement (compilateurs "intelligents"), reconnaissance, minage et synthèse, raytracing et physique pour le JV, et bien d'autres encore.

La stagnation de la puissance CPU et la lenteur de la parallélisation sont de gros problèmes et cela va être une belle opportunité pour certains services dans le nuage qui pourront offrir des prestations qu'aucune machine cliente ne pourra offrir. Et j'ajoute que pour produire des logiciels toujours plus complexes à main d’œuvre constante il faudra avoir des abstractions de plus en plus hautes et gourmandes. Pendant ce temps la puissance séquentielle des CPU stagne ou presque depuis dix ans. A vrai dire je pense que nous aurons besoin de langages plus expressifs et mieux optimisables.

Pour ce qui est des langages, pour de l'optimisation extrême, il n'y en a qu'un seul qui le permet vraiment, c'est l'assembleur. Le C, étant très bas niveau, permet aussi de s'en rapprocher sérieusement.

Non, on n'optimise pas en écrivant son programme en assembleur ! Pas en 2015. On optimise en utilisant des algorithmes plus complexes mais optimaux, en réagençant ses données, en parallélisant, etc. Si tu places trois boucles vectorielles en assembleur ce sera déjà bien et ça ne fera pas une grande différence - sauf exception.

L'optimisation que l'on peut faire, n'est pas de l'optimisation, mais de la bonne pratique de codage pour éviter d'embrouiller le compilateur et lui faciliter la tache parce qu'on final c'est lui qui optimise et pas le développeur.

Le compilateur dotnet est optimisé pour une compilation rapide et n'optimisera que bien peu ton programme. Tu ne peux pas t'appuyer sur lui. Les compilateurs C/C++ sont quant à eux excellents mais ils opèrent toujours à bas niveau. Ils ne procèderont pas à des changements de haut niveau de l'agencement du code et de ses structures, ne changeront pas ton algorithme, ne paralléliseront pas, etc. Cela demanderait une intelligence du code très basée soit sur une compréhension du domaine métier, soit sur une instrumentation très fine des binaires (profile-guided optimization puissance 10) accompagnée d'une perte de contrôle du développeur.

[Pol63]

on peut surtout se dire que le compilateur n'est vraiment pas intelligent
car je ne comprends pas qu'un .length = 0 soit énormément plus rapide qu'un = ""
quand on teste l'existence de 2 chaines il devrait déjà vérifier si la longueur est la même

c'est un langage d'assez haut niveau, ca serait dommage de devoir perdre du temps sur des choses si simples

x += 1 et les fonctions similaires sont toutes plus rapides que leur version x = x + 1 ; elles ne sont donc pas codées pareil lors de la compilation

sur vs 2015 preview je n'ai aucune différence de temps entre les 2 syntaxes

[Sehnsucht]

le = prend (peut prendre serait plus correct) en compte la culture ; ça serait surtout une erreur de croire que 2 chaines de longueurs différentes sont forcément différentes. Par exemple le "ß" allemand est égal à un "ss" malgré que leurs longueurs diffèrent. Ce qui montre surtout que comparer les longueurs est certes plus rapide mais ça ne fait pas strictement la même chose que de tester l'égalité de 2 chaines.

[mactwist69]

Je dis peut être une bêtise mais je crois que le = "" est plus long car il va d'abord créer une objet string, pour y stocker une chaîne vide...

Tandis que le Lenght=0 il ne fait qu'un comparaison.

C'est d'ailleurs aussi pourquoi le StringBuilder est plus rapide que la concaténation avec le &....
Quand on utilise le &, il va créer autant d'objet string qu'il y a de parties... Ce qu'il ne fait pas avec le string builder.

C'est aussi pourquoi l'initialisation par String.empty est plus rapide, car il ne créer pas de String.

[Sehnsucht]

Le runtime maintient un pool des littéraux constants pour éviter ce type de réallocation du coup String.Empty et "" sont (peuvent être) équivalents (vérifiable via ReferenceEquals(String.Empty, "") par exemple)
Après là où ça se complique c'est selon la version du runtime, l'interning automatique de la chaine vide peut s'appliquer ou pas ; je renvoie à un article d'Eric Lipert pour plus d'infos sur le sujet.