> Fil-C is new and is a viable competitor to rust

I’ve no horse in the race here, but the Fil-C page talks about a 4x overhead from using it, which feels like it would make it less competitive

▲ mbrock 4 days ago | parent [-]

Currently measured worst case for some types or code.

▲ brucehoult 4 days ago | parent [-]

I tried it on my primes micro-benchmark (http://hoult.org/primes.txt) and got a 2:1 slowdown on 13th gen i9.

It does a LOT of array access and updating, probably near to worst-case for code that isn't just a loop copying bytes.

The average slowdown is probably more in the same region as using Java or C# or for that matter C++ std::array or std:vector.

▲ mbrock 3 days ago | parent [-]

If you missed it, djb himself posted this cute graph of "nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4)":

https://cr.yp.to/2025/20251028-filcc-vs-clang.html

I've heard Filip has some ideas about optimizing array performance to avoid capability checks on every access... doing that thread safely seems like an interesting challenge but I guess there are ways!

	▲	brucehoult 3 days ago \| parent [-]
		Sure of course I followed that link. I've really got no idea what the horizontal axis is! But there is a huge cluster of results between 1x and 1.5x execution time. And, the kind of code he is interested in is not necessarily the same as the kind of code I'm interested in. In fact I know it's not! As one more data point, compiling my little benchmark with gcc, without any optimisation flag. `1964ms gcc primes.c -o primes -O 3723ms fil-c primes.c -o primes -O 3753ms gcc primes.c -o primes 16334ms fil-c primes.c -o primes` Fil-C with -O is almost identical to gcc without.