What do you mean? The calling convention is relatively minor and is not something you really need to be aware of.
[addendum - I mis -understood/-read the goals aligned bit]
Fil-C is much slower than C. In the best cases it's in the region of 1.5x slower than C/C++ (the best case performance is around ASAN or a bit slower - with the exception of allocation performance - more on that below). Worst cases it in the vicinity of 4x slower. For most stuff it seems to be a bit more than 2x slower than plain C (maybe 2.5x but it was a long time ago when I last looked at these numbers, so I'm going to assume it's improved so that 2x is more accurate). There are pathological cases where things become extremely bad (>10x slower), but I don't think that's a intrinsic limit - pathological cases generally get focused optimization when they come up (often they're just something dumb happening in the pipeline).
It also has significantly higher memory overhead - a combination of much more metadata, much more base overhead due to isolation, and the fact that it is GC'd. The use of the GC isn't "make it easier to write memory safe code", it's "assume the existence of UaF vulnerabilities and use a GC to ensure that anything still referenced is not actually released".
Basically the purpose of Fil-C is to address "I have an old C codebase, I cannot reasonably find and fix all possible errors, but it's also not performance critical so the safety vs performance tradeoff permits a significant performance hit in exchange for increased safety guarantees.
andyferris | 10 hours ago
Reading this… I do sometimes wonder why this couldn’t be (have been) C.
Just think - correctness could be a performance concern! Goals aligned... Etc.
olliej | 6 hours ago
What do you mean? The calling convention is relatively minor and is not something you really need to be aware of.
[addendum - I mis -understood/-read the goals aligned bit]
Fil-C is much slower than C. In the best cases it's in the region of 1.5x slower than C/C++ (the best case performance is around ASAN or a bit slower - with the exception of allocation performance - more on that below). Worst cases it in the vicinity of 4x slower. For most stuff it seems to be a bit more than 2x slower than plain C (maybe 2.5x but it was a long time ago when I last looked at these numbers, so I'm going to assume it's improved so that 2x is more accurate). There are pathological cases where things become extremely bad (>10x slower), but I don't think that's a intrinsic limit - pathological cases generally get focused optimization when they come up (often they're just something dumb happening in the pipeline).
It also has significantly higher memory overhead - a combination of much more metadata, much more base overhead due to isolation, and the fact that it is GC'd. The use of the GC isn't "make it easier to write memory safe code", it's "assume the existence of UaF vulnerabilities and use a GC to ensure that anything still referenced is not actually released".
Basically the purpose of Fil-C is to address "I have an old C codebase, I cannot reasonably find and fix all possible errors, but it's also not performance critical so the safety vs performance tradeoff permits a significant performance hit in exchange for increased safety guarantees.