Hello,
je rebondis sur l'article de Driss.
Savez vous que en toute rigueur, on ne devrait utiliser
les variables de boucles QUE pour compter. En d'autres mots,
la variable de boucle ne devrait pas apparaître dans le corps de la
boucle.
Cette règle est une règle de base d'algorithmique et en pratique, c'est
effectivement plus sur et plus correct d'un point de vue sémantique.
Ainsi, pour unitialiser un tableau, il ne faudrait pas écrire ceci :
Const TAILLE_TABLEAU As Long = 100000
Dim t(TAILLE_TABLEAU) As Long
Dim i As Long
Dim n As Long
For i = 1 To TAILLE_TABLEAU
t(i) = 10
Next i
Mais cela:
n = 0
For i = 1 To TAILLE_TABLEAU
n = n + 1
t(n) = 10
Next i
On pourrait objecter que la seconde forme va être plus lente :
on doit incrémenter une variable de plus.
Il n'en est rien : En plus d'être plus correcte, la seconde forme
peut même être très légèrement plus rapide !
Mais comment est-ce possible ?
En n'utilisant pas 'i' dans la boucle, on permet au compilateur
d'implémenter la boucle de façon optimale, en utilisant
des instructions rapides qui savent (par exemple) décrémenter et brancher
si zéro en un seul cycle, ou tout autre genre d'optimisation.
D'où le gain de temps. Et bien sur c'est valable dans tous les langages.
Conclusion : ne jamais essayer de se substituer au compilateur : celui-ci
est dans tous les cas bien plus malin que le programmeur. A vouloir faire
des "ruses" pour tenter des "optimisations", on empêche bien souvent ce
brave compilateur de faire correctment son job :-)
Hello,
je rebondis sur l'article de Driss.
Savez vous que en toute rigueur, on ne devrait utiliser
les variables de boucles QUE pour compter. En d'autres mots,
la variable de boucle ne devrait pas apparaître dans le corps de la
boucle.
Cette règle est une règle de base d'algorithmique et en pratique, c'est
effectivement plus sur et plus correct d'un point de vue sémantique.
Ainsi, pour unitialiser un tableau, il ne faudrait pas écrire ceci :
Const TAILLE_TABLEAU As Long = 100000
Dim t(TAILLE_TABLEAU) As Long
Dim i As Long
Dim n As Long
For i = 1 To TAILLE_TABLEAU
t(i) = 10
Next i
Mais cela:
n = 0
For i = 1 To TAILLE_TABLEAU
n = n + 1
t(n) = 10
Next i
On pourrait objecter que la seconde forme va être plus lente :
on doit incrémenter une variable de plus.
Il n'en est rien : En plus d'être plus correcte, la seconde forme
peut même être très légèrement plus rapide !
Mais comment est-ce possible ?
En n'utilisant pas 'i' dans la boucle, on permet au compilateur
d'implémenter la boucle de façon optimale, en utilisant
des instructions rapides qui savent (par exemple) décrémenter et brancher
si zéro en un seul cycle, ou tout autre genre d'optimisation.
D'où le gain de temps. Et bien sur c'est valable dans tous les langages.
Conclusion : ne jamais essayer de se substituer au compilateur : celui-ci
est dans tous les cas bien plus malin que le programmeur. A vouloir faire
des "ruses" pour tenter des "optimisations", on empêche bien souvent ce
brave compilateur de faire correctment son job :-)
Hello,
je rebondis sur l'article de Driss.
Savez vous que en toute rigueur, on ne devrait utiliser
les variables de boucles QUE pour compter. En d'autres mots,
la variable de boucle ne devrait pas apparaître dans le corps de la
boucle.
Cette règle est une règle de base d'algorithmique et en pratique, c'est
effectivement plus sur et plus correct d'un point de vue sémantique.
Ainsi, pour unitialiser un tableau, il ne faudrait pas écrire ceci :
Const TAILLE_TABLEAU As Long = 100000
Dim t(TAILLE_TABLEAU) As Long
Dim i As Long
Dim n As Long
For i = 1 To TAILLE_TABLEAU
t(i) = 10
Next i
Mais cela:
n = 0
For i = 1 To TAILLE_TABLEAU
n = n + 1
t(n) = 10
Next i
On pourrait objecter que la seconde forme va être plus lente :
on doit incrémenter une variable de plus.
Il n'en est rien : En plus d'être plus correcte, la seconde forme
peut même être très légèrement plus rapide !
Mais comment est-ce possible ?
En n'utilisant pas 'i' dans la boucle, on permet au compilateur
d'implémenter la boucle de façon optimale, en utilisant
des instructions rapides qui savent (par exemple) décrémenter et brancher
si zéro en un seul cycle, ou tout autre genre d'optimisation.
D'où le gain de temps. Et bien sur c'est valable dans tous les langages.
Conclusion : ne jamais essayer de se substituer au compilateur : celui-ci
est dans tous les cas bien plus malin que le programmeur. A vouloir faire
des "ruses" pour tenter des "optimisations", on empêche bien souvent ce
brave compilateur de faire correctment son job :-)
Hello Jean-Marc,
Merci, c'est très instructif et nous allons sagement appliquer.
Qu'en est-il alors d'une boucle ayant le même objet mais implémentée
avec do while ou équivalent ?
La vitesse est-elle la même ?
Hello Jean-Marc,
Merci, c'est très instructif et nous allons sagement appliquer.
Qu'en est-il alors d'une boucle ayant le même objet mais implémentée
avec do while ou équivalent ?
La vitesse est-elle la même ?
Hello Jean-Marc,
Merci, c'est très instructif et nous allons sagement appliquer.
Qu'en est-il alors d'une boucle ayant le même objet mais implémentée
avec do while ou équivalent ?
La vitesse est-elle la même ?
La vitesse est-elle la même ?
Oui, car pour le compilateur, il n'y a de toute façon pas de For/Next
ni de While/Wend ni de Do/Loop.
...
L'astuce, c'est que selon les compilos, les processeurs et l'allure
de la boucle, le compilateur peut faire des optimisations de bas
niveau intéressantes. Par exemple, utiliser pour les pas
(L1, L2 et L3) une seule instruction, consommant donc un seul cycle.
Note : bien sur, l'optimisation (la vitesse) n'est pas le but ici.
On n'optimise pas un programme de cette façon mais en choisissant
de meilleurs algortihmes, en rationalisant les choses, en préprocessant,
etc.
La vitesse est-elle la même ?
Oui, car pour le compilateur, il n'y a de toute façon pas de For/Next
ni de While/Wend ni de Do/Loop.
...
L'astuce, c'est que selon les compilos, les processeurs et l'allure
de la boucle, le compilateur peut faire des optimisations de bas
niveau intéressantes. Par exemple, utiliser pour les pas
(L1, L2 et L3) une seule instruction, consommant donc un seul cycle.
Note : bien sur, l'optimisation (la vitesse) n'est pas le but ici.
On n'optimise pas un programme de cette façon mais en choisissant
de meilleurs algortihmes, en rationalisant les choses, en préprocessant,
etc.
La vitesse est-elle la même ?
Oui, car pour le compilateur, il n'y a de toute façon pas de For/Next
ni de While/Wend ni de Do/Loop.
...
L'astuce, c'est que selon les compilos, les processeurs et l'allure
de la boucle, le compilateur peut faire des optimisations de bas
niveau intéressantes. Par exemple, utiliser pour les pas
(L1, L2 et L3) une seule instruction, consommant donc un seul cycle.
Note : bien sur, l'optimisation (la vitesse) n'est pas le but ici.
On n'optimise pas un programme de cette façon mais en choisissant
de meilleurs algortihmes, en rationalisant les choses, en préprocessant,
etc.
Hello,
je rebondis sur l'article de Driss.
Savez vous que en toute rigueur, on ne devrait utiliser
les variables de boucles QUE pour compter. En d'autres mots,
la variable de boucle ne devrait pas apparaître dans le corps de la
boucle.
Cette règle est une règle de base d'algorithmique et en pratique, c'est
effectivement plus sur et plus correct d'un point de vue sémantique.
Ainsi, pour unitialiser un tableau, il ne faudrait pas écrire ceci :
Const TAILLE_TABLEAU As Long = 100000
Dim t(TAILLE_TABLEAU) As Long
Dim i As Long
Dim n As Long
For i = 1 To TAILLE_TABLEAU
t(i) = 10
Next i
Mais cela:
n = 0
For i = 1 To TAILLE_TABLEAU
n = n + 1
t(n) = 10
Next i
On pourrait objecter que la seconde forme va être plus lente :
on doit incrémenter une variable de plus.
Il n'en est rien : En plus d'être plus correcte, la seconde forme
peut même être très légèrement plus rapide !
Mais comment est-ce possible ?
En n'utilisant pas 'i' dans la boucle, on permet au compilateur
d'implémenter la boucle de façon optimale, en utilisant
des instructions rapides qui savent (par exemple) décrémenter et brancher
si zéro en un seul cycle, ou tout autre genre d'optimisation.
D'où le gain de temps. Et bien sur c'est valable dans tous les langages.
Conclusion : ne jamais essayer de se substituer au compilateur : celui-ci
est dans tous les cas bien plus malin que le programmeur. A vouloir faire
des "ruses" pour tenter des "optimisations", on empêche bien souvent ce
brave compilateur de faire correctment son job :-)
Bon week-end !
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Hello,
je rebondis sur l'article de Driss.
Savez vous que en toute rigueur, on ne devrait utiliser
les variables de boucles QUE pour compter. En d'autres mots,
la variable de boucle ne devrait pas apparaître dans le corps de la
boucle.
Cette règle est une règle de base d'algorithmique et en pratique, c'est
effectivement plus sur et plus correct d'un point de vue sémantique.
Ainsi, pour unitialiser un tableau, il ne faudrait pas écrire ceci :
Const TAILLE_TABLEAU As Long = 100000
Dim t(TAILLE_TABLEAU) As Long
Dim i As Long
Dim n As Long
For i = 1 To TAILLE_TABLEAU
t(i) = 10
Next i
Mais cela:
n = 0
For i = 1 To TAILLE_TABLEAU
n = n + 1
t(n) = 10
Next i
On pourrait objecter que la seconde forme va être plus lente :
on doit incrémenter une variable de plus.
Il n'en est rien : En plus d'être plus correcte, la seconde forme
peut même être très légèrement plus rapide !
Mais comment est-ce possible ?
En n'utilisant pas 'i' dans la boucle, on permet au compilateur
d'implémenter la boucle de façon optimale, en utilisant
des instructions rapides qui savent (par exemple) décrémenter et brancher
si zéro en un seul cycle, ou tout autre genre d'optimisation.
D'où le gain de temps. Et bien sur c'est valable dans tous les langages.
Conclusion : ne jamais essayer de se substituer au compilateur : celui-ci
est dans tous les cas bien plus malin que le programmeur. A vouloir faire
des "ruses" pour tenter des "optimisations", on empêche bien souvent ce
brave compilateur de faire correctment son job :-)
Bon week-end !
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
Hello,
je rebondis sur l'article de Driss.
Savez vous que en toute rigueur, on ne devrait utiliser
les variables de boucles QUE pour compter. En d'autres mots,
la variable de boucle ne devrait pas apparaître dans le corps de la
boucle.
Cette règle est une règle de base d'algorithmique et en pratique, c'est
effectivement plus sur et plus correct d'un point de vue sémantique.
Ainsi, pour unitialiser un tableau, il ne faudrait pas écrire ceci :
Const TAILLE_TABLEAU As Long = 100000
Dim t(TAILLE_TABLEAU) As Long
Dim i As Long
Dim n As Long
For i = 1 To TAILLE_TABLEAU
t(i) = 10
Next i
Mais cela:
n = 0
For i = 1 To TAILLE_TABLEAU
n = n + 1
t(n) = 10
Next i
On pourrait objecter que la seconde forme va être plus lente :
on doit incrémenter une variable de plus.
Il n'en est rien : En plus d'être plus correcte, la seconde forme
peut même être très légèrement plus rapide !
Mais comment est-ce possible ?
En n'utilisant pas 'i' dans la boucle, on permet au compilateur
d'implémenter la boucle de façon optimale, en utilisant
des instructions rapides qui savent (par exemple) décrémenter et brancher
si zéro en un seul cycle, ou tout autre genre d'optimisation.
D'où le gain de temps. Et bien sur c'est valable dans tous les langages.
Conclusion : ne jamais essayer de se substituer au compilateur : celui-ci
est dans tous les cas bien plus malin que le programmeur. A vouloir faire
des "ruses" pour tenter des "optimisations", on empêche bien souvent ce
brave compilateur de faire correctment son job :-)
Bon week-end !
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Hum sur un plan académique, je dirais plutot de bannir la boucle for!
Enfin, ce que tu dis n'est pas totalement faux mais loin d'etre
totalement vrai!
Un compilo plus intelligent qu'un codeur ? je doute un peu quand meme!
Fais un code en C, sort le listing asm et dis moi qu'il n'est pas
possible de faire mieux ?
Et pourtant le C est le langage le plus proche de l'assembleur!
Ok dans la plupart des cas le compilo fera mieux, mais pas toujours!
Je pense qu'il n'y a pas plus mauvais conseil que de dire
"N'optimisez pas vos codes, le compilo s'en charge"
Te rends tu compte de la portée de ce que tu dis ?
Hum sur un plan académique, je dirais plutot de bannir la boucle for!
Enfin, ce que tu dis n'est pas totalement faux mais loin d'etre
totalement vrai!
Un compilo plus intelligent qu'un codeur ? je doute un peu quand meme!
Fais un code en C, sort le listing asm et dis moi qu'il n'est pas
possible de faire mieux ?
Et pourtant le C est le langage le plus proche de l'assembleur!
Ok dans la plupart des cas le compilo fera mieux, mais pas toujours!
Je pense qu'il n'y a pas plus mauvais conseil que de dire
"N'optimisez pas vos codes, le compilo s'en charge"
Te rends tu compte de la portée de ce que tu dis ?
Hum sur un plan académique, je dirais plutot de bannir la boucle for!
Enfin, ce que tu dis n'est pas totalement faux mais loin d'etre
totalement vrai!
Un compilo plus intelligent qu'un codeur ? je doute un peu quand meme!
Fais un code en C, sort le listing asm et dis moi qu'il n'est pas
possible de faire mieux ?
Et pourtant le C est le langage le plus proche de l'assembleur!
Ok dans la plupart des cas le compilo fera mieux, mais pas toujours!
Je pense qu'il n'y a pas plus mauvais conseil que de dire
"N'optimisez pas vos codes, le compilo s'en charge"
Te rends tu compte de la portée de ce que tu dis ?
> C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Il est souvent difficile, si pas impossible, de faire mieux "à la main"
au niveau traduction que ce que fait un bon compilateur en utilisant
les bonnes options d'optimisation.
Et pourtant le C est le langage le plus proche de l'assembleur!
Ok dans la plupart des cas le compilo fera mieux, mais pas toujours!
On est bien d'accord :-) Mais si tu as un problème de perfs que seule
une réécriture en assembleur à la main peut résoudre, ton problème
n'est pas la ou tu crois. Cf la suite ...
- Pour rechercher efficacement dans un dictionnaire (non trié) comportant
des millions d'entrées, il y a des méthodes efficaces (tries/trees) et
d'autres moins, voire beaucoup moins. Le choix de l'algo est déterminant.
Ca ne veux pas dire qu'il faut coder comme un cochon, c'est précisément
tout
le contraire !
Je dis qu'il faut toujours garder un code clair, sans astuces syntaxiques.
Le
> C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Il est souvent difficile, si pas impossible, de faire mieux "à la main"
au niveau traduction que ce que fait un bon compilateur en utilisant
les bonnes options d'optimisation.
Et pourtant le C est le langage le plus proche de l'assembleur!
Ok dans la plupart des cas le compilo fera mieux, mais pas toujours!
On est bien d'accord :-) Mais si tu as un problème de perfs que seule
une réécriture en assembleur à la main peut résoudre, ton problème
n'est pas la ou tu crois. Cf la suite ...
- Pour rechercher efficacement dans un dictionnaire (non trié) comportant
des millions d'entrées, il y a des méthodes efficaces (tries/trees) et
d'autres moins, voire beaucoup moins. Le choix de l'algo est déterminant.
Ca ne veux pas dire qu'il faut coder comme un cochon, c'est précisément
tout
le contraire !
Je dis qu'il faut toujours garder un code clair, sans astuces syntaxiques.
Le
> C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Il est souvent difficile, si pas impossible, de faire mieux "à la main"
au niveau traduction que ce que fait un bon compilateur en utilisant
les bonnes options d'optimisation.
Et pourtant le C est le langage le plus proche de l'assembleur!
Ok dans la plupart des cas le compilo fera mieux, mais pas toujours!
On est bien d'accord :-) Mais si tu as un problème de perfs que seule
une réécriture en assembleur à la main peut résoudre, ton problème
n'est pas la ou tu crois. Cf la suite ...
- Pour rechercher efficacement dans un dictionnaire (non trié) comportant
des millions d'entrées, il y a des méthodes efficaces (tries/trees) et
d'autres moins, voire beaucoup moins. Le choix de l'algo est déterminant.
Ca ne veux pas dire qu'il faut coder comme un cochon, c'est précisément
tout
le contraire !
Je dis qu'il faut toujours garder un code clair, sans astuces syntaxiques.
Le
C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
Le reste relève plus de la philo ou du cas par cas...
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Bonne soirée
C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
Le reste relève plus de la philo ou du cas par cas...
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Bonne soirée
C'est une question de goût, pas d'académisme. La boucle For à ses usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
Le reste relève plus de la philo ou du cas par cas...
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Bonne soirée
"Sebastien" wrote in message
news:
Hello,C'est une question de goût, pas d'académisme. La boucle For à ses
usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est
juste des cas ou il sera 'naturel' de l'employer.
Mais tu as raison, il n'est jamais plus perfomant qu'autre
chose.
<...>Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement
clair :-)Le reste relève plus de la philo ou du cas par cas...
Sur!Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Ok !Bonne soirée
Bonne journée !
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
"Sebastien" <Sebastien.groulard@gmail.com> wrote in message
news:5849D312-A76D-4475-97ED-559B8C1849B6@microsoft.com...
Hello,
C'est une question de goût, pas d'académisme. La boucle For à ses
usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est
juste des cas ou il sera 'naturel' de l'employer.
Mais tu as raison, il n'est jamais plus perfomant qu'autre
chose.
<...>
Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement
clair :-)
Le reste relève plus de la philo ou du cas par cas...
Sur!
Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Ok !
Bonne soirée
Bonne journée !
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
"Sebastien" wrote in message
news:
Hello,C'est une question de goût, pas d'académisme. La boucle For à ses
usages.
Hum si on veut, mais je vois pas de cas ou un for est irremplacable ou
plus performant...
C'est tout à fait vrai. For n'est pas irremplaçable. Il est
juste des cas ou il sera 'naturel' de l'employer.
Mais tu as raison, il n'est jamais plus perfomant qu'autre
chose.
<...>Enfin la on s'évade, je voulais juste réagir a ce conseil de départ qui
pour moi pouvait être dangereusement interprété.
C'est vrai. J'aurais du nuancer afin d'être parfaitement
clair :-)Le reste relève plus de la philo ou du cas par cas...
Sur!Sinon merci pour tes éclaircissements et ta pédagogie a toute épreuve :)
Je manquerais pas de consulter tes liens des que j'aurais une minute!
Ok !Bonne soirée
Bonne journée !
Cordialement,
--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à
appeler une procédure externe ?
je ne suis pas au point de réécrire tous les algorythmes, même si cela me
prend, mais je voudrai ne pas trop perdre en efficacité..
Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à
appeler une procédure externe ?
je ne suis pas au point de réécrire tous les algorythmes, même si cela me
prend, mais je voudrai ne pas trop perdre en efficacité..
Mais perd t'on comme le dis Sebastien beaucoup de cycles ou de temps à
appeler une procédure externe ?
je ne suis pas au point de réécrire tous les algorythmes, même si cela me
prend, mais je voudrai ne pas trop perdre en efficacité..