compilation

Le
Barsalou
Bonjour,

Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation, notamment
pour améliorer la vitesse d'exécution, et cela vaut-il la peine ?

Merci de m'informer.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
LE TROLL
Le #15414451
BOF !

--
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Barsalou" news: %23$
Bonjour,

Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?

Merci de m'informer.


jean-marc
Le #15414441
"Barsalou" news:%23$
Bonjour,

Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?

Merci de m'informer.



hello,

je n'ai pas la version initiation sous la main mais je
pense qu'elle dispose des mêmes options à savoir:
Quand tu génères ton exe:
"FileMake"
Tu as un bouton "Options"
Tu cliques dessus et tu as une form avec 2 onglets:
Le second onglet ("compile") te propose des options
d'optimisation:
Par défaut, il est sur "Optimize for Fast Code".

Tu as encore d'autre réglages dans "Advanced Optimisations"
qui permettent de générer du code plus rapide:
"désactiver le controle de bornes", "Désactiver le
controle d'overflow", etc.

--- MAIS ---

=> On ne gagne JAMAIS rien à essayer d'accélérer les choses
par des otpimisations de compilation.

=> La seule façon raisonnable d'augmenter les perfs (si
besoin est) est de choisir de meilleurs algorithmes, de
meilleures structures de données, ou d'utiliser des
fonctions bas niveau du système.

Exemple bête: si tu tries des nombres avec un tri à bulle,
il est inutile et ridicule de vouloir l'optimiser. Ca sera
toujours de toute façon hyper lent comparé à un meilleur
algorithme (par exemple un quick sort).

Autre exemple: Faire une recherche linéaire dans
un grand tableau de données sera toujours plus lent
que de faire une recherche dichotomique ou avec une hash
table.

Dans tous les cas, l'amélioration des perfs passe par de
meilleures structures/meilleurs algos/meilleures fonctions.

Donc pour répondre à ta question: ce type d'optimisation
par compilation est totalement inutile.

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ;
FAQ VB: http://faq.vb.free.fr/
Jacques93
Le #15414391
Bonjour jean-marc,
jean-marc a écrit :
"Barsalou" news:%23$
Bonjour,

Si je ne m'abuse on peut avec VB6 Pro compiler de façon à optimiser le
fichier exe.
Y a-t-il une astuce pour faire de même avec la version Initiation,
notamment pour améliorer la vitesse d'exécution, et cela vaut-il la peine
?

Merci de m'informer.



hello,

je n'ai pas la version initiation sous la main mais je
pense qu'elle dispose des mêmes options à savoir:
Quand tu génères ton exe:
"FileMake"
Tu as un bouton "Options"
Tu cliques dessus et tu as une form avec 2 onglets:
Le second onglet ("compile") te propose des options
d'optimisation:
Par défaut, il est sur "Optimize for Fast Code".

Tu as encore d'autre réglages dans "Advanced Optimisations"
qui permettent de générer du code plus rapide:
"désactiver le controle de bornes", "Désactiver le
controle d'overflow", etc.




On a également accès à cet onglet (dans ce cas le 3ème) via

Projet => Propiétés

--- MAIS ---

=> On ne gagne JAMAIS rien à essayer d'accélérer les choses
par des otpimisations de compilation.

=> La seule façon raisonnable d'augmenter les perfs (si
besoin est) est de choisir de meilleurs algorithmes, de
meilleures structures de données, ou d'utiliser des
fonctions bas niveau du système.

Exemple bête: si tu tries des nombres avec un tri à bulle,
il est inutile et ridicule de vouloir l'optimiser. Ca sera
toujours de toute façon hyper lent comparé à un meilleur
algorithme (par exemple un quick sort).

Autre exemple: Faire une recherche linéaire dans
un grand tableau de données sera toujours plus lent
que de faire une recherche dichotomique ou avec une hash
table.

Dans tous les cas, l'amélioration des perfs passe par de
meilleures structures/meilleurs algos/meilleures fonctions.

Donc pour répondre à ta question: ce type d'optimisation
par compilation est totalement inutile.




Pour une fois, tu me permettras d'être en désaccord avec toi.
Non pas sur le fait qu'il faille un algorithme performant et adapté,
là je suis d'accord, c'est la base.

Mais sur les possibilités d'optimisation intégrées à un compilateur.
Je parle là en général, pas de VB en particulier ;-) .

