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.
Euh, le call on null ca serait pas fait par le JIT dans ce cas, mais par le compilateur en amont. De la même manière que c'est le compilateur Lisaac et pas GCC qui s'en occupe...
Cette limitation vient de l'implémentation de Mono, pas du modèle sous-jacent, le compilateur AOT de .NET n'a pas cette limitation.
Ensuite je vois pas pourquoi tu parles de ça...
De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
Garantie possible... uniquement si tu ne fait pas appel à des modules externes.
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
Toutafé, on est d'accord. Les avantages sont indéniables, la question est de savoir si le jeu en vaut la chandelle au regard des inconvénients. Cela est d'autant plus bizzare vu la cible : embarqué, OS : jamais de code assembleur ? jamais de code externe ? jamais de drivers binaires ? Bref, combien de projet où le compilateur pourra vraiment offrir une garantie (ce qui suppose que tout soit codé en Lisaac et que toutes les sources soient compilées en même temps) ?
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.
Bref, c'est donc bien possible. Comme déjà expliqué, la présence d'une VM n'implique pas JIT : on peut faire de l'AOT. Mais oui, niveau perf les services apportés par ces VM a souvent un impact négatif c'est clair.
Mais dans tout les cas ca reste tout à fait possible, CQFD.
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
Non non non et non. Une VM n'est pas un programme. Une VM c'est une machine virtuelle, une représentation abstraite sous la forme d'un jeu d'instruction d'une machine qui n'existe pas. C'est une confusion classique : on assimile une VM au runtime et son moteur JIT. Pourtant la technique AOT montre clairement que le bytecode est "lui compilé et le code machine ne bouge plus". C'est exactement pareil.
et surtout titanesque, de générer de l'assembleur.
Ok c'est bien un problème de moyen.
Maintenant moi j'ai une question : comment offrez-vous l'accès aux instructions spécifiques des processeurs modernes ? SSE & co ? Les unités de calculs vectorielles toussa ? En dehors des optimisations de base offertes par GCC, il est souvent très utile d'aller directement utiliser les instructions processeurs quand c'est vraiment les perfs que l'on recherche...
En résumé je trouve ce paradoxe assez étonnant : un des atouts de Lisaac, ce sont les perfs, et en même temps, vous limitez intrinséquement les perfs de Lisaac à la VM exposée par le langage C, autrement dit pas d'optimisation possible en dehors de cette VM... Lisaac est condamné à être aussi "lent" que le langage C "standard".
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 1.
Euh, le call on null ca serait pas fait par le JIT dans ce cas, mais par le compilateur en amont. De la même manière que c'est le compilateur Lisaac et pas GCC qui s'en occupe...
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.
Cette limitation vient de l'implémentation de Mono, pas du modèle sous-jacent, le compilateur AOT de .NET n'a pas cette limitation.
Ensuite je vois pas pourquoi tu parles de ça...
De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
Garantie possible... uniquement si tu ne fait pas appel à des modules externes.
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
Toutafé, on est d'accord. Les avantages sont indéniables, la question est de savoir si le jeu en vaut la chandelle au regard des inconvénients. Cela est d'autant plus bizzare vu la cible : embarqué, OS : jamais de code assembleur ? jamais de code externe ? jamais de drivers binaires ? Bref, combien de projet où le compilateur pourra vraiment offrir une garantie (ce qui suppose que tout soit codé en Lisaac et que toutes les sources soient compilées en même temps) ?
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.
Bref, c'est donc bien possible. Comme déjà expliqué, la présence d'une VM n'implique pas JIT : on peut faire de l'AOT. Mais oui, niveau perf les services apportés par ces VM a souvent un impact négatif c'est clair.
Mais dans tout les cas ca reste tout à fait possible, CQFD.
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
Non non non et non. Une VM n'est pas un programme. Une VM c'est une machine virtuelle, une représentation abstraite sous la forme d'un jeu d'instruction d'une machine qui n'existe pas. C'est une confusion classique : on assimile une VM au runtime et son moteur JIT. Pourtant la technique AOT montre clairement que le bytecode est "lui compilé et le code machine ne bouge plus". C'est exactement pareil.
et surtout titanesque, de générer de l'assembleur.
Ok c'est bien un problème de moyen.
Maintenant moi j'ai une question : comment offrez-vous l'accès aux instructions spécifiques des processeurs modernes ? SSE & co ? Les unités de calculs vectorielles toussa ? En dehors des optimisations de base offertes par GCC, il est souvent très utile d'aller directement utiliser les instructions processeurs quand c'est vraiment les perfs que l'on recherche...
En résumé je trouve ce paradoxe assez étonnant : un des atouts de Lisaac, ce sont les perfs, et en même temps, vous limitez intrinséquement les perfs de Lisaac à la VM exposée par le langage C, autrement dit pas d'optimisation possible en dehors de cette VM... Lisaac est condamné à être aussi "lent" que le langage C "standard".