IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Mozilla, Fastly, Intel et Red Hat lancent l'Alliance Bytecode, une initiative construite autour de WebAssembly
Qui propose d'apporter plus de sécurité, d'ubiquité et d'interopérabilité sur le Web

Le , par Christian Olivier

70PARTAGES

11  0 
Dans un effort commun visant à faire de WebAssembly un runtime informatique multiplateforme, les entreprises Mozilla, Fastly, Intel et Red Hat ont annoncé le lancement de l’Alliance Bytecode. Cette initiative architecturée autour de WebAssembly est axée sur la fourniture d’un bytecode sécurisé par défaut qui peut être exécuté depuis un navigateur Web, un ordinateur de bureau ou une plateforme IoT/embarquée.


Pour rappel, WebAssembly a été présenté comme une architecture de jeu d’instructions virtuel avec de nombreux cas d’utilisation capable de prendre du code écrit dans des langages de programmation autres que JavaScript et d’exécuter ce code sur une plateforme spécifique – du moins à l’origine -, un navigateur en l’occurrence. Cette solution devrait également permettre aux applications complexes - telles que les jeux vidéo immersifs en 3D, le design informatisé ou l’édition d’images et de vidéos - de fonctionner de façon optimale sur les plateformes cibles. Grâce à WebAssembly, des développeurs seraient par exemple en mesure de coder leurs applications en C, C++ ou en Rust et de faire exécuter ces programmes à la vitesse native sur un navigateur Web, sans avoir à repasser par JavaScript avec les contraintes que cela impose.

Selon les promoteurs l’initiative, la montée en puissance du Cloud et des périphériques IoT fait que les développeurs exécutent du code non fiable dans de nouveaux environnements, ce qui soulève de nouveaux problèmes, notamment en matière de sécurité et de portabilité. L’Alliance Bytecode devra fournir une base permettant aux développeurs d’exécuter en toute confiance du code non fiable sur n’importe quelle infrastructure, système d’exploitation et périphérique. Cette communauté open source se focalisera sur la mise en place d’un environnement d’exécution et de chaînes d’outils linguistiques associées – incluant cargo-wasi, wat et wasmparser – qui offrent sécurité, efficacité et modularité sur une large gamme d’architectures et de périphériques. Le projet devrait s’appuyer sur les normes existantes telles que WebAssembly et WebAssembly System Interface (WASI).

Les nanoprocessus de WebAssembly

WebAssembly peut fournir le type d’isolation qui permet d’exécuter en toute sécurité du code non fiable, grâce à une architecture similaire aux nombreux petits processus d’Unix, ou aux conteneurs et aux microservices. Toutefois, cet isolement est beaucoup plus léger et la communication entre les nanoprocessus de WebAssembly ne souffre d’aucune réduction de performance, au contraire. Cela signifie que vous pouvez les utiliser pour empaqueter une seule instance de module WebAssembly ou une petite collection d’instances de module qui veulent partager des choses comme la mémoire entre eux. De plus, vous n’avez pas besoin d’abandonner le langage de programmation, comme les signatures de fonctions et le contrôle de type statique.


Cette propriété est due au fait que chaque module WebAssembly est sandboxé par défaut ainsi qu’à la particularité de l’architecture mémoire. En effet, chaque module WebAssembly n’a pas accès à la totalité de la mémoire dans son processus - uniquement au bloc de mémoire qui lui a été assigné et qui est isolé du reste du pool -. En parallèle, grâce à une fonctionnalité introduite en aout dernier sur WebAssembly - les types d’interfaces -, il est facile pour deux modules d’échanger des données, mais toujours de façon sécurisée et rapide, et le moteur de WebAssembly permet d’effectuer des copies directes au niveau de la mémoire. Ces opérations fonctionnent même si les deux modules ne sont pas compilés à partir du même langage.


