Si tu
n'appelles la fonction qu'une seule fois, ce n'est pas la peine de la
générer en ligne.
Si tu
n'appelles la fonction qu'une seule fois, ce n'est pas la peine de la
générer en ligne.
Si tu
n'appelles la fonction qu'une seule fois, ce n'est pas la peine de la
générer en ligne.
wrote:"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wroteLe seul cas où l'appel est remplacé par une valeur immédiate, c'est
avec tous les commutateurs qui vont bien, et si douze est déclarée
inline.
Ça dépend du compilateur. Sans démander une certaine optimisation,
c'est probable qu'elle ne soit jamais générée en ligne. Avec les
meilleurs compilateurs, si le profiler dit que c'est là que ça
coince, le compilateur génèrera la fonction en ligne, même si
l'appel est virtuel, et même si la définition de la fonction se
trouve dans une autre module. (D'accord, d'aussi bons compilateurs
sont rares. Mais ils existent.)
Est-ce que tu as des exemples de tels compilateurs (juste histoire de
compléter ma culture en la matière) ?
kanze@gabi-soft.fr wrote:
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote
Le seul cas où l'appel est remplacé par une valeur immédiate, c'est
avec tous les commutateurs qui vont bien, et si douze est déclarée
inline.
Ça dépend du compilateur. Sans démander une certaine optimisation,
c'est probable qu'elle ne soit jamais générée en ligne. Avec les
meilleurs compilateurs, si le profiler dit que c'est là que ça
coince, le compilateur génèrera la fonction en ligne, même si
l'appel est virtuel, et même si la définition de la fonction se
trouve dans une autre module. (D'accord, d'aussi bons compilateurs
sont rares. Mais ils existent.)
Est-ce que tu as des exemples de tels compilateurs (juste histoire de
compléter ma culture en la matière) ?
wrote:"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wroteLe seul cas où l'appel est remplacé par une valeur immédiate, c'est
avec tous les commutateurs qui vont bien, et si douze est déclarée
inline.
Ça dépend du compilateur. Sans démander une certaine optimisation,
c'est probable qu'elle ne soit jamais générée en ligne. Avec les
meilleurs compilateurs, si le profiler dit que c'est là que ça
coince, le compilateur génèrera la fonction en ligne, même si
l'appel est virtuel, et même si la définition de la fonction se
trouve dans une autre module. (D'accord, d'aussi bons compilateurs
sont rares. Mais ils existent.)
Est-ce que tu as des exemples de tels compilateurs (juste histoire de
compléter ma culture en la matière) ?
Si tu n'appelles la fonction qu'une seule fois, ce n'est pas la
peine de la générer en ligne.
Je ne suis pas tellement d'accord. Si une fonction n'est appelée
qu'une seule fois, cela signifie qu'elle n'est appelée que d'un seul
endroit. Or, générer en ligne une telle fonction n'augmente pas la
taille du code exécutable, au contraire puisque les coûts d'appel et
de retour de la fonction sont supprimés. Si plusieurs fonctions dans
un même programme satisfont ce critère, il est possible que le
bénéfice sur la taille du code et le temps d'exécution ne soit pas
négligeable. AMHA, les fonctions qui ne sont appelées que d'un seul
point (ce qui inclut les fonctions appelées une seule fois) devrait
être systématiquement mises en ligne, et ce indépendamment de leur
taille d'ailleurs.
Si tu n'appelles la fonction qu'une seule fois, ce n'est pas la
peine de la générer en ligne.
Je ne suis pas tellement d'accord. Si une fonction n'est appelée
qu'une seule fois, cela signifie qu'elle n'est appelée que d'un seul
endroit. Or, générer en ligne une telle fonction n'augmente pas la
taille du code exécutable, au contraire puisque les coûts d'appel et
de retour de la fonction sont supprimés. Si plusieurs fonctions dans
un même programme satisfont ce critère, il est possible que le
bénéfice sur la taille du code et le temps d'exécution ne soit pas
négligeable. AMHA, les fonctions qui ne sont appelées que d'un seul
point (ce qui inclut les fonctions appelées une seule fois) devrait
être systématiquement mises en ligne, et ce indépendamment de leur
taille d'ailleurs.
Si tu n'appelles la fonction qu'une seule fois, ce n'est pas la
peine de la générer en ligne.
Je ne suis pas tellement d'accord. Si une fonction n'est appelée
qu'une seule fois, cela signifie qu'elle n'est appelée que d'un seul
endroit. Or, générer en ligne une telle fonction n'augmente pas la
taille du code exécutable, au contraire puisque les coûts d'appel et
de retour de la fonction sont supprimés. Si plusieurs fonctions dans
un même programme satisfont ce critère, il est possible que le
bénéfice sur la taille du code et le temps d'exécution ne soit pas
négligeable. AMHA, les fonctions qui ne sont appelées que d'un seul
point (ce qui inclut les fonctions appelées une seule fois) devrait
être systématiquement mises en ligne, et ce indépendamment de leur
taille d'ailleurs.
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > "Alain Naigeon" writes:
|
| Merci pour ta réponse, il me faut un peu de temps pour
| la digérer. Mais j'ai tout de même une question immédiate :
|
| void f()
| {
| if( false)
| { /*
| ...
| */
| }
|
|
| Est-ce que le langage autorise une optimisation à :
| void f() { }
| ?
As-tu vraiment voulu dire « commentaire » dans la branche de if ?
Si, oui, alors la sémantique dynamique est équivalente effectivement à
void f() { }. Si non, je ne comprends pas ta question. Veux-tu dire
que parce qu'il y a « false », le fragment suivant
void f() { if (false) { toto; } }
où le nom « toto » n'est jamais déclaré doit être considéré valide ?
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le
message
| news: m3y8tdr3l1.fsf@uniton.integrable-solutions.net...
| > "Alain Naigeon" <anaigeon@free.fr> writes:
|
| Merci pour ta réponse, il me faut un peu de temps pour
| la digérer. Mais j'ai tout de même une question immédiate :
|
| void f()
| {
| if( false)
| { /*
| ...
| */
| }
|
|
| Est-ce que le langage autorise une optimisation à :
| void f() { }
| ?
As-tu vraiment voulu dire « commentaire » dans la branche de if ?
Si, oui, alors la sémantique dynamique est équivalente effectivement à
void f() { }. Si non, je ne comprends pas ta question. Veux-tu dire
que parce qu'il y a « false », le fragment suivant
void f() { if (false) { toto; } }
où le nom « toto » n'est jamais déclaré doit être considéré valide ?
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > "Alain Naigeon" writes:
|
| Merci pour ta réponse, il me faut un peu de temps pour
| la digérer. Mais j'ai tout de même une question immédiate :
|
| void f()
| {
| if( false)
| { /*
| ...
| */
| }
|
|
| Est-ce que le langage autorise une optimisation à :
| void f() { }
| ?
As-tu vraiment voulu dire « commentaire » dans la branche de if ?
Si, oui, alors la sémantique dynamique est équivalente effectivement à
void f() { }. Si non, je ne comprends pas ta question. Veux-tu dire
que parce qu'il y a « false », le fragment suivant
void f() { if (false) { toto; } }
où le nom « toto » n'est jamais déclaré doit être considéré valide ?
J'ai vraiment du mal à comprendre ce raisonnement : dès lors
qu'il n'y aura jamais exécution, en quoi la validité est-elle
nécessaire ??
Qu'un compilateur vérifie ce qui peut être exécuté
éventuellement, bravo, c'est ce qu'on attend de lui ; mais de là
à vérifier ce qui, à coup sûr, n'aura jamais la main - et par con-
séquent, n'a pas à être alloué, initialisé, etc - alors là, c'est too
much pour moi ;-) Du moins, la *raison* m'échappe.
J'ai vraiment du mal à comprendre ce raisonnement : dès lors
qu'il n'y aura jamais exécution, en quoi la validité est-elle
nécessaire ??
Qu'un compilateur vérifie ce qui peut être exécuté
éventuellement, bravo, c'est ce qu'on attend de lui ; mais de là
à vérifier ce qui, à coup sûr, n'aura jamais la main - et par con-
séquent, n'a pas à être alloué, initialisé, etc - alors là, c'est too
much pour moi ;-) Du moins, la *raison* m'échappe.
J'ai vraiment du mal à comprendre ce raisonnement : dès lors
qu'il n'y aura jamais exécution, en quoi la validité est-elle
nécessaire ??
Qu'un compilateur vérifie ce qui peut être exécuté
éventuellement, bravo, c'est ce qu'on attend de lui ; mais de là
à vérifier ce qui, à coup sûr, n'aura jamais la main - et par con-
séquent, n'a pas à être alloué, initialisé, etc - alors là, c'est too
much pour moi ;-) Du moins, la *raison* m'échappe.
Il y en a plusieurs : je sais que HP en a un (mais je ne sais pas si
c'est commercialisé ou non),
Il y en a plusieurs : je sais que HP en a un (mais je ne sais pas si
c'est commercialisé ou non),
Il y en a plusieurs : je sais que HP en a un (mais je ne sais pas si
c'est commercialisé ou non),
| Euh... c'est juste syntaxique, la récursivité ?
et surtout lexicale.
Plus généralement, est-ce que
extern bool some_test();
void f() { if (some_test()) f(); }
est un appel récursif ?
La réponse, comme celle donnée avant est oui.
| Je trouve l'exemple astucieux et intéressant, mais c'est
ça dépend, je trouve que l'exemple montre peu de familiarité avec la
récursivité et la théorie des langages ;-)
Considére un langage où un nom ne peut être utilisé que si un binding
(i.e. une association entre ce nom et l'entité qu'il désigne) a été
préalablement établi. Ce qui semble relever du bon sens : si j'utilise
un nom quelque part, je sais exactement ce qu'il désigne et je peux
donner la valeur de ce qu'il désigne.
Eh bin, dans un tel langage il n'est pas possible de définir une
fonction comme
let f x = if (true) true else f(x - 1);
La raison est toute simple : la validité d'une expression est
lexicale.
dans
if (true) true else f(x - 1);
on ne sait pas ce que désigne « f » -- puisqu'on ne lui a pas encore
établi de binding. Note bien qu'ici la seule présence (lexicale) de f fout
tout en l'air.
Pour arriver à faire de la recursivité, il faut un opérateur de point
fixe[1]. Par exemple, « rec » est l'opérateur de point fixe pour les
fonctions dans (O)Caml.
let rec f x = if (true) true else f(x - 1);
[1] un opérateur de point fixe Fix est un opérateur qui satisfait
l'équation
Fix(f) = f(Fix(f)) pour tout f.
| Euh... c'est juste syntaxique, la récursivité ?
et surtout lexicale.
Plus généralement, est-ce que
extern bool some_test();
void f() { if (some_test()) f(); }
est un appel récursif ?
La réponse, comme celle donnée avant est oui.
| Je trouve l'exemple astucieux et intéressant, mais c'est
ça dépend, je trouve que l'exemple montre peu de familiarité avec la
récursivité et la théorie des langages ;-)
Considére un langage où un nom ne peut être utilisé que si un binding
(i.e. une association entre ce nom et l'entité qu'il désigne) a été
préalablement établi. Ce qui semble relever du bon sens : si j'utilise
un nom quelque part, je sais exactement ce qu'il désigne et je peux
donner la valeur de ce qu'il désigne.
Eh bin, dans un tel langage il n'est pas possible de définir une
fonction comme
let f x = if (true) true else f(x - 1);
La raison est toute simple : la validité d'une expression est
lexicale.
dans
if (true) true else f(x - 1);
on ne sait pas ce que désigne « f » -- puisqu'on ne lui a pas encore
établi de binding. Note bien qu'ici la seule présence (lexicale) de f fout
tout en l'air.
Pour arriver à faire de la recursivité, il faut un opérateur de point
fixe[1]. Par exemple, « rec » est l'opérateur de point fixe pour les
fonctions dans (O)Caml.
let rec f x = if (true) true else f(x - 1);
[1] un opérateur de point fixe Fix est un opérateur qui satisfait
l'équation
Fix(f) = f(Fix(f)) pour tout f.
| Euh... c'est juste syntaxique, la récursivité ?
et surtout lexicale.
Plus généralement, est-ce que
extern bool some_test();
void f() { if (some_test()) f(); }
est un appel récursif ?
La réponse, comme celle donnée avant est oui.
| Je trouve l'exemple astucieux et intéressant, mais c'est
ça dépend, je trouve que l'exemple montre peu de familiarité avec la
récursivité et la théorie des langages ;-)
Considére un langage où un nom ne peut être utilisé que si un binding
(i.e. une association entre ce nom et l'entité qu'il désigne) a été
préalablement établi. Ce qui semble relever du bon sens : si j'utilise
un nom quelque part, je sais exactement ce qu'il désigne et je peux
donner la valeur de ce qu'il désigne.
Eh bin, dans un tel langage il n'est pas possible de définir une
fonction comme
let f x = if (true) true else f(x - 1);
La raison est toute simple : la validité d'une expression est
lexicale.
dans
if (true) true else f(x - 1);
on ne sait pas ce que désigne « f » -- puisqu'on ne lui a pas encore
établi de binding. Note bien qu'ici la seule présence (lexicale) de f fout
tout en l'air.
Pour arriver à faire de la recursivité, il faut un opérateur de point
fixe[1]. Par exemple, « rec » est l'opérateur de point fixe pour les
fonctions dans (O)Caml.
let rec f x = if (true) true else f(x - 1);
[1] un opérateur de point fixe Fix est un opérateur qui satisfait
l'équation
Fix(f) = f(Fix(f)) pour tout f.
"Alain Naigeon" writes:
| : dès lors
| qu'il n'y aura jamais exécution, en quoi la validité est-elle
| nécessaire ??
Parce que le fait qu'une instruction soit grammaticallement correcte
est indépendante de ce qu'elle soit effectivement exécutée.
"Alain Naigeon" <anaigeon@free.fr> writes:
| : dès lors
| qu'il n'y aura jamais exécution, en quoi la validité est-elle
| nécessaire ??
Parce que le fait qu'une instruction soit grammaticallement correcte
est indépendante de ce qu'elle soit effectivement exécutée.
"Alain Naigeon" writes:
| : dès lors
| qu'il n'y aura jamais exécution, en quoi la validité est-elle
| nécessaire ??
Parce que le fait qu'une instruction soit grammaticallement correcte
est indépendante de ce qu'elle soit effectivement exécutée.
Gabriel Dos Reis wrote:Pour arriver à faire de la recursivité, il faut un opérateur de point
fixe[1]. Par exemple, « rec » est l'opérateur de point fixe pour les
fonctions dans (O)Caml.
let rec f x = if (true) true else f(x - 1);
C'est dommage, dans les docs OCaml que je viens de lire, les seules
mentions que je vois à rec, c'est du style let f est non récursif, let
rec f l'est, sans plus de détail. :([1] un opérateur de point fixe Fix est un opérateur qui satisfait
l'équation
Fix(f) = f(Fix(f)) pour tout f.
Là, j'ai du mal à concrètiser. Peux-tu pour m'aider à me décrasser les
méninges donner un exemple d'opérateur de point fixe pour les fonctions
de R dans R ?
Gabriel Dos Reis wrote:
Pour arriver à faire de la recursivité, il faut un opérateur de point
fixe[1]. Par exemple, « rec » est l'opérateur de point fixe pour les
fonctions dans (O)Caml.
let rec f x = if (true) true else f(x - 1);
C'est dommage, dans les docs OCaml que je viens de lire, les seules
mentions que je vois à rec, c'est du style let f est non récursif, let
rec f l'est, sans plus de détail. :(
[1] un opérateur de point fixe Fix est un opérateur qui satisfait
l'équation
Fix(f) = f(Fix(f)) pour tout f.
Là, j'ai du mal à concrètiser. Peux-tu pour m'aider à me décrasser les
méninges donner un exemple d'opérateur de point fixe pour les fonctions
de R dans R ?
Gabriel Dos Reis wrote:Pour arriver à faire de la recursivité, il faut un opérateur de point
fixe[1]. Par exemple, « rec » est l'opérateur de point fixe pour les
fonctions dans (O)Caml.
let rec f x = if (true) true else f(x - 1);
C'est dommage, dans les docs OCaml que je viens de lire, les seules
mentions que je vois à rec, c'est du style let f est non récursif, let
rec f l'est, sans plus de détail. :([1] un opérateur de point fixe Fix est un opérateur qui satisfait
l'équation
Fix(f) = f(Fix(f)) pour tout f.
Là, j'ai du mal à concrètiser. Peux-tu pour m'aider à me décrasser les
méninges donner un exemple d'opérateur de point fixe pour les fonctions
de R dans R ?
