Le fait que, ces services soient pour le moment offerts sur des machines virtuelles prouvent que compiler la même chose est trop compliqué
Je me tue à t'expliquer qu'une plateforme comme Mono tu produits un code compilé en natif et qui s'exécute comme tout autre exécutable générés par un compilateur traditionnel ! Donc oui c'est possible, mono le fait. GCJ aussi, .NET ngen aussi.
Si ces services sont associés à une machine virtuelle, c'est qu'il est impossible d'offrir les mêmes services associés au jeu d'instruction des machines physiques que nous connaissons, il est donc nécessaire d'introduire une couche d'abstraction purement virtuelle mais offrant un ensemble de services/instructions cohérent et intégré.
Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur.
Si tu veux, et moi j'essai justement de t'expliquer qu'avec des environnement modernes comme Mono, ce n'est plus comme ca que ca marche :)
En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.
Toutafé. Un programme compilé en code natif dès le départ (ala C) a ce problème. Mais c'est là que le fait de retarder la dernière étape de compilation au dernier moment (JIT) apporte une grande souplesse : on peut compiler à l'avance, mais aussi le faire "en live", la refaire si nécessaire, etc.
Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.
Oué ca c'est cool, mais j'ai l'impression que tu n'as qu'un objectif : les performances. Ce après quoi court Lisaac (avec aussi bien sûr quelques paradigmes objets originaux et une meilleure abstraction), mais en laissant de côté tous les services qu'offrent les plateformes modernes de style .NET/Mono. Sans doute parcque ce n'est pas la même utilisation visée.
Ah oui, et puis bon, je sais pas si ca sert à grand chose de se "prendre" le choux pour obtenir des gains de performances générales sur l'ensemble d'un programme qui vont s'évaluer à quelques pourcent de temps d'exécution... A mon avis, à l'heure actuelle si tu veux améliorer les perfs va falloir "inventer" un langage où les concepts de parrallèlismes seront simples à appréhender et à utiliser. Je ne parle pas de la parrallèlisation automatique qui sera toujours limités, je parle d'offrir une sémantique élégante et intuitive au programmeur. Il y a de nombreux essais, mais je n'ai pas encore trouvé de langage vraiment convaincant...
PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir,
C'était juste une question pour savoir où ca en était... Pour la libération de LisaacOS, franchement, perso je m'en tape royalement si les outils pour le compiler ne le sont pas...
[^] # Re: Le passage Mono dans le document
Posté par TImaniac (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 2.
Je me tue à t'expliquer qu'une plateforme comme Mono tu produits un code compilé en natif et qui s'exécute comme tout autre exécutable générés par un compilateur traditionnel ! Donc oui c'est possible, mono le fait. GCJ aussi, .NET ngen aussi.
Si ces services sont associés à une machine virtuelle, c'est qu'il est impossible d'offrir les mêmes services associés au jeu d'instruction des machines physiques que nous connaissons, il est donc nécessaire d'introduire une couche d'abstraction purement virtuelle mais offrant un ensemble de services/instructions cohérent et intégré.
Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur.
Si tu veux, et moi j'essai justement de t'expliquer qu'avec des environnement modernes comme Mono, ce n'est plus comme ca que ca marche :)
En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.
Toutafé. Un programme compilé en code natif dès le départ (ala C) a ce problème. Mais c'est là que le fait de retarder la dernière étape de compilation au dernier moment (JIT) apporte une grande souplesse : on peut compiler à l'avance, mais aussi le faire "en live", la refaire si nécessaire, etc.
Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.
Oué ca c'est cool, mais j'ai l'impression que tu n'as qu'un objectif : les performances. Ce après quoi court Lisaac (avec aussi bien sûr quelques paradigmes objets originaux et une meilleure abstraction), mais en laissant de côté tous les services qu'offrent les plateformes modernes de style .NET/Mono. Sans doute parcque ce n'est pas la même utilisation visée.
Ah oui, et puis bon, je sais pas si ca sert à grand chose de se "prendre" le choux pour obtenir des gains de performances générales sur l'ensemble d'un programme qui vont s'évaluer à quelques pourcent de temps d'exécution... A mon avis, à l'heure actuelle si tu veux améliorer les perfs va falloir "inventer" un langage où les concepts de parrallèlismes seront simples à appréhender et à utiliser. Je ne parle pas de la parrallèlisation automatique qui sera toujours limités, je parle d'offrir une sémantique élégante et intuitive au programmeur. Il y a de nombreux essais, mais je n'ai pas encore trouvé de langage vraiment convaincant...
PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir,
C'était juste une question pour savoir où ca en était... Pour la libération de LisaacOS, franchement, perso je m'en tape royalement si les outils pour le compiler ne le sont pas...