L'API d'intégration des Promises JavaScript (JSPI) permet aux applications WebAssembly écrites en supposant un accès synchronisé à des fonctionnalités externes de fonctionner sans heurt dans un environnement où ces fonctionnalités sont en réalité asynchrones.
L'API JSPI (JavaScript Promise Integration) de WebAssembly a une nouvelle API, disponible dans la version M126 de Chrome. Nous parlons de ce qui a changé, comment l'utiliser avec Emscripten, et quelle est la feuille de route pour JSPI.
JSPI est une API qui permet aux applications WebAssembly utilisant des API séquentielles d'accéder aux API Web qui sont asynchrones. De nombreuses API Web sont conçues en termes d'objets Promise de JavaScript : au lieu d'effectuer immédiatement l'opération demandée, elles renvoient une Promise pour le faire. D'autre part, de nombreuses applications compilées en WebAssembly viennent de l'univers C/C++, qui est dominé par des API bloquant l'appelant jusqu'à achèvement.
L'API d'intégration des promesses JavaScript (JSPI) de WebAssembly entre en phase de test origin, avec la version M123 de Chrome. Cela signifie que vous pouvez tester si vous et vos utilisateurs pouvez profiter de cette nouvelle API.
JSPI est une API qui permet à du code dit séquentiel – qui a été compilé en WebAssembly – d'accéder à des API Web qui sont asynchrones. De nombreuses API Web sont conçues en termes de Promises JavaScript : au lieu de réaliser immédiatement l'opération demandée, elles renvoient une Promise pour le faire. Lorsque l'action est finalement réalisée, le gestionnaire de tâches du navigateur déclenche les callbacks liés à la Promise. JSPI s'intègre dans cette architecture permettant à une application WebAssembly d'être suspendue lorsque la Promise est retournée et reprise lorsque celle-ci est résolue.
Bienvenue dans le monde passionnant de V8, où la vitesse n'est pas seulement une caractéristique mais un mode de vie. Alors que nous disons adieu à 2023, il est temps de célébrer les réalisations impressionnantes que V8 a accomplies cette année.
Grâce à des optimisations innovantes en termes de performances, V8 continue de repousser les limites de ce qui est possible dans le paysage toujours en évolution du Web. Nous avons introduit un nouveau compilateur de niveau intermédiaire et mis en œuvre plusieurs améliorations dans l'infrastructure du compilateur de haut niveau, le runtime et le ramasse-miettes, ce qui a entraîné des gains de vitesse significatifs dans tous les domaines.
Un article récent sur WebAssembly Garbage Collection (WasmGC) explique à un niveau général comment la proposition de Garbage Collection (GC) vise à mieux prendre en charge les langages à GC dans Wasm, ce qui est très important compte tenu de leur popularité. Dans cet article, nous entrerons dans les détails techniques sur la manière dont les langages à GC tels que Java, Kotlin, Dart, Python et C# peuvent être portés sur Wasm. Il existe en fait deux approches principales :
Nous intégrons les appels en queue de WebAssembly dans V8 v11.2 ! Dans cet article, nous donnons un aperçu de cette proposition, présentons un cas d’utilisation intéressant pour les coroutines C++ avec Emscripten, et montrons comment V8 gère les appels en queue en interne.
Un appel est dit être en position de queue si c'est la dernière instruction exécutée avant de retourner de la fonction actuelle. Les compilateurs peuvent optimiser ces appels en supprimant la pile de l'appelant et en remplaçant l’appel par un saut.
Cela est particulièrement utile pour les fonctions récursives. Par exemple, prenez cette fonction C qui additionne les éléments d'une liste chaînée :
int sum(List* list, int acc) {
if (list == nullptr) return acc;
return sum(list->next, acc + list->val);
}
Avec un appel classique, cela consomme un espace de pile de 𝒪(n) : chaque élément de la liste ajoute un nouveau cadre à la pile d'appels. Avec une liste assez longue, cela peut rapidement provoquer un débordement de pile. En remplaçant l'appel par un saut, l'optimisation des appels en queue transforme efficacement cette fonction récursive en une boucle utilisant un espace de pile de 𝒪(1) :
V8 dispose de deux compilateurs pour compiler le code WebAssembly en code machine pouvant ensuite être exécuté : le compilateur de base Liftoff et le compilateur optimisé TurboFan. Liftoff peut générer du code beaucoup plus rapidement que TurboFan, ce qui permet un démarrage rapide. TurboFan, en revanche, peut générer du code plus rapide, ce qui permet des performances maximales.
Grâce à des travaux récents sur Chrome et Emscripten, vous pouvez désormais utiliser jusqu'à 4 Go de mémoire dans les applications WebAssembly. C'est une augmentation par rapport à la limite précédente de 2 Go. Cela peut sembler étrange qu'il y ait eu une limite - après tout, aucun travail n'était nécessaire pour permettre aux gens d'utiliser 512 Mo ou 1 Go de mémoire ! - mais il s'avère qu'il y a des aspects spéciaux concernant le passage de 2 Go à 4 Go, à la fois dans le navigateur et dans la chaîne d'outils, que nous décrirons dans cet article.
Nous avons un nombre croissant de compilateurs et d'autres outils qui génèrent ou manipulent des fichiers .wasm, et parfois, vous pourriez vouloir jeter un œil à l'intérieur. Peut-être êtes-vous un développeur de cet outil ou, plus directement, vous êtes un programmeur ciblant Wasm et vous vous demandez à quoi ressemble le code généré, pour des raisons de performance ou autres.
Emscripten s'est toujours concentré en priorité sur la compilation pour le web et autres environnements JavaScript comme Node.js. Mais à mesure que WebAssembly commence à être utilisé sans JavaScript, de nouveaux cas d'utilisation apparaissent, et nous avons travaillé sur la prise en charge de l'émission de fichiers Wasm autonomes à partir d'Emscripten, qui ne dépendent pas de l'environnement d'exécution JavaScript d'Emscripten ! Ce post explique pourquoi cela est intéressant.