Koromix a écrit 15 commentaires

Pour faire tourner du code non-JS dans un navigateur, le WebAssembly semble être la (bonne ?) solution.

Koffi ne fonctionne pas dans un navigateur mais avec Node.js, qui est un runtime Javascript (basé sur V8) comme l'est la JVM pour Java ou le CLR .Net pour C#.

L'intérêt du FFI, que ce soit avec Koffi ou autre chose, c'est :

• L'appel direct à des fonctions du système d'exploitation, par exemple Win32 (ce que WASM ne fournit pas, et c'est d'ailleurs voulu, les navigateurs se devant de fournir un environnement d'exécution limité et contrôlé)
• Réutiliser des librairies C déjà compilées, sans avoir à tout wrapper (avec N-API, les API V8, ou autre)

Je prends un exemple complètement au hasard : lister les fenêtres ouvertes sous Windows en utilisant l'API Win32, depuis une application Node.js. Pour ce faire, il faut appeler EnumWindows(), c'est une fonction fournie par user32.dll, et qui utilise l'ABI C.

Honnêtement, ce n'est pas voulu, le nom est composé de mon pseudo Koromix et de FFI.

Bah, si je suis honnête, me faire plaisir c'est 80% de la motivation de ce projet ;) J'ai pu (et je peux) jouer avec du code bas niveau, de l'assembleur x86, x64, RISC-V, ARM64 et ARM32, les différentes ABI C. Et bientôt PowerPC :)

Cela dit, ma motivation initiale c'était d'utiliser Raylib sans tout wrapper. Certes, node-raylib existe, et c'est ce que j'ai utilisé au début… Mais un certain nombre de bugs existent, et j'ai eu pas mal de crashs, ainsi que pas mal de fonctions inutilisables ou toujours pas wrappées à ce jour. A ce moment, je me suis dit "tiens, pourquoi pas utiliser node-ffi". J'ai converti le code que j'avais, j'ai lancé, les perfs étaient bien plus catastrophiques qu'attendu… Et Koffi est né :)

Et puis, node-ffi, libffi, dyncall , toutes ces choses existent déjà et ont pas mal d'utilisateurs, a priori il y a un public et un besoin. On verra bien !

Bien évidemment, une autre possibilité existe, c'est de générer un binding de manière automatisée. Émettre du C, qui utilise N-API et le compiler en live, c'est simple dans l'idée. Si l'écosystème C était moins arachaïque, on compilerait du code de binding dynamiquement et facilement (sans avoir de souci avec certaines plateformes, de problèmes avec les linkers, etc), et ça serait plus performant. Mais l'écosystème étant ce qu'il est, ce n'est pas si facile et ça pose tout un tas de problèmes, largement liés aux nombreux arachaïsmes du C, de POSIX, de Win32, de macOS, etc.

Merci !

Globalement utiliser un module de Foreign Function Interface avec C c'est un compromis par rapport à un binding manuel, je pense qu'on peut dire que ça a de l'intérêt dans 3 cas :

• La facilité de réutiliser du code existant en C, sans avoir à tout wrapper (avec N-API, les API V8, ou autre)
• L'appel direct à des fonctions du système d'exploitation, par exemple Win32
• Le côté dynamique, un peu comme faire la réflexion (en Java, en C#), au prix d'une perte de performance

De mon point de vue, le benchmark le plus réaliste est celui basé sur Raylib, avec une perte de 20%. Il est rare d'avoir besoin d'une librarie de FFI pour appeler des fonctions très légères comme atoi() ou rand(), car ce sont des fonctionnalités généralement disponibles dans le langage, et/ou faciles à wrapper.

Par contre, pour quelque chose comme Raylib, ImGui, une bibliothèque de sons, Win32, GTK+, etc. Et bien ça peut avoir un certain intérêt, et l'overhead a relativement moins d'impact dans ce cas. De l'ordre de celui observé avec le benchmark Raylib.

Et puis j'espère bien gagner en performance, même si je suis déjà relativement content des résultats obtenus :)

Effectivement, merci pour l'exemple… :)
J'espère que la troisième fois est la bonne !

Voici les graphiques mis à jour pour Linux et Windows :

Quelqu'un me croit si je dis qu'à une époque je faisais de l'aide méthodologique dans un service de stats, sur R ? 😁
J'ai bien fait d'arrêter !

C'est une bonne remarque, merci, j'ai mis à jour les graphiques disponibles sur le site (il y a un cache d'1h ça peut mettre un peu de temps à changer). Et j'ai switché vers une échelle logarithmique pour que ça reste lisible avec les résultats de node-ffi-napi.

En ce qui concerne la version C/C++ de chaque test, elle a existé par le passé mais je reconnais l'avoir retirée car elle montrait avant tout l'overhead Javascript par rapport au C/C++. Hors je souhaite plutôt parler de l'overhead lié à Koffi, qui se pose en alternative au développement d'un binding manuel (généralement basé sur N-API, voire directement sur les API V8. Et non à un redéveloppement intégral en C ou C++ (ou Rust, pour éviter qu'on me tombe dessus 🥷).

Malgré tout, pour le troisième benchmark basé sur Raylib, les tableaux affichent les résultats de la version C++ : https://koffi.dev/benchmarks#raylib-results

Il y a une page dédiée aux benchmarks sur le site, avec 3 tests implémentés en plusieurs versions :

1. rand(): ce benchmark est basé sur des millions d'appels à rand(), compare un binding maison (qui utilise N-API) et Koffi (et node-ffi-napi, tellement catastrophique que je ne le mets que dans tes tableaux et pas les graphiques sinon on ne voit plus rien…). On est sur du +70% à +80% de temps d'exécution, donc même pas un doublement, et il s'agit d'une fonction C très simple donc l'overhead est majoré.
2. atoi(): ce benchmark est similaire au précédent, mais basé sur atoi() pour mesurer les performances de passage de chaine.
3. Raylib: ce benchmark est assez différent, il est basé sur Raylib (librairie C pour faire de la programmation de jeux vidéos). Ici 3 implémentations (sans compter node-ffi-napi) sont comparées : une version entièrement en C++, une version basée sur le paquet node-raylib (qui est un binding maison) et une version basée sur Koffi. Les fonctions Raylib font plus de boulot que les tests précédents, et là on est sur +20% de temps d'exécution par rapport au binding N-API.

Les deux premiers permettent de révèler l'overhead lié à Koffi puisqu'il s'agit de fonctions très simples, notamment rand(), mais par contre ce n'est pas un cas très réaliste d'utilisation. Le troisième est plus réaliste par rapport à l'utilisation réelle d'un module FFI, avec un overhead qui est relativement tolérable.

Pour résumer, l'overhead sur les deux premiers benchmarks (appels d'une fonction C très rapide) est de +70 à +80% par rapport au binding N-API, sur le troisième c'est +20% par rapport au binding N-API node-raylib. Pour comparaison, node-ffi-napi c'est +7000% sur atoi(), sans parler d'une explosion de la consommation mémoire (plusieurs Go) liée au GC qui ne réagit pas.

Les appels synchrones ont lieu sur le thread principal, les appels asynchrones sont exécutés par un pool de threads (worker threads).

J'ai publié deux petites mises à jour (1.3.1 puis 1.3.2), qui sont destinées à permettre (je l'espère) l'installation et la compilation de Koffi sur d'anciens systèmes comme Debian 9.

Ces mises à jour ne changent rien pour les systèmes plus récents ou les autres plateformes.

Les détails sont ici : https://github.com/Koromix/luigi/issues/10

Je parle du nombre de canaux disponibles. Surtout si on ne veut pas encore faire un saut de génération qui demande du nouveau matériel.

Et bien faisons un saut et de l'investissement, mais au lieu de faire plus mais avec une plus grosse empreinte (modèle VOD), on fait ce qu'il faut pour faire un truc sympa avec beaucoup moins de ressources (CanalSat v2). On a plein de chaines, on diffuse des tas de films et séries en broadcast et les utilisateurs attrapent ce qui passe.
Et on regarde les vidéos Youtube en 240p.

Sauf que ce n'est pas plus énergivore maintenant qu'il y a 10 ans

Mais c'était déjà trop énergivore il y a 10 ans, c'est bien ça le problème.
Au lieu de faire plus avec le même budget écologique qu'il y a 10 ans, on doit plutôt faire autant que possible avec (relativement) moins. Et donc profiter du progrès technologique pour faire des économies (en termes écologiques), et pas pour en faire plus comme c'est le cas à chaque fois.

Bref pour le moment on va faire comme d'habitude, c'est à dire que l'explosion des usages va oblitérer le gain en efficacité. D'ailleurs c'est ce qui se passe, puisque la consommation totale du secteur numérique (en chiffre absolu) augmente chaque année. Et pas de bol, mais c'est bien ça qui compte pour la planète.

En plus, du point de vue des terminaux, s'ils tiennent 10 ans, c'est déjà énorme, et on peut supposer que la 4G va encore être disponible 5 ans (vu la durée de vie de la 2G et 3G). Donc, si tu change de terminal tous les 10 ans, tu es bon.

10 ans c'est bien, mais on doit pouvoir mieux faire. 20 ou mieux, 30 ans ?
Surtout qu'un condensateur claqué, en général ça se change assez facilement. Mais bon si on le change et qu'en fait l'appareil n'a plus accès au réseau bah forcément ça favorise pas la réparabilité…

Perso, je n'ai pas de soucis avec un celeron n3350, tu n'aurais pas un problème de navigateur ?

J'ai aucun dossier à partager (que du privé partagé avec d'autres, c'est pas mon choix d'ailleurs d'utiliser GDrive) mais j'ai constaté ça plusieurs fois sur Firefox.

Autre exemple peut-être plus facile à reproduire: Google Maps. Qui passait tout seul sur un téléphone de 2013 il y a 6 ans, et qui est maintenant complètement inutilisable (par exemple sur l'iPhone 4 SE que j'ai récupéré). J'arrive même pas à charger la page.
Et pourtant, Google Maps ne fait à peu près rien de plus qu'avant (à part une base de données plus fournie).

Je ne crois pas que les gens regarde de la 4K dans le métro en 4G.

Là c'est du pinaillage. A Lille par exemple, les pubs pour la 4G dans le métro de Lille datent d'il y a un an, l'installation aussi. Et déjà, il y a pas mal de gens qui regardent la vidéo en 4G le matin et le soir, avec une bonne définition.
Tout ça c'est du gadget. Et si bientôt on propose la 5G dans le métro, et bah ouais on verra des gens regarder en 4K dans le métro sur des écrans Retina HD++ avec leur iPhone 13.

Du coup, tu limite énormément le choix de diffusion et on revient sur un modèle où la pub est reine. Tu sous-utilise l'infrastructure internet existante (vu qu'elle est déjà en place et doit être renouvellée).

Ou bien on utilise un abonnement. C'est ce que font déjà Canal+ et CanalSat depuis plus de 20 ans. Sans oublier au passage la redevance télévisuelle.

Quant à l'infrastructure existante, je pense qu'on apprécie pas le problème de la même manière. Si cette infrastructure est déjà trop énergivore (c'est mon point de vue), en sachant qu'au niveau mondial elle ne couvre qu'une partie de la population (et que l'autre a très envie d'y accéder aussi), la conséquence logique c'est que de toute manière on va pas pouvoir la garder. Donc va falloir faire avec moins, peut-être beaucoup moins. Dans ce contexte, je préfère garder Wikipédia et bazarder la 4K.

Est-ce que c'est vraiment rentable ? De toutes façon, le parc se renouvelle, est-ce que la 5G consomme vraiment plus que la 3G et mérite qu'on ne fasse pas le pas ? Qu'est-ce que coûte le fait de rester sur la 3G au lieu de partir sur la 5G ?

Non mais justement, le but c'est d'arrêter de renouveler l'infrastructure sans arrêt, et de mettre fin à l'obsolescence (qu'elle soit programmée ou marketing). C'est pas une question de rentabilité mais d'écologie, soit le sujet de ce journal.

On a gardé la télévision analogique pendant 40 ans et ça ne posait pas de problème.
J'ai strictement aucun équipement 4K et ça me pose aucun problème. J'avoue m'être habitué au 720p, mais je me rappelle très bien avoir longtemps regardé des DVD (voire moins) en 480p et je m'en portais pas plus mal. En me forçant un peu, je peux y retourner.
J'ai récupéré un MacBook de 2009 qui me sert beaucoup et tout va très bien. A part qu'évidemment, Google Drive met 10 secondes pour afficher une liste de 200 fichiers (en foirant régulièrement avec un ordre parfois incompréhensible), entre autres lenteurs totalement incompréhensibles. Mais là, c'est pas le MacBook le problème.
On pourrait continuer les exemples de ce type à l'infini.

Donc, pour revenir à la question, ce qu'on doit sacrifier si on reste en 3G ? Bah on va pas pouvoir regarder de 4K dans le métro. C'est pas un drame.

Non, désolé j'aurais dû être plus précis, je ne parlais pas du protocole IP en évoquant le broadcast.
Par broadcast/one-to-many je pensais avant tout à la diffusion TNT et/ou satellite.

On peut d'ailleurs noter que là aussi, une condition indispensable serait de ne pas changer de norme (SD => HD => 4K => 8K => ?) tous les 3 ans.
Un peu comme en téléphonie, d'ailleurs. On pourrait décider de rester en 3G (éventuellement 4G maintenant que ça se démocratise).

On pourrait déjà se contenter du 720p, éventuellement du 1080p. Et ne pas pousser le 4K, puis le 8K, etc.

Par ailleurs, le broadcast (one-to-many) de flux vidéos pompe beaucoup moins de ressources. On pourrait y revenir (ou en tout cas y rester), à condition de diversifier les chaines et de faire une vraie programmation (films et séries diverses tous les soirs, des émissions intéressantes, etc.). Et on enregistre pour regarder un truc en différé.

Quand on fournit un travail on est prêt à en accepter les critiques. Ce genre de « coquille » passerait pour un logiciel libre plus obscur mais passe mal pour un logiciel connu et répandu comme Firefox. La majorité des utilisateurs (Windows ≥ Vista) n'en verra rien et l'impact est limité… et c'est ce qui explique probablement que l'erreur soit arrivée en release. Une erreur plus visible/répandue aurait, AMHA, un très mauvais impact sur la qualité perçue du logiciel. Bien plus que de vagues considérations sur la consommation et les fuites mémoires, les crashs/freezes récurrents, etc. Là c'est concret, c'est quasiment la première chose qu'on voit, et la présentation fait tout pour l'utilisateur.

Tout n'est pas négatif, cela dit. J'utilise Firefox depuis longtemps, la traduction française est de qualité et c'est la première fois que je vois une telle erreur. Donc pour le reste de votre boulot, un grand merci. Surtout quand je vois la qualité de l'interface et du texte des logiciels que j'utilise tous les jours, propriétaires et extrêment chers. Mais bon là, j'ai pas le choix.

Plutôt d'accord avec toi, ce label "Outils de développement" se voit dès l'ouverture de Firefox, et donne une assez mauvaise impression d'amateurisme :/ Dès que je pose les yeux sur la barre d'onglets cette coquille me saute aux yeux. Ça n'est pas grave, mais c'est gênant malgré tout.

L'erreur est probablement passée à la trappe car elle ne concerne qu'une minorité des utilisateurs : ceux sous Windows XP et autres OS (dont les distributions Linux).

Il s'agit d'une erreur (cf. https://bugzilla.mozilla.org/show_bug.cgi?id=902173), éventuellement corrigée dans une version 23.0.1 (ou la 24 le cas échéant).