Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

test et style

13 réponses
Avatar
Laurent Deniau
Y aurait-il une quelleconque raison pour que

if (A) {
if (B) {
[...]
}
}

soit plus lent ou plus rapide que

if (A && B) {
[...]
}

ou A et B sont deux expressions booleennes non-constantes.

Idem pour:

while(A) {
if (B) {
[...]
}
}

et

while(A && B) {
[...]
}

A priori je dirais non, mais est-ce que qqchose m'aurait echappe?

a+, ld.

10 réponses

1 2
Avatar
Stephane Zuckerman
On Wed, 14 Dec 2005, Laurent Deniau wrote:

Y aurait-il une quelleconque raison pour que

if (A) {
if (B) {
[...]
}
}

soit plus lent ou plus rapide que

if (A && B) {
[...]
}

ou A et B sont deux expressions booleennes non-constantes.


Pour cette construction il est clair que non (le compilateur transformant
sans doute une forme en l'autre).

while(A) {
if (B) {
[...]
}
}

et

while(A && B) {
[...]
}


Là je pense comme vous, mais je ne sais pas. Après tout, le compilateur/le
prédicteur de branchement pourraient bien ne pas savoir comment s'y
prendre... Tout dépend de ce qu'est capable d'analyser le compilateur, je
pense.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

Avatar
Marc Boyer
Laurent Deniau a écrit :
Idem pour:

while(A) {
if (B) {
[...]
}
manque pas un 'else break' là ?

}

et

while(A && B) {
[...]
}


Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain

Avatar
Jean-Marc Bourguet
Laurent Deniau writes:

Y aurait-il une quelleconque raison pour que

if (A) {
if (B) {
[...]
}
}

soit plus lent ou plus rapide que

if (A && B) {
[...]
}

ou A et B sont deux expressions booleennes non-constantes.


Je n'en vois pas. Meme avec des generateurs de code tres simple on
devrait arriver au meme code.

Idem pour:

while(A) {
if (B) {
[...]
}
}

et

while(A && B) {
[...]
}


La deuxieme boucle est terminee des que !B, pas la premiere.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Avatar
Pierre Maurette
Y aurait-il une quelleconque raison pour que

if (A) {
if (B) {
[...]
}
}

soit plus lent ou plus rapide que

if (A && B) {
[...]
}

ou A et B sont deux expressions booleennes non-constantes.
Je pense que le code objet sera strictement le même. Le choix entre les

deux formes est du niveau du commentaire implicite. La première forme
est claire sur les intentions du programmeur de ne pas évaluer B si A
est faux, mais elle est méchante pour son ego: un lecteur pourra
supposer qu'il ignore la règle de l'évaluation économique. ;-) bien
entendu.


Idem pour:

while(A) {
if (B) {
[...]
}
}
Si A vrai et B faux, je continue la boucle.



et

while(A && B) {
[...]
}
Si A vrai et B faux, j'arrête la boucle.


Là, il me semble que ce n'est pas du tout le même algo, non ?
;-)




--
Pierre Maurette

Avatar
Laurent Deniau
Pierre Maurette wrote:
Idem pour:

while(A) {
if (B) {
[...]
}
}


Si A vrai et B faux, je continue la boucle.


Note que A aussi peut arreter la boucle.

et

while(A && B) {
[...]
}


Si A vrai et B faux, j'arrête la boucle.


Ca c'est sur!

Là, il me semble que ce n'est pas du tout le même algo, non ?
;-)


Juste ;-) Je corrige pour qqchose de plus correct...

while (A && !B) {
[...]
}

Ca ne change rien a ma question. Mais je pense effectivement que le code
objet sera soit identique, soit aussi performant dans les deux cas.

a+, ld.


Avatar
Laurent Deniau
Marc Boyer wrote:

Idem pour:

while(A) {
if (B) {
[...]
}


manque pas un 'else break' là ?


C'est effectivement une alternative au !B dans le cas suivant.

}

et

while(A && B) {
[...]
}



a+, ld.


Avatar
Charlie Gordon
"Laurent Deniau" wrote in message
news:dnpg7j$7f$
Pierre Maurette wrote:
Idem pour:

while(A) {
if (B) {
[...]
}
}


Juste ;-) Je corrige pour qqchose de plus correct...


while (A && !B) {
[...]
}

Ca ne change rien a ma question. Mais je pense effectivement que le code
objet sera soit identique, soit aussi performant dans les deux cas.


effectivement, cela ne change rien à la question, c'est toujours différent.
ces deux boucles ne sont pas équivalentes, le code objet sera différent pour des
valeurs non triviales de A et B

--
Chqrlie.



Avatar
Laurent Deniau
Charlie Gordon wrote:
"Laurent Deniau" wrote in message
news:dnpg7j$7f$

Pierre Maurette wrote:


Idem pour:

while(A) {
if (B) {
[...]
}
}


Juste ;-) Je corrige pour qqchose de plus correct...


while (A && !B) {
[...]
}

Ca ne change rien a ma question. Mais je pense effectivement que le code
objet sera soit identique, soit aussi performant dans les deux cas.



effectivement, cela ne change rien à la question, c'est toujours différent.
ces deux boucles ne sont pas équivalentes, le code objet sera différent pour des
valeurs non triviales de A et B


Ok, alors simplifions encore un peu:

while(A)
if (B)
break;

et

while(A && !B) ;

a+, ld.




Avatar
Antoine Leca
In news:dnpbjf$jdo$, Laurent Deniau va escriure:
Y aurait-il une quelleconque raison pour que

if (A) {
if (B) {
[...]
}
}

soit plus lent ou plus rapide que

if (A && B) {
[...]
}

ou A et B sont deux expressions booleennes non-constantes.


Un générateur de code un peu taquin en mode déboguage, qui insiste pour
mettre une possibilité de point d'arrêt pour chaque ligne (et donc va être
obligé de générer une instruction supplémentaire pour la deuxième accolade
fermante, dans la première hypothèse) ?


Ou un générateur de code très idiot, qui génère systématiquement, pour une
accolade fermante
JUMP .L2 / saute par-dessus le else
puis après l'accolage fermante
.L2:
sans s'apercevoir, le c.., qu'il n'y a rien entre les deux quand il n'y a
pas de else. Dans ton exemple, dans le premier cas il y aura deux sauts
inutiles, mais dans le second cas il n'y en aura qu'un ?


Autre possibilité, un générateur de code pour architecture parallèle, qui
évalue spéculativement B sur un deuxième noud, mais qui ne le fait que dans
l'un des schémas et pas dans l'autre (va savoir pourquoi...) Évidemment, on
ne peut faire cela que si l'on est sûr que les effets de bord de A n'ont pas
d'effet pour B.


Antoine

Avatar
Laurent Coustet
Laurent Deniau wrote:
Y aurait-il une quelleconque raison pour que

if (A) {
if (B) {
[...]
}
}

soit plus lent ou plus rapide que

if (A && B) {
[...]
}

A priori je dirais non, mais est-ce que qqchose m'aurait echappe?


Il suffit de regarder la différence dans la sortie assembleur crashée
par le compilateur.

Et on constate qu'il sagit exactement du même code généré!
--
Laurent Coustet

1 2