Malheureusement, la façon dont la plupart des systèmes d’exploitation gèrent l’accès au système de fichiers n’offre pas forcément un niveau de sécurité optimal et il ne suffit pas de prendre des précautions vis-à-vis de la gestion mémoire entre les modules WabAssembly pour que tout soit parfaitement sécurisé. Il faut aller encore plus loin et s’intéresser aux API et aux appels système qui intègrent « ;le concept de permission ;», de sorte qu’ils puissent octroyer différentes permissions à différents modules et différentes ressources. C’est là qu’intervient la fonctionnalité baptisée WASI (WebAssembly system interface) qui permet d’isoler ces différents modules les uns des autres, de leur octroyer avec précision des permissions bien spécifiques et de verrouiller le système.

Malgré tout, le système n’est pas encore au point, les développeurs en charge du projet ayant eux-mêmes reconnu que pour l’instant, ils n’ont trouvé aucun moyen de faire passer les clés de contrôle du système par l’arbre des dépendances. À ce sujet, ils ont confié : « ;Nous avons besoin d’un moyen pour permettre aux modules parents de donner ces clés à leurs dépendances. De cette façon, ils peuvent donner à leurs dépendances exactement les clés dont ils ont besoin et aucune autre. Et puis, ces dépendances peuvent faire la même chose pour leurs enfants, jusqu’au bout de l’arbre ;». Mais ils comptent bien s’attaquer à cet ultime défi. Sur le plan technique, ils prévoient d’utiliser une forme de virtualisation granulaire par module. L’idée est de fournir un écosystème WebAssembly sécurisé par défaut pour toutes les plateformes qui pourra protéger efficacement contre les codes malveillants ou les vulnérabilités inhérentes au code, par exemple.

L’avis des promoteurs du projet

Luke Wagner, un ingénieur chez Mozilla, a expliqué à ce propos : « ;Le standard WebAssembly est en train de transformer le Web et nous pensons qu’il peut jouer un rôle encore plus important au sein de l’écosystème des logiciels, en se développant au-delà des navigateurs. C’est un moment unique pour cette nouvelle technologie, car nous avons l’occasion de réparer ce qui est obsolète et d’établir, pour un développement natif, de nouvelles fondations sécurisées par défaut, mobiles et évolutives. Nous devons toutefois prendre des mesures réfléchies et à travers l’industrie pour nous assurer que ces mesures sont bien appliquées ;».


De son côté Mark Skarpness, vice-président de la division Architecture, Graphiques et Logiciels d’Intel a déclaré : « ;Intel rejoint l’Alliance Bytecode en tant que membre fondateur afin d’offrir à un large éventail d’applications et de serveurs de meilleures performances et une sécurité renforcée de l’environnement WebAssembly, en allant au-delà du navigateur. Les technologies de l’alliance Bytecode peuvent aider les développeurs à faire évoluer les logiciels en utilisant une multitude de langages et en s’appuyant sur toutes les capacités des plateformes de calcul de dernière génération ;».

Chris Wright, Senior Vice-President et Chief Technology Officer chez Red Hat, estime quant à lui que « ;les technologies Open Source jouent un rôle important dans la mise en place des fondations informatiques, du système d’exploitation au navigateur en passant par des clouds hybrides ouverts ;». Il a ajouté : « ;Nous sommes heureux de participer avec nos partenaires à son évolution vers un projet mature et entièrement communautaire ;».


Un certain nombre de projets open source ont été apportés à ce projet par les différents membres. Il s’agit notamment de :
  • Wasmtime, un environnement d’exécution léger et performant pour WebAssembly et WASI ;;
  • Lucet, un environnement d’exécution avec compilation hors ligne pour WebAssembly et WASI axé sur les applications à faible latence et à haute concurrence ;;
  • WebAssembly Micro Runtime (WAMR), un environnement d’exécution WebAssembly basé sur un interpréteur pour les périphériques embarqués ;;
  • Cranelift, un générateur de code multiplateforme qui met l’accent sur la sécurité et la performance, écrit en Rust.


Source : Mozilla, Alliance ByteCode

Et vous ?

Que pensez-vous de cette initiative ?