Là aussi, il peut être utile de tester. Bien que les processeurs soient
de plus en plus puissants, indiquer le type de processeur par exemple
permet d'utiliser les instructions les plus performantes. J'admets que
pour VB, cette option est peut être obsolète vu son âge. D'autres
options, comme certains contrôles (dans les options avancées) peuvent
être intéressantes, bien qu'il faille pour le coup un code irréprochable
(Je n'ai pas testé ces options sous VB)

Par contre, et toujours de *manière générale* , le choix entre
pseudo-code (ou code interprété) et code natif, peut ne pas être neutre
du tout. Je prends un exemple concret, bien qu'ancien. Il existe des
langages multi plate-formes; pour des raisons de distribution, il est
intéressant de choisir le pseudo-code qui sera identique, car interprété
par un Run-Time approprié à chaque plate-forme. Si l'on choisit du code
natif, il faut deux distributions, car le code est, d'une part
interprété directement par le processeur, mais il faut qu'il soit
reconnu comme un exécutable valide par le système d'exploitation (et la,
point de normes, chacun son format). Et si je poursuis avec cet exemple
où les plates-formes étaient d'une part MS-DOS et d'autre par UNIX, on
avait (1995) d'un côté du code 8/16 bits en mode réel pour le premier,
et du code 32 bits en mode protégé pour l'autre. Je te garantis que ça
fait une différence

J'admets que dans ce cas, il est également difficile de juger de la part
de responsabilité du système d'exploitation.

Je te rappelle également les temps anciens des 286, et 386, où il était
bon de choisir le modèle adéquat entre Small (.exe ou .com), Medium ou
Large), et éventuellement d'indiquer la bonne librairie mathématique.
Les processeurs i287 et i387 n'étant pas toujours présent, car
excessivement cher, le compilateur générait soit des instructions
machines x87, soit utilisaient des librairies appropriées (Small, Medium
ou Large) exécutées par le processeur central, soit les deux. De
mémoire, un 80287, lors de sa sortie coutait plusieurs milliers de
francs (1985). Mais les gains de temps étaient très impressionnant
(de plusieurs minutes à quelques secondes pour certains calcul)

Bon d'accord, maintenant les processeurs mathématiques sont intégrés aux
Pentium, Itanium, etc... et le problème se déplace plutôt vers les
cartes graphiques (DirectX, Open GL)


PS : Je ne te ferais pas l'affront de te rappeler la foultitude
d'options de compilation et d'édition de liens de Cl (Visual C).
Auraient ils mis cela à disposition si ça ne servait vraiment à rien ? ;-)

--
Cordialement,

Jacques.
jean-marc
Le #15414381
"Jacques93" wrote in message
news:
Bonjour jean-marc,
jean-marc a écrit :
"Barsalou" news:%23$






Hello Jacques,


Pour une fois, tu me permettras d'être en désaccord avec toi.



Bien entendu :-)


Non pas sur le fait qu'il faille un algorithme performant et adapté,
là je suis d'accord, c'est la base.

Mais sur les possibilités d'optimisation intégrées à un compilateur.
Je parle là en général, pas de VB en particulier ;-) .

