Euh là tu montresuniquement que le bytecode est toujours de haut niveau, et que donc le boulot du JIT revient à compiler un code de haut niveau en code natif... comme le compilo Lisaac.
Tu montres tout l'inverse de ce que cherches à démontrer :)
Après on est d'accord, ce ne sont pas les mêmes techniques d'optimisation, etc.
M'enfin ils font quand même la même chose : traduction en code machine d'un code de relativement haut niveau pour l'exécuter ensuite.
Et puis on parle pas que de JIT, on parle également de AOT, où le temps de compilation n'est plus un frein aux optimisations : la phase d'optimisation peut devenir plus proche de celle d'un compilateur ala GCC. C'est tellement vrai avec GCJ...
Oui mais la différence, c'est qu'en JIT, le "compilateur" connais pas mal d'infos car les données sont disponibles, il est en situation, il les as.
Mais comme il ne fait pas d'analyse globale. Ton call on null pète au runtime, pas à la compilation, parce que la compilation te l'empêche intrinsèquement.
En AOT ( http://www.mono-project.com/AOT#Full_AOT ) il fait une optimisation à la SmartEiffel : il regarde les possibilités au niveau statique, e va compiler tous les cas, même si l'arbre d'exécution réel impliquerai que tel ou tel cas n'existerait jamais. C'est la différence entre le compilateur SmartEiffel et Lisaac, qui a été développé dans le même labo que SmartEiffel.
Regarde les limitations : http://www.mono-project.com/AOT#Limitation:_Generic_Interfac(...)
C'est cela qu'on essaye d'éviter avec Lisaac, mais ça a été aussi une stratégie pour des langages comme OCaml.
C'est une philosophie qui consiste à déterminer le maximum d'erreurs potentielles à la compilations. De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
La compilation séparée à ses avantages et ses défauts, tout comme la compilation globale. Néanmoins, modulo le temps de compilation, je pense que tu peux faire en compilation globale ce que tu peux faire en séparé, par exemple en stockant quelques part des infos sur le bout de code compilé en globale, qui serviront lorsqu'on compilera le plugin.
De toutes façons, la compilation globale permet déjà un truc intéressant par rapport à son pendant séparé : tu n'embarques que le code dont tu te sers dans la lib, et question de taille, sur des machines à moins de 256ko, ça a son importance.
Ca n'a aucun rapport. Il y a des projets d'OS en Java ou en C# (et dérivés) : tu peux très bien embarqué tout le bootstrap nécessaire pour lancer ton JIT avec ton OS en bytecode, bref embarqué le runtime comme ca se fait souvent.
Si ça a voir, parce que ta VM doit embarquer un mini OS, c'est elle qui doit gérer les interruptions, la gestion de la mémoire, etc..
Et question taille, mais surtout perf, on a pas le temps de faire du JIT en live.
Vi d'ailleur j'ai jamais bien compris : c'est par flemme que Lisaac utilise le C comme VM ? Non parcque dans mes souvenirs de cours d'optimisation à la fac, il me semble qu'un code écrit en fortran peut par exemple être plus rapide qu'un code écrit en C dans certaines situations : la sémantique fortran permet au compilateur de faire plus d'hypothèses (et donc d'optimisation) alors que le compilo C reste limité, tant la sémantique est permissive...
Je cherches pas à dire que Fortran est plus rapide que le C, mais qu'il paraît bizzare qu'un langage qui cherche les performances comme Lisaac n'est pas un compilateur qui profite de sa connaissance de "haut niveau" de la sémantique du code du développeur pour générer un binaire encore plus optimisé...
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Re..
1) Pourquoi utiliser C (et ce n'est pas une VM : une VM est un programme qui tourne et exécute du code, le C est lui compilé et le code machine ne bouge plus) ?
Au vu du nombre d'architecture différentes existantes, et du nombre de règle d'optimisations très complexes des processeurs modernes, il aurait été stupide et surtout titanesque, de générer de l'assembleur. C'est pour cela que Dominique Colnet, lorsqu'il a commencé SmartEiffel (car ça vient de lui), a décidé d'utiliser un assembleur portable : le langage C.
L'idée consiste à générer un C très bas niveau, gérant une arithmétique de pointeurs très proche de la machine.
2) On en vient donc à pourquoi C et par Fortran ?
C est un langage doté de compilateur performant, disponible sur énormément de machine, et c'est sur ces compilateurs que tous les efforts sont effectués pour générer un assembleur le plus optimisé possible.
GCC connait les règles spécifiques à chaque processeurs : Athlon Thunderbird, Core Duo 1 et 2, AMD64, Arm thumb, etc...
La machine virtuelle java le fait aussi d'ailleurs.
On peut tout à fait être aussi voire plus performant qu'un code fortran si l'on écrit son code C d'une certaine façon (en faisant un code C qui ressemble.. à du fortran : pas trop de pointeurs, etc...).
Le projet GCC l'explique sur cette page : http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Pas vectorisable :
while (*p != NULL) {
*q++ = *p++;
}
Vectorisable :
for (k = 0; k < K; k++) {
sum = 0;
for (j = 0; j < M; j++)
for (i = 0; i < N; i++)
sum += in[i+k][j] * coeff[i][j];
out[k] = sum;
}
Il y est décrit comment écrire son code C, mais aussi quelle forme de code sont à éviter pour que le compilateur puisse optimiser au mieux et utiliser MMX, SSE, et dans le futur Larabee.
On a juste à faire attention à ce que le compilateur génère du code parfaitement conforme à ces normes, et on a ainsi un code parfaitement optimisé.
Il y a d'autres techniques comme utiliser automatiquement la lib oil, et autres système.
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Même sur processeur Intel, j'en mettrais pas ma main à couper. GCC est travaillé au corps par pas mal d'universitaires, et ICC est souvent au coude à coude avec GCC.
De toutes façon on s'en fiche, le code peut être compilé par ICC aussi...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Tu montres tout l'inverse de ce que cherches à démontrer :)
Après on est d'accord, ce ne sont pas les mêmes techniques d'optimisation, etc.
M'enfin ils font quand même la même chose : traduction en code machine d'un code de relativement haut niveau pour l'exécuter ensuite.
Et puis on parle pas que de JIT, on parle également de AOT, où le temps de compilation n'est plus un frein aux optimisations : la phase d'optimisation peut devenir plus proche de celle d'un compilateur ala GCC. C'est tellement vrai avec GCJ...
Oui mais la différence, c'est qu'en JIT, le "compilateur" connais pas mal d'infos car les données sont disponibles, il est en situation, il les as.
Mais comme il ne fait pas d'analyse globale. Ton call on null pète au runtime, pas à la compilation, parce que la compilation te l'empêche intrinsèquement.
En AOT ( http://www.mono-project.com/AOT#Full_AOT ) il fait une optimisation à la SmartEiffel : il regarde les possibilités au niveau statique, e va compiler tous les cas, même si l'arbre d'exécution réel impliquerai que tel ou tel cas n'existerait jamais. C'est la différence entre le compilateur SmartEiffel et Lisaac, qui a été développé dans le même labo que SmartEiffel.
Regarde les limitations : http://www.mono-project.com/AOT#Limitation:_Generic_Interfac(...)
C'est cela qu'on essaye d'éviter avec Lisaac, mais ça a été aussi une stratégie pour des langages comme OCaml.
C'est une philosophie qui consiste à déterminer le maximum d'erreurs potentielles à la compilations. De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
La compilation séparée à ses avantages et ses défauts, tout comme la compilation globale. Néanmoins, modulo le temps de compilation, je pense que tu peux faire en compilation globale ce que tu peux faire en séparé, par exemple en stockant quelques part des infos sur le bout de code compilé en globale, qui serviront lorsqu'on compilera le plugin.
De toutes façons, la compilation globale permet déjà un truc intéressant par rapport à son pendant séparé : tu n'embarques que le code dont tu te sers dans la lib, et question de taille, sur des machines à moins de 256ko, ça a son importance.
Ca n'a aucun rapport. Il y a des projets d'OS en Java ou en C# (et dérivés) : tu peux très bien embarqué tout le bootstrap nécessaire pour lancer ton JIT avec ton OS en bytecode, bref embarqué le runtime comme ca se fait souvent.
Si ça a voir, parce que ta VM doit embarquer un mini OS, c'est elle qui doit gérer les interruptions, la gestion de la mémoire, etc..
Et question taille, mais surtout perf, on a pas le temps de faire du JIT en live.
Vi d'ailleur j'ai jamais bien compris : c'est par flemme que Lisaac utilise le C comme VM ? Non parcque dans mes souvenirs de cours d'optimisation à la fac, il me semble qu'un code écrit en fortran peut par exemple être plus rapide qu'un code écrit en C dans certaines situations : la sémantique fortran permet au compilateur de faire plus d'hypothèses (et donc d'optimisation) alors que le compilo C reste limité, tant la sémantique est permissive...
Je cherches pas à dire que Fortran est plus rapide que le C, mais qu'il paraît bizzare qu'un langage qui cherche les performances comme Lisaac n'est pas un compilateur qui profite de sa connaissance de "haut niveau" de la sémantique du code du développeur pour générer un binaire encore plus optimisé...
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Re..
1) Pourquoi utiliser C (et ce n'est pas une VM : une VM est un programme qui tourne et exécute du code, le C est lui compilé et le code machine ne bouge plus) ?
Au vu du nombre d'architecture différentes existantes, et du nombre de règle d'optimisations très complexes des processeurs modernes, il aurait été stupide et surtout titanesque, de générer de l'assembleur. C'est pour cela que Dominique Colnet, lorsqu'il a commencé SmartEiffel (car ça vient de lui), a décidé d'utiliser un assembleur portable : le langage C.
L'idée consiste à générer un C très bas niveau, gérant une arithmétique de pointeurs très proche de la machine.
2) On en vient donc à pourquoi C et par Fortran ?
C est un langage doté de compilateur performant, disponible sur énormément de machine, et c'est sur ces compilateurs que tous les efforts sont effectués pour générer un assembleur le plus optimisé possible.
GCC connait les règles spécifiques à chaque processeurs : Athlon Thunderbird, Core Duo 1 et 2, AMD64, Arm thumb, etc...
La machine virtuelle java le fait aussi d'ailleurs.
On peut tout à fait être aussi voire plus performant qu'un code fortran si l'on écrit son code C d'une certaine façon (en faisant un code C qui ressemble.. à du fortran : pas trop de pointeurs, etc...).
Le projet GCC l'explique sur cette page :
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Pas vectorisable :
while (*p != NULL) {
*q++ = *p++;
}
Vectorisable :
for (k = 0; k < K; k++) {
sum = 0;
for (j = 0; j < M; j++)
for (i = 0; i < N; i++)
sum += in[i+k][j] * coeff[i][j];
out[k] = sum;
}
Il y est décrit comment écrire son code C, mais aussi quelle forme de code sont à éviter pour que le compilateur puisse optimiser au mieux et utiliser MMX, SSE, et dans le futur Larabee.
On a juste à faire attention à ce que le compilateur génère du code parfaitement conforme à ces normes, et on a ainsi un code parfaitement optimisé.
Il y a d'autres techniques comme utiliser automatiquement la lib oil, et autres système.
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Même sur processeur Intel, j'en mettrais pas ma main à couper. GCC est travaillé au corps par pas mal d'universitaires, et ICC est souvent au coude à coude avec GCC.
De toutes façon on s'en fiche, le code peut être compilé par ICC aussi...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker