4 ms·

I don't get it, what's the catch? Why isn't everyone using Fil-C immediately everywhere?

pizlonator 2y ago
Lots of reasons. Here's one: even just switching from gcc or msvc to clang, in projects that really want to, takes years. Here's another one: the Fil-C compiler is really young, so it almost certainly still has bugs. Those compilers that folks actually use in anger tend to get qualified on ~billions of lines of code before anyone other than the compiler devs touches them. The Fil-C compiler is too young to have that level of qualification. So "immediately everywhere" isn't going to happen. At best it'll be "over a period of time and incrementally".
throwaway4655 2y ago
Awful performance. Usually 2x worse than C and 4x worse in the worst case. Given the comment by Fil-C's creator minimizing the performance issue [0], I wouldn't get my hopes up. [0] https://news.ycombinator.com/item?id=43190938 https://news.ycombinator.com/item?id=43190938
- pizlonator 2y ago
  I guess you missed the point of that post. I’ll summarize: language implementations get faster over time. Young ones tend to be slow. Fil-C is a young implementation that still has lots of unoptimized things. Also, Fil-C being 2x slower than C means it’s already faster than many safe languages. And, for a lot of C use cases perf doesn’t matter as much as the hype suggests. The fact that young implementations are slow is something that’s worth understanding even if you don’t care about fil-C. It suggests, for example, that if someone invents a new language and their initial implementation is slow, then you can’t use that fact to assume that it’ll be slow forever. I think that’s generally a useful lesson. I care about performance a lot and Fil-C has gotten about 100x faster since the first prototype. It’ll keep getting faster.
fweimer 2y ago
It's not widely known, and it seems to be still in the research stage. A lot of things in this area never really get out of that. It did not happen for MPX. Many distributions build binaries for SHSTK, but I doubt anyone is enabling it by default. Even Address Sanitizer still relies on wrappers on the side, does not provide ABI stability, and is generally not considered ready for production binaries. I don't think there's a mainstream distribution where linking with -fsanitizer=address automatically gives you the Address Sanitizer version of system libraries. (Wouldn't that be nice?) Getting these things to mass deployment, ticking all those little boxes, is a lot of effort. Porting a distribution to a new CPU architecture is likely easier, especially after the early stages (toolchain bringup). Apart from that, there could be technical issues with the proposed approach. Perhaps the memory overhead? Or it might turn out that the desired performance characteristics basically require a JIT that specializes code so that typed pointers can be used where the types are known to be correct.
- pizlonator 2y ago
  Pretty much everything you're saying is true. > It's not widely known, and it seems to be still in the research stage. Yes on both counts. > A lot of things in this area never really get out of that. I hope that doesn't happen to Fil-C, but it could! > Getting these things to mass deployment, ticking all those little boxes, is a lot of effort. 100% I think this is one area where I'm trying to make Fil-C different than what came before it. I'm trying to tick all those little boxes. It's a lot of work! > Porting a distribution to a new CPU architecture is likely easier, especially after the early stages (toolchain bringup). Not sure about this. It might be true today because Fil-C hasn't yet ticked all the boxes, but the aim is definitely to be close to the cost of porting to a new CPU. It's already like that for a lot of code. > Perhaps the memory overhead? Heh yeah. The invisicaps cost memory. And GC costs memory. > Or it might turn out that the desired performance characteristics basically require a JIT that specializes code so that typed pointers can be used where the types are known to be correct. I've thought about how a JIT might help. I don't think it would. (Most of my compiler experience is writing JITs and I wrote JavaScriptCore's JITs, so I'm biased towards seeing JIT opt opportunities - and I don't see any in Fil-C right now.)

Lots of reasons. Here's one: even just switching from gcc or msvc to clang, in projects that really want to, takes years. Here's another one: the Fil-C compiler is really young, so it almost certainly still has bugs. Those compilers that folks actually use in anger tend to get qualified on ~billions of lines of code before anyone other than the compiler devs touches them. The Fil-C compiler is too young to have that level of qualification. So "immediately everywhere" isn't going to happen. At best it'll be "over a period of time and incrementally".

throwaway4655 2y ago

Awful performance. Usually 2x worse than C and 4x worse in the worst case. Given the comment by Fil-C's creator minimizing the performance issue [0], I wouldn't get my hopes up. [0] https://news.ycombinator.com/item?id=43190938 https://news.ycombinator.com/item?id=43190938

pizlonator 2y ago
I guess you missed the point of that post. I’ll summarize: language implementations get faster over time. Young ones tend to be slow. Fil-C is a young implementation that still has lots of unoptimized things. Also, Fil-C being 2x slower than C means it’s already faster than many safe languages. And, for a lot of C use cases perf doesn’t matter as much as the hype suggests. The fact that young implementations are slow is something that’s worth understanding even if you don’t care about fil-C. It suggests, for example, that if someone invents a new language and their initial implementation is slow, then you can’t use that fact to assume that it’ll be slow forever. I think that’s generally a useful lesson. I care about performance a lot and Fil-C has gotten about 100x faster since the first prototype. It’ll keep getting faster.

fweimer 2y ago

It's not widely known, and it seems to be still in the research stage. A lot of things in this area never really get out of that. It did not happen for MPX. Many distributions build binaries for SHSTK, but I doubt anyone is enabling it by default. Even Address Sanitizer still relies on wrappers on the side, does not provide ABI stability, and is generally not considered ready for production binaries. I don't think there's a mainstream distribution where linking with -fsanitizer=address automatically gives you the Address Sanitizer version of system libraries. (Wouldn't that be nice?) Getting these things to mass deployment, ticking all those little boxes, is a lot of effort. Porting a distribution to a new CPU architecture is likely easier, especially after the early stages (toolchain bringup). Apart from that, there could be technical issues with the proposed approach. Perhaps the memory overhead? Or it might turn out that the desired performance characteristics basically require a JIT that specializes code so that typed pointers can be used where the types are known to be correct.

pizlonator 2y ago
Pretty much everything you're saying is true. > It's not widely known, and it seems to be still in the research stage. Yes on both counts. > A lot of things in this area never really get out of that. I hope that doesn't happen to Fil-C, but it could! > Getting these things to mass deployment, ticking all those little boxes, is a lot of effort. 100% I think this is one area where I'm trying to make Fil-C different than what came before it. I'm trying to tick all those little boxes. It's a lot of work! > Porting a distribution to a new CPU architecture is likely easier, especially after the early stages (toolchain bringup). Not sure about this. It might be true today because Fil-C hasn't yet ticked all the boxes, but the aim is definitely to be close to the cost of porting to a new CPU. It's already like that for a lot of code. > Perhaps the memory overhead? Heh yeah. The invisicaps cost memory. And GC costs memory. > Or it might turn out that the desired performance characteristics basically require a JIT that specializes code so that typed pointers can be used where the types are known to be correct. I've thought about how a JIT might help. I don't think it would. (Most of my compiler experience is writing JITs and I wrote JavaScriptCore's JITs, so I'm biased towards seeing JIT opt opportunities - and I don't see any in Fil-C right now.)