Voir aussi

Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
RustPython, un interpréteur Python écrit en Rust et compatible avec WebAssembly, est disponible, pourrait-il rivaliser avec CPython ?
Mozilla finance un portage de Julia en WebAssembly afin d'effectuer des calculs lourds au sein du navigateur

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Captain Spic
Membre à l'essai https://www.developpez.com
Le 01/05/2021 à 0:35
C'est assez déprimant quand tu tombes sur un article cool, sur une technologie cool qui a un potentiel assez énorme, et qu'en dessous, il y a deux commentaires archi négatifs et ce sans justifications valables...

Il faut savoir que Java et .NET, qui sont les deux grosses références en terme d'exécution au travers de bytecode, n'ont jamais réussi à fédérer plus de communautés que la leur.
Avec WASM, on peut dire qu'il y a eu un engouement certain de la part d'à peu près toute les communautés, y compris chez ces deux compères (la liste des projets de compilation vers WASM).

Déjà à la base le projet est assez génial puisque qu'il permet à n'importe quel langage de pouvoir rivaliser avec JavaScript et sa fullstack.
Les aficionado du C++ pourront donc utiliser leur langage de prédilection pour exécuter du code côté client.
Du coup, même ceux qui haïssent JavaScript, devraient être content : ils n'ont plus besoin de l'utiliser pour monter une application web !