Là aussi, il peut être utile de tester. Bien que les processeurs soient
de plus en plus puissants, indiquer le type de processeur par exemple
permet d'utiliser les instructions les plus performantes. J'admets que
pour VB, cette option est peut être obsolète vu son âge. D'autres
options, comme certains contrôles (dans les options avancées) peuvent
être intéressantes, bien qu'il faille pour le coup un code irréprochable
(Je n'ai pas testé ces options sous VB)



C'est exact. Par exemple avec VB, désactiver le controle de bornes de
tableau
fait gagner du temps (beaucoup) si on fait un usage extensif des tableaux.

Voici un petit exemple:

Dim tablo(1000) As Long

Private Sub Command1_Click()
Dim i As Long
Dim j As Long
Dim t1 As Double, t2 As Double
Dim duration As Double

t1 = Timer
For i = 1 To 50000
For j = 1 To 1000
tablo(j) = i * j
Next j
Next i
t2 = Timer
duration = t2 - t1
MsgBox duration * 1000
End Sub

Si on compile ce code avec et sans le controle de bornes, et avec et
sans le controle d'overflow, on obtient ceci:

Pas d'optimisation : 171 ms
Enleve controle bornes : 108 ms
Enleve aussi controle overflow : 71 ms

Donc c'est clair, on a énormément gagné, à vue de nez.

MAIS c'est très artificiel, car certes on a doublé la vitesse
du programme, mais uniquement parce que celui ci est orienté pour
mesurer les effets du controle de bornes et de l'overflow.

On notera au passage que certes, on a gagné environ 100 ms entre
le meilleur et le moins bon, mais c'est en exécutant 50000 * 1000
opérations c'est à dire 50.000.000 (50 millions) d'affectation/calcul.
Soit un gain unitaire par instruction de:
100 / 50.000.000 = 1/500000 ms . C'est peu.

A moins d'utiliser ceci dans un programme qui passe sa vie à faire
ce genre de calculs, le bénéfice va être difficile à mesurer.


Par contre, et toujours de *manière générale* , le choix entre
pseudo-code (ou code interprété) et code natif, peut ne pas être neutre
du tout. Je prends un exemple concret, bien qu'ancien. Il existe des
langages multi plate-formes; pour des raisons de distribution, il est
intéressant de choisir le pseudo-code qui sera identique, car interprété
par un Run-Time approprié à chaque plate-forme. Si l'on choisit du code
natif, il faut deux distributions, car le code est, d'une part
interprété directement par le processeur, mais il faut qu'il soit
reconnu comme un exécutable valide par le système d'exploitation (et la,
point de normes, chacun son format). Et si je poursuis avec cet exemple
où les plates-formes étaient d'une part MS-DOS et d'autre par UNIX, on
avait (1995) d'un côté du code 8/16 bits en mode réel pour le premier,
et du code 32 bits en mode protégé pour l'autre. Je te garantis que ça
fait une différence



Ca c'est tout à fait vrai! Certains de mes programmes vont presque
2 fois plus vite sur AIX une fois compilé en 64 bits au lieu de 32
sous Windows 2000.

J'admets que dans ce cas, il est également difficile de juger de la part
de responsabilité du système d'exploitation.



Oui, aussi. Et aussi du hardware :

A ce propos j'ai une anecdote: croyant gagner du temps, j'implémente
une optimisation rusée pour gagner du temps sur des cas
particluiers de strlen().
Je fais, je teste => Génial! Sous Windows et sous Unix, je vais
presque 2 fois plus vite.

Je porte mon code sur notre mainframe IBM, qui est la plateforme
du client. Enorme déception: je vais 2 fois plus lentement qu'avant!

=> Sur les mainframes IBM, des opérations genre strlen() sont reconnus
par le compilateur, qui sait alors les transformer pour les faire
exécuter en micro-code avec des circuits spéciaux :
Un strlen est instantané sur ces machines, quelle que
soit la longeur de la chaine... Amusant.

Je te rappelle également les temps anciens des 286, et 386, où il était
bon de choisir le modèle adéquat entre Small (.exe ou .com), Medium ou
Large), et éventuellement d'indiquer la bonne librairie mathématique.
Les processeurs i287 et i387 n'étant pas toujours présent, car
excessivement cher, le compilateur générait soit des instructions
machines x87, soit utilisaient des librairies appropriées (Small, Medium
ou Large) exécutées par le processeur central, soit les deux. De
mémoire, un 80287, lors de sa sortie coutait plusieurs milliers de
francs (1985). Mais les gains de temps étaient très impressionnant
(de plusieurs minutes à quelques secondes pour certains calcul)



Oh oui, j'ai très bien connu cette bell époque. On faisait
gaffe alors et on savait ce que pré-processing voulait dire. On savait
aussi déployer des trésors d'imagination pour éviter les calculs en
virgule flottante!


Bon d'accord, maintenant les processeurs mathématiques sont intégrés aux
Pentium, Itanium, etc... et le problème se déplace plutôt vers les cartes
graphiques (DirectX, Open GL)


PS : Je ne te ferais pas l'affront de te rappeler la foultitude d'options
de compilation et d'édition de liens de Cl (Visual C). Auraient ils mis
cela à disposition si ça ne servait vraiment à rien ? ;-)



Non non, c'est très vrai. Ces options sont utiles et font une vraie
différence,
mesurable et tout et tout. Parfois utile, en fonction du genre de
programmes.

---

En fait, mon propos était surtout de dire (mais sans doute ais-je été un
peu maladroit dans la formulation) que l'optimisation du code passait
*en premier* par le choix des algos, des structures, la réflexion, etc.

