De WebAssembly (WASM) à C++, Firefox change de moteur d’exécution pour son IA locale et annonce des gains de « 2 à 10× » selon les tâches, tout en supprimant le coût de chauffe propre au WASM lors des premiers lancements. Les premières fonctions concernées, dont les groupes d’onglets intelligents et la génération d’alt‑text dans PDF.js, bénéficient déjà de cette accélération dans Firefox 142, avec une latence mesurée passant de 3,5 s à 350 ms pour l’alt‑text sur la même machine.
Surprenant d’ apprendre que Mozilla, à l’origine de Rust, soit passé de Wasm à C++
Je pense qu’ils se sont largement basés sur les lib c++ existantes, ne serait-ce que pour sortir plus rapidement la feature.
En soi, c’était déjà une aberration que d’utiliser autre chose qu’un langage natif pour manipuler de l’IA… Ils visaient la fonctionnalité sans se préoccuper de la performance: javascript, puis WASM, puis re-javascript ? Il espérait quoi l’architecte …
Que l’auteur de l’article et du commentaire ait un bagage technique un peu plus élevé. Tu ne peux pas utiliser WASM dans un navigateur qu’avec du Javascript. Donc oui, en fait, tout utilisation de WASM implique de copier des données du JS vers la mémoire allouée au webassembly, puis l’inverse pour les résultats. Dans la majorité des cas, c’est pas du tout un problème, vu que tout le traitement est fait dans le WASM, et donc le gain de performance est colossal par rapport à un JS JIT. Mais pour le LLM (l’IA dont on parle ici), les données à envoyer, c’est les modèles et poids du réseau neuronal. Les données d’entrées (le PDF, ou le texte d’une page), c’est peanut à côté (des GB pour le premiers vs des kB pour le second). Les données de sortie (le résumé), c’est peanut aussi. Le coût de cette copie explique la raison du ralentissement au démarrage.
L’autre problème du WASM qui est limitant ici, c’est les check mémoires (en gros, l’assembly doit vérifier toute écriture/lecture mémoire pour éviter qu’elle ne touche une zone extérieure à son allocation). Sur du gros calcul matriciel, ces checks de sécurité coûtent plus cher que le calcul lui même. Le fait de passer en C++ implique que ces tests sont supprimés, que l’on peut utiliser des instructions natives pour le SIMD (qui n’en ont RAF de ravager la mémoire du voisin), ce que le WASM ne supporte (et heureusement) pas.
Enfin, l’implementation JS de Mozilla est plus lente que celle de Chrome, ce qui ajoute aussi une explication à ce gain.
Je crois que l’autre commentaire dit la même chose que toi, sans les précisions techniques ^^