Et maintenant, c'est encore mieux, puisque les enseignements appris chèrement avec l'évolution des usages du web, dont WASM hérite vont pouvoir déborder du web et en faire profiter le développement "natif".
(En plus de pouvoir faire communiquer deux langages différents de manière plus simples et efficace et ce, peu importe la plateforme.

Franchement, le potentiel est là et vu les efforts investis on peut espérer de belles choses à l'avenir !
Enfin bref, ça vaut vraiment pas le coup de venir rager
6  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/05/2021 à 8:42
Citation Envoyé par archqt Voir le message
En gros c'est du "ByteCode" qui est exécuté. Par contre la vitesse native, non, ça ne pourra jamais aller aussi vite que des instructions assembleur. Sauf si bien sûr le byte code est retraduit en instruction assembleur avant .
Je suppose que c'est cela qui est fait, du moins ce que je ferais moi, un code intermédiaire comme celui qui sort de LLVM, puis une traduction de cet assembleur universel vers l'assembleur de la cible.

Par contre s'il y a GC on aura forcément des pertes par rapport à une application pure C/C++/Rust par exemple.
Justement, un gros avantage de WASM par rapport à JavaScript, c'est qu'il n'impose pas de notions de haut niveau comme un GC ou un typage dynamique. Un WASM produit à partir d'un langages de type C, C++ ou Rust peut donc théoriquement être compilé en quelque-chose de relativement similaire.
Dans la pratique il y a quand même des écarts dus à certaines contraintes de sécurité, indispensables pour des code tiers téléchargés à la volée (protection contre les buffer overflow et les failles de type spectre notamment). De plus les compilateurs WASM, vont généralement, dans un premier temps, ne pas optimiser autant qu'ils le pourraient pour privilégier la vitesse de compilation et donc leur permettre de démarrer l’exécution quasi immédiatement, ce qui est généralement ce que l'on attend dans un contexte web. Seul les codes relativement couteux en temps d’exécution seront recompilés avec les meilleures optimisations.

Le fonctionnement général du Wasm est en effet comparable au LLVM IR. Avec son projet pNaCL, Google souhaitait d'utiliser directement le LLVM IR comme bytecode, Mozilla de son coté, avec asm.js, proposait d'utiliser un sous-ensemble de JavaScript. Wasm est né de la mise en commun de leurs idées d'une manière plus propre, avec bytecode spécifiquement conçu pour être adapté aux contraintes du Web. Comparé à ces représentations intermédiaires, il est plus indépendant de la plateforme, plus compact a télécharger, plus rapide a compiler, plus sécurisé.

Citation Envoyé par SimonDecoline Voir le message
Quels enseignements par exemple ?
J'ai plutôt l'impression que le web frontend a perdu du temps à refaire ce qui existait déjà dans le natif.
En effet, mais dans le cadre d'une exécution dans le navigateur il y a des contraintes de portabilité et de sécurité qui sont ignorées par les développeurs natif, d'où la catastrophe ActiveX.
Les Applets ont été la première tentative de résoudre le problème d'exécution dans le navigateur mais elle ont échoué pour des raisons à la fois techniques, et politiques. Techniquement, ça imposait une architecture trop contraignante, trop liée au langage Java lui même, pas assez orienté vers les performances. Politiquement, Java n'a jamais cherché a être une norme du web, c'est resté un produit appartenant à Sun, mal intégré. L'opposition a peine cachée de Microsoft n'a rien arrangé.
Il y a eu d'autres tentatives, comme Flash, Active X, NaCL, asm.js,... qui péchaient toutes plus ou moins a différents niveaux : intégration, portabilité, sécurité, ... pour la simple et bonne raison que c'était des initiatives poussées par des acteurs externes qui fournissaient une solution taillée pour leur propres objectifs et pas le Web en général.

Webassembly est vraiment une action commune des principaux acteurs du Web, bâtie sur l'expérience de ces projets et qui vise a traiter au mieux les besoin d'un bytecode du Web et qui a été penser pour traiter au mieux à la fois les problématiques de performance, de portabilité, de sécurité et d'intégration a l'écosystème Web.
4  0 
Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 13/11/2019 à 17:28
Citation Envoyé par Bardotj Voir le message
Avons nous rééllement besoin de web assembly ?

Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
Le WebAssembly est plus performant que le javascript qui est utilisé avec Electron pour faire des applis bureau.
Des virus sont fait en C ou C++, doit-on bannir ces langages pour autant.

Pour les perfs on utilise un paquet de langage moins performant que le natif pour faire des applis de bureau, à part si le but est d'avoir l'appli la plus performante (style jeux AAA, montage photo/video ...).
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 14/11/2019 à 10:14
Citation Envoyé par Bardotj Voir le message
Avons nous rééllement besoin de web assembly ?
Avons nous besoin d'un ordinateur ? Pour survivre, non. Pour programmer, oui.
Avons nous besoin de WebAssembly ? Pour programmer, non. Pour avoir un bytecode efficace, securisé et adapté a de multiple langages, oui.

Citation Envoyé par Bardotj Voir le message
Le WebAssembly serait moins performant en terme de rapidité que le code natif, selon les résultats d'une étude
Pas besoin de faire une étude pour savoir ça. WebAssembly est un bytecode adapté pour avoir de bonnes performances, particulièrement avec les langages stricts, mais il a des contraintes de sécurité qui font qu'il ne pourra pas à 100% au niveau du natif non sécurisé. Mais par rapport au JS les gains sont indéniables.
Il faut aussi voir que les VM des navigateurs privilégient actuelement la vitesse de compilation aux performances. C'est logique pour le web où on ne veut pas attendre au chargement de la page. Mais pour une utilisation en tant qu'application lourde comme le prévoit la Bytecode Alliance, les performances seront certainement privilégiées.

Citation Envoyé par Bardotj Voir le message
50 % des sites web utilisent WebAssembly à des fins malveillantes, selon une étude de la Technische Universität Braunschweig
Pour des choses qui seraient de toute façon faites en JavaScript si le WebAssembly n'existait.
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 01/05/2021 à 7:33
Citation Envoyé par Jeff_67 Voir le message
Le point faible du web, c'est JavaScript. Or avec WebAssembly, il n'est à ma connaissance pas possible d'interagir avec le navigateur sans passer par un bout de code JavaScript.
Pour le moment juste une petite partie des API Web est disponible directement (principalement Canevas et webgl), mais a terme toute les API du navigateur devraient être accessibles sans passer par JavaScript. Le souci pour le moment c'est que la plupart des API comme le DOM utilisent des objets qui sont managé par le Garbage Collector du navigateur. Donc avant de les rendre disponible, il faut rendre WASM capable d'interagir avec le GC ce qui nécessite encore des travaux
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/05/2021 à 10:56
Citation Envoyé par Madmac Voir le message
- Parce que le passé est garant de l'avenir.
C'est juste une jolie phrase taillée pour la philosophie de comptoir, mais dans la pratique sans aucun fondement. En réalité, le passé est rarement le garant de l'avenir, car les situations ne se représentent quasiment jamais deux fois a l'identique. C'est particulièrement vrai dans le cas qui nous concerne.

Citation Envoyé par Madmac Voir le message
Si Microsoft est impliqué, tu peux est certain que cela va finir en eau de boudin. Microsoft est sectaire.
La situation actuelle de WASM n'a pas grand chose a voir avec l'époque de Active X dans le navigateur. Les technologies sont sensiblement différentes et surtout, Microsoft n'est pas maitre a bord, c'est juste un membre parmi d'autre. De plus et il n'a pas de position particulièrement dominante, sur le domaine visé par Wasi (serveur et IOT), il est même plutôt un outsider. Même au niveau du contrôle des techno Web, il s'est fait voler sa position par Google.

Citation Envoyé par SimonDecoline Voir le message
Oui d'accord mais tout ça, ça reste spécifique au web/navigateur. Ma question était sur les "enseignements du web frontend qui vont faire profiter le dev natif".
En effet, sous cet angle là, l'intérêt est carrément discutable : le natif à déjà récupéré depuis longtemps ce qu'il avait à récupérer du front (xaml, styles,... ), il n'y a pas vraiment besoin de Wasm pour ça.
L'interet de Wasm hors du web, c'est plutôt pour avoir un système de sandbox plus léger qu'avec la virtualisation ou un conteneur.
2  0 
Avatar de Madmac
Membre extrêmement actif https://www.developpez.com
Le 03/05/2021 à 21:04
Citation Envoyé par Uther Voir le message
C'est juste une jolie phrase taillée pour la philosophie de comptoir, mais dans la pratique sans aucun fondement. En réalité, le passé est rarement le garant de l'avenir, car les situations ne se représentent quasiment jamais deux fois a l'identique. C'est particulièrement vrai dans le cas qui nous concerne.
Pas du tout

par exemple
Code : Sélectionner tout
1
2
3
4
5
begin
File.open("./planets.ini").each { |planetname| planets_temp.append( planetname) }
rescue SystemCallError => e
   print "Error: ./planets.ini missing, loading default values."
end
Ce code fonctionne sous Mac et Linux, mais pas sous Microsoft. Vois-tu voir pourquoi? Et leur foutu terminal qui ne comprend pas NCurses.

Citation Envoyé par Uther Voir le message

La situation actuelle de WASM n'a pas grand chose a voir avec l'époque de Active X dans le navigateur. Les technologies sont sensiblement différentes et surtout, Microsoft n'est pas maitre a bord, c'est juste un membre parmi d'autre. De plus et il n'a pas de position particulièrement dominante, sur le domaine visé par Wasi (serveur et IOT), il est même plutôt un outsider. Même au niveau du contrôle des techno Web, il s'est fait voler sa position par Google.
La similarité est qu'ils vont pouvoir écrire autre chose que des cookies sur ton disque . Et cela représente un énorme problème. Et mème Microsoft n'est qu'un joueur parmi les autres, je n'ai qu'à penser à Explorer pour imaginer les milles et une façon d'empoisonner ce projet.

Citation Envoyé par Uther Voir le message

En effet, sous cet angle là, l'intérêt est carrément discutable : le natif à déjà récupéré depuis longtemps ce qu'il avait à récupérer du front (xaml, styles,... ), il n'y a pas vraiment besoin de Wasm pour ça.
L'interet de Wasm hors du web, c'est plutôt pour avoir un système de sandbox plus léger qu'avec la virtualisation ou un conteneur.
Là j'ai du mal à te suivre. Pour le moment Wasm se limite à Javascript. Alors un navigateur suffit. Et coté serveur Node te permet tester ton code.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/05/2021 à 23:10
Citation Envoyé par Madmac Voir le message
Ce code fonctionne sous Mac et Linux, mais pas sous Microsoft. Vois-tu voir pourquoi? Et leur foutu terminal qui ne comprend pas NCurses.
C'est un peu hors sujet, là. Mais si tu veux dire que, tous les outils ne sont pas toujours 100% multi plateformes, en effet c'est vrai, et Microsoft et loin d'être le seul coupable dans le domaine. Le fait qu'ils collaborent à WebAssembly et WASI, qui sont des technologies qui visent justement à améliorer l'interopérabilité, c'est justement plutôt un bonne nouvelle.
L'époque ou Microsoft essayait d’écraser de son poids les efforts de standardisation est révolue depuis longtemps. Même s'ils le voulaient ils ne sont plus en position de force pour le faire.

Citation Envoyé par Madmac Voir le message
La similarité est qu'ils vont pouvoir écrire autre chose que des cookies sur ton disque . Et cela représente un énorme problème. Et mème Microsoft n'est qu'un joueur parmi les autres, je n'ai qu'à penser à Explorer pour imaginer les milles et une façon d'empoisonner ce projet.
...
Là j'ai du mal à te suivre. Pour le moment Wasm se limite à Javascript. Alors un navigateur suffit. Et coté serveur Node te permet tester ton code.
Je pense que tu as mal compris ce que sont WebAssembly et WASI.
WASM est un bytecode générique qui peut théoriquement être produit a partir de n'importe quel langage, avec des performance potentiellement proche du natif.

Le premier usage historique de WebAssembly est, comme son nom l'indique, dans le cadre du navigateur Web. Pour cet usage, il n'aura accès qu'aux API Web existantes et rien de plus. Donc il n'apporte aucune nouvelle possibilité technique au navigateur par rapport JavaScript. Il permettra juste d'être plus performant et d'utiliser d'autres langages de manière plus propre.

Le but de la Bytecode alliance, dont parle l'article, est de développer WASI, une API qui permettra l'usage du Bytecode WebAssembly sans navigateur. Le but premier est de pouvoir mettre en place un système de sandbox pour des environnement de type serveur, plutôt qu'un système de conteneur ou de virtualisation. Mais dans ce cas là, malgré son nom, WebAssembly n'a plus aucun lien avec le navigateur. WASI sera une API adaptée aux besoin d'un ordinateur complet qui sera utilisable dans des machines virtuelles dédiés. Elle ne sera jamais intégrée aux navigateurs.

La seule chose en commun entre une appli WebAssembly sur navigateur et une appli WASI, c'est le format du bytecode.
2  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 06/05/2021 à 22:02
Citation Envoyé par Madmac Voir le message
Ok, là je comprend. Je vois pas vraiment l'intérêt de faire à distance ce que peut-être fait sur son propre ordinateur. J'imaginais quelque chose comme les JARS de Java. Je ne crois pas que cela va révolutionner le monde de l’informatique.
Il ne s'agit pas de faire les choses à distance, enfin pas forcément. Les Applications WASI seront des applications normales, tout a fait utilisable en local. Un fichier wasm compilé pour utiliser WASI est l'équivalent d'un fichier .class. La JVM executant le code Java est juste remplacée une VM WebAssembly et la bibliothèque standard Java est remplacée par WASI.

L'avantage de WASI est que :
- il assure une encapsulation des IO, à la manière d'un conteneur Docker, mais au niveau de la VM WASM et pas du système, ce qui devrait être moins couteux en performance.
- L'application peut théoriquement être écrite dans n'importe quel langage.
- Le WebAssembly étant conçu pour fonctionner avec des langages de bas niveau, il permet de tirer de meilleures performances qu'une JVM taillé spécifiquement pour le Java
- Son utilisation quasi transparente, ce qui permet une prise en main quasi immédiate pour les utilisateurs et l'adaptation simple pour les applications existantes.
2  0 
Avatar de archqt
Membre émérite https://www.developpez.com
Le 01/05/2021 à 14:50
En gros c'est du "ByteCode" qui est exécuté. Par contre la vitesse native, non, ça ne pourra jamais aller aussi vite que des instructions assembleur. Sauf si bien sûr le byte code est retraduit en instruction assembleur avant .
Je suppose que c'est cela qui est fait, du moins ce que je ferais moi, un code intermédiaire comme celui qui sort de LLVM, puis une traduction de cet assembleur universel vers l'assembleur de la cible.

Par contre s'il y a GC on aura forcément des pertes par rapport à une application pure C/C++/Rust par exemple.
1  0