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)
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)
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)
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
Laurent Deniau <laurent.deniau@cern.ch> 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
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
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
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 ?
;-)
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
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.
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.
C'est effectivement une alternative au !B dans le cas suivant.
}
et
while(A && B) { [...] }
a+, ld.
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.
"Laurent Deniau" <laurent.deniau@cern.ch> wrote in message
news:dnpg7j$7f$1@sunnews.cern.ch...
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
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.
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.
Charlie Gordon wrote:
"Laurent Deniau" <laurent.deniau@cern.ch> wrote in message
news:dnpg7j$7f$1@sunnews.cern.ch...
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
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.
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
In news:dnpbjf$jdo$1@sunnews.cern.ch, 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.
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
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
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