141–150 of 263 posts
I would really like to see Omarchy go this direction. A fully memory-safe userland for Omarchy is possible with existing techhnology.
Cool project! I take it the goal is that, overhead being acceptable, most C / C++ programmes don't actually "have to be" rewritten in something like Rust? I wonder how / where Epic Games comes in?
Note that Fil-C is a garbage-collected language that is significantly slower than C. It's not a target for writing new code (you'd be better off with C# or golang), but something like sandboxing with WASM, except that Fil-C crashes more precisely.
Earlier quoted context omitted.
> disadvantages are speed, and garbage collection. And size. About 10x increase both on disk and in memory $ stat -c '%s %n' {/opt/fil,}/bin/bash 15299472 /opt/fil/bin/bash 1446024 /bin/bash $ ps -eo rss,cmd | grep /bash 34772 /opt/fil/bin/bash 4256 /bin/bash
How does that compare with rust? You don't happen to have an example of a binary underway moving to rust in Ubuntu-land as well? Curious to see as I honestly don't know whether rust is nimble like C or not.
Ubuntu 25.10's rust "coreutils" multicall binary: 10828088 bytes on disk, 7396 KB in RAM while doing "sleep".
Alpine 3.22's GNU "coreutils" multicall binary: 1057280 bytes on disk, 2320 KB in RAM while doing "sleep".
Earlier quoted context omitted.
There’s no Rust fans here, only GC skeptics. GC skeptics existed long before anyone dreamed of Rust and will survive Rust as well. It’s a pretty reasonable objection too (though I personally don’t agree). C has always been chosen when performance is paramount. For people who prioritise performance it must feel a bit weird to leave performance on the table in this way. And Jesus Christ, give it a rest with this “Rust…
No, back in the day C was used for everything. Vim was not written in C because it needed to wring every last bit of performance out of text editing. Rewriting everything in rust "for memory-safety" is a false tradeoff given the millions of lines of C code out there and the fact that rewrites always introduce new bugs.
The vast majority of the conversation here is about GC and the performance implications of that. Please stick to the rest of the thread.
For those who might miss it, the notes cite a new 64-bit version of cdb that supports exabyte databases https://cdb.cr.yp.to Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve
Earlier quoted context omitted.
From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang" Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most inter…
Cryptographic software is probably close to a best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. As long as Fil-C is able to avoid doing anything expensive in the inner loops you get good performance.
> best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops.
I am a bit surprised that the build_all_fast_glibc.sh script requires 31Gbyte of memory to run. Can somebody explain? I would like to try out Fil-C.
Earlier quoted context omitted.
From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang" Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most inter…
Along with the sibling comment, microbenchmarks should not be used as authoritative data when the use case is full applications. For that matter, highly optimized Java or Go may be "1 to 4 times as slow as plain C". Fil-C has its merits, but they should be described carefully, just with any technology.
Fil-C has its drawbacks, but they should be described carefully, just with any technology.
There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!
I’m glad Phil’s work is finally getting the recognition it deserves. There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!
As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.