En une ligne : Compilations avec des vérifications à l'exécution. Pour ça des informations sont rajoutées aux pointeurs, et un garbage collector. Ça compile à code source égal y compris sur de gros projets genre MariaDb. Le tout au prix évidemment de perte de performance (4 fois plus lent à l'exec dans le pire des cas).
Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. I'm actively working on performance optimizations for Fil-C, so that 4x number will go down.
C’est clair qu’il a le potentiel d’un game changer… ou presque.
Du "safe" "rust" sans avoir à l’apprendre… Bon avec une pertes de performances par rapport au C original et même par rapport à Rust mais une perte minimale généralement acceptable.
Bien mieux que le "safe C++" moderne qui s’y perd de plus en plus sans assurer le niveau de sécurité de Rust.
Bon Rust ajoutera toujours le côté explicitement safe. J’étends par là qu’il ne fait pas que empêcher les memory leek "segfault". En plus il permet au programmeur de traiter chaque cas de potentiel segfault alors que fil-C fait juste un plantage "propre": exit sans segfault.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# ch'tite dépêche ?
Posté par orfenor . Évalué à 4 (+3/-1).
Tu veux pas écrire une petite dépêche d'intro sur ça ? C'est super intéressant comme projet.
[^] # Re: ch'tite dépêche ?
Posté par thoasm . Évalué à 7 (+4/-0).
En une ligne : Compilations avec des vérifications à l'exécution. Pour ça des informations sont rajoutées aux pointeurs, et un garbage collector. Ça compile à code source égal y compris sur de gros projets genre MariaDb. Le tout au prix évidemment de perte de performance (4 fois plus lent à l'exec dans le pire des cas).
[^] # Re: ch'tite dépêche ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+1/-1).
4 fois? C’est quand même beaucoup. Je pesais que ce serait 50% max ce qui est pour moi acceptable généralement.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: ch'tite dépêche ?
Posté par thoasm . Évalué à 7 (+4/-0).
C'est dans le Manifesto Manifesto :
Ils pensent optimiser dans les futures versions
[^] # Re: ch'tite dépêche ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à 5 (+4/-0). Dernière modification le 11 mai 2025 à 23:35.
C’est clair qu’il a le potentiel d’un game changer… ou presque.
Du "safe" "rust" sans avoir à l’apprendre… Bon avec une pertes de performances par rapport au C original et même par rapport à Rust mais une perte minimale généralement acceptable.
Bien mieux que le "safe C++" moderne qui s’y perd de plus en plus sans assurer le niveau de sécurité de Rust.
Bon Rust ajoutera toujours le côté explicitement safe. J’étends par là qu’il ne fait pas que empêcher les memory leek "segfault". En plus il permet au programmeur de traiter chaque cas de potentiel segfault alors que fil-C fait juste un plantage "propre": exit sans segfault.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: ch'tite dépêche ?
Posté par orfenor . Évalué à 5 (+3/-0).
Après ces explications, tu n'as plus qu'à te coller à une dépêche!
[^] # Re: ch'tite dépêche ?
Posté par Dring . Évalué à 6 (+5/-1).
Je peux aider en proposant un titre pas du tout putaclic. Genre « Un Rust-Killer écrit en C. Vous serez surpris par les performances. ».
Ou alors…
« Il recompile MariaDB en mode safe-memory en 2 étapes. Vous ne devinerez jamais la seconde ».
[^] # Re: ch'tite dépêche ?
Posté par lrda . Évalué à 1 (+1/-0).
Une grosse différence c'est surtout que ça va se détecter qu'au runtime, là où Rust (et même une partie de C++) va détecter ça à la compilation.
C'est toujours mieux que des vulnérabilités mémoire, mais il y aura un plantage du programme quand même
Ça veut dire qu'avec le Fil-C, le problème n'est pas vu avant qu'il soit testé.
[^] # Re: ch'tite dépêche ?
Posté par inkey . Évalué à 1 (+0/-0).
Du coup l'idée c'est de compilé en fil-c pour debug et de compiler de façon standard en release ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.