Bien entendu, une fois le code parfaitement au point et utilisant
les meilleurs options pour les algos et le reste, ALORS (seulement)
on peut regarder du coté des options de compil, pour générer le meilleur
code possible.

Bien cordialement,

Jean-marc

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ;
FAQ VB: http://faq.vb.free.fr/
Barsalou
Le #15413921
Non. Je n'ai qu'un onglet qui ne propose pas d'options de compilations.
Merci quand même
Barsalou
Le #15413911
Il n'y a rien non plus dans les propriétés du projet.
Cela dit j'ai fait de mon mieux pour optimiser le code et je voulais
simplement savoir si je pouvais gagner quelque chose en plus !
Jacques93
Le #15413881
Bonjour Barsalou,
Barsalou a écrit :
Il n'y a rien non plus dans les propriétés du projet.
Cela dit j'ai fait de mon mieux pour optimiser le code et je voulais
simplement savoir si je pouvais gagner quelque chose en plus !



Bon, pas d'onglet, mais les options de compilation fonctionnent peut
être quand même. Elles sont stockées dans le .vbp. Si tu veux essayer,
il n'y a pas grand risque, tu édites le .vbp avec le bloc-note (fais une
sauvegarde avant, au cas où), et tu regardes si tu as les lignes :

CompilationType=0
OptimizationType=0
FavorPentiumPro(tm)=0
CodeViewDebugInfo=0
NoAliasing=0
BoundsCheck=0
OverflowCheck=0
FlPointCheck=0
FDIVCheck=0
UnroundedFP=0

qui sont les options par défaut. Si elles n'y sont pas tu peux les
insérer après 'VersionCompanyName'. Pour vérifier s'y elles sont prises
en compte tu peux faire une compilation avec

CompilationType=0 (Compiler en Code Natif)

et une autre

CompilationType=-1 (Compiler en P-Code)

si l'exe obtenu est de taille différente (le Code Natif est plus
volumineux) c'est bon signe. Les autres options sont
(0 = False / -1 = True) :

OptimizationType=0 (Optimiser la rapidité du code)
OptimizationType=1 (Optimiser la taille du code)
OptimizationType=2 (Pas d'optimisation)

FavorPentiumPro(tm)=0/-1 (Favoriser le Pentium Pro(tm)
CodeViewDebugInfo=0/-1 (Générer les informations de débogage)

' Optimisation avancée :

NoAliasing=0/-1 (Pas d'utilisation d'alias)
BoundsCheck=0/-1 (Supprimer les contrôles de limites de
tableaux)
OverflowCheck=0/-1 (Supprimer les contrôles de dépassement sur les
entiers)
FlPointCheck=0/-1 (Supprimer les contrôles de d'erreurs en
virgules flottante)
FDIVCheck=0/-1 (Supprimer les contrôles Safe Pentium(tm) FDIV
UnroundedFP=0/-1 (Autoriser les opérations en virgule flottante
non arrondies)

valables uniquement avec une compilation en Code Natif.

--
Cordialement,

Jacques.
Barsalou
Le #15413841
Merci, je vais essayer car c'est exactement ce que je cherchais.
Barsalou
Le #15413801
CompilationType était à -1. Je l'ai mis à 0 et compilé, mais l'exécutable a
exactement les mêmes 815104 octets de long, donc cela ne sert à rien de
bidouiller le vbp.
Merci quand même.
Jean-marc
Le #15413791
Barsalou wrote:
CompilationType était à -1. Je l'ai mis à 0 et compilé, mais
l'exécutable a exactement les mêmes 815104 octets de long, donc cela
ne sert à rien de bidouiller le vbp.
Merci quand même.



Hello,

Mauvaise nouvelle: les options de compilation avancées et la compilation
en code natif est une fonctionnalié qui n'existe que dans les versions
Pro et Enterprise.

Ca n' a pas été facile, mais j'ai trouvé:
http://msdn2.microsoft.com/en-us/library/aa240843(VS.60).aspx

Et aussi des infos intéressantes ici:
http://msdn2.microsoft.com/en-us/library/aa232747(VS.60).aspx


--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
mailto: remove '_no_spam_' ;
FAQ VB: http://faq.vb.free.fr/
Publicité
Poster une réponse
Anonyme