S02E03 — 03-01-2026.
la poésie du code.
jour 3.
Hier, le temps était propice, mon objectif: publier ma bibliothèque de fonctions d’accélération ou de lissage. Je ne sais pas du tout comment les mathématiques nomment les easing functions en français. En vérité, je ne suis pas à mon premier coup d’essai, j’avais publié une version de celle-ci sous le nom de eazing. Mais n’étant pas satisfait de mon implémentation, je l’ai recommencer, lui est donné un p’tit nom plus moderne eazy.
En soi, la vraie amélioration s’est faite sur les performances. Pour me challenger, j’ai benchmarké mes fonctions avec les meilleures caisses de l’écosystème Rust. Et les résultats sont assez impressionnants. Ils sont disponibles ici — tu te rends vite compte que ma bibliothèque performent de fou malade. En général, eazy finit première du classement ou second lorsqu’elle performe moins.
| Benchmark | Gagnant | classement eazy |
|---|---|---|
| in_back | eazy (4.81µs) | 1er |
| in_out_back | eazy (10.56µs) | 1er |
| out_back | simple_easing2 (5.57µs) | 2ème (6.17µs) |
| in_quadratic | eazy (2.52µs) | 1er |
| in_out_quadratic | emath (4.71µs) | 2ème (5.28µs) |
| out_quadratic | eazy (2.68µs) | 1er |
source — eazy — performance benchmark
Et il y a des belles caisses dans la compétition, dans la course, eazy compète avec emathegui et notamment interpolationpiston. Les deux caisses les plus utilisés comptabilisant à elles seules plus de 12 millions de téléchargements au total (au moment où j’écris ce speech). Ce chiffre continuera d’augmenter, c’est autant d’applications potentiels dont les performances peuvent drastiquement améliorer. Ne serait-ce que si j’arrive à convaincre 1% de ces utilisateurs d’utiliser eazy, ça donne 120k programmes potentiels plus rapides. C’est pas mal — on parle ici de performance 8x plus rapide ce qui n’est pas négligeable pour réduire la consommation mémoire de certains programmes.
Je vais songer à faire un peu de promo, d’ici mi-février pour donner un peu plus de visibilité.
Mais comment, j’ai fais? J’ai simplement suivant les conseils de Michel Ange aka Michaelangel007. C’est un magnifiquement dépôt qui tente d’illustrer la poésie dans le code puisque son auteur démontre l’erreur que toute l’industrie de la Tech fait et continue de faire en utiliser des fonctions d’accélération non-optimisées. En gros, parmis tous les ingénieurs dans notre domaine, aucun n’a vu que les travaux de Robert Penner étant pas optimisé du tout (Rob, c’est le gars qui à ramener les fonctions de lissage dans l’game), plus d’info @ici — dis-toi que ses travaux sont encore utiliser en CSS, JavaScript, C et il est cité en tant que référant: @https://easings.net. Comme quoi même les gens, le plus intelligents peuvent être des moutons et suivre le troupeau sans se poser de question. Rien à voir avec le Qi.
Je reviens sur notre poète du code, je lis ces explications, les diggères, les tests et constate la magie des mathématiques, la beauté de la poésie du code. L’optimisation se fait principalement au niveau des arguments nécessaires aux fonctions d’accélération en général. L’approche de Michaelangel007 est de la normaliser pour ne prendre qu’un seul argument p ∈ [0,1] — si je comprends correctement c’est que la valeur oscillera entre 0 et 1. C’est cette simplification qui va changer le game puisque tu ne fais aucunes allocations, pas de validations, de checks à faire durant le temps d’éxécution, juste des maths et au revoir-merci.
Une fois convaincu, j’ai poussé le concept en essayant d’ajouter plus de fonctions, de les optimiser en suivant toujours ses conseils d’optimisation pour assurer une prouesse technique à ma bibliothèque de fonctions d’accélération.
TRiLU!