This is very cool. I wonder if it makes sense to integrate into nixpkgs as a sort of “cross-compilation” target. Obviously it isn’t quite cross-compilation but it does mean that it can hook into nixpkgs machinery for transitively building dependencies with Fil-C. Of course there are probably some downsides here as you will end up compiling two versions of things in some cases for the “build” and “host” platform even though both of these can actually be run on the host machine.
There are definitely some programs of quality that I don’t trust that I would love to replace with Fil-C compiled variants. Really I could probably replace the vast majority of network services I run with this since they don’t have high performance requirements. Being able to do something like: services.rspamd.package = pkgsCross.fil-c.pkgs.rspamd or something like that would be incredibly powerful.
There’s a definite performance hit for dereferencing pointers, because Fil-C effectively virtualizes pointer accesses. I was poking at it last week in nixpkgs, trying to make a more stdenv compatible version of @mbrock’s filnix.
FWIW - Mike Acton’s Data Oriented Design talk from many CppCons ago is a good reminder to only go to main memory when necessary - it can be hundreds of times slower than other operations though I’d expect even warm reads on the same cache line to have a performance penalty with Fil-C.
I’ve gotten quite a bit further with Fil-C packaging. Readme has more pictures, toolchain structure is better, many packages work, including Lighttpd, OpenSSH, Emacs, etc. I made a PoC of a non-NixOS tiny as possible Nix-generated distribution that builds to QEMU, Docker, and nspawn…
Most excitingly I’ve just made the leap into defining a gnufilc ABI and verified that Nixpkgs can—for GNU Hello and some other packages!—automatically cross compile from a pkgs with platform x86_64-linux-gnufilc…