5 ms·

It is great that Fil-C exists. This is the sort of technique that is very effective for real programs, but that developers are convinced does not work. Existenc

It is great that Fil-C exists. This is the sort of technique that is very effective for real programs, but that developers are convinced does not work. Existence proofs cut through long circular arguments.

johncolanduoni 1y ago
What do the benchmarks look like? My main concern with this approach would be that the performance envelope would eliminate it for the use-cases where C/C++ are still popular. If throughput/latency/footprint are too similar to using Go or what have you, there end up being far fewer situations in which you would reach for it.
- pizlonator 1y ago
  Some programs run as fast as normally. That's admittedly not super common, but it happens. Some programs have a ~4x slowdown. That's also not super common, but it happens. Most programs are somewhere in the middle. > for the use-cases where C/C++ are still popular This is a myth. 99% of the C/C++ code you are using right now is not perf sensitive. It's written in C or C++ because: - That's what it was originally written in and nobody bothered to write a better version in any other language. - The code depends on a C/C++ library and there doesn't exist a high quality binding for that library in any other language, which forces the dev to write code in C/C++. - C/C++ provides the best level of abstraction (memory and syscalls) for the use case. Great examples are things like shells and text editors, where the syscalls you want to use are exposed at the highest level of fidelity in libc and if you wrote your code in any other language you'd be constrained by that language's library's limited (and perpetually outdated) view of those syscalls.
  - baranul 1y ago
    Very good answer and agree. There seems to be a psychological component wrapped up in the mythology versus the reality of what's necessary.
  - monkeyelite 1y ago
    You are making a lot of assumptions about my code.
    - pizlonator 1y ago
      I'm not meaning to. I've ported a lot of programs to Fil-C and I'm reacting to what I learn. I am curious though. What assumptions do you think I'm making that you think are invalid?
      - monkeyelite 1y ago
        - that 4x would not impact user experience - that my code is on a Unix time sharing system - that I only use C or C++ because I inherited it - that Unix tools do not benefit from efficient programming because of syscalls - that multi-threaded garbage collection would be good for perf (assuming I’m not sharing the system)
        pizlonator 1y ago
        You are posting on HN in a browser presumably. I am familiar with the stack of C/C++ code involved in that because I was a browser dev for 10+ years. Most of that code is definitely not perf sensitive in the sense that if you slowed it down by 4x, you might not notice most of the time (Browser performance is like megapixels or megahertz … a number that marketing nerds can use to flex, but that is otherwise mostly irrelevant) When I say 99% of the C code you use, I mean “use” as a human using a computer, not “use” as a dependency in your project. I’m not here to tell you that your C or C++ project should be compiled with Fil-C. I am here to tell you that most of the C/C++ programs you use as an end user could be compiled with Fil-C and you wouldn’t experience an degraded experience if that happened
        mike_hearn 1y ago
        You're absolutely right about all of this. People under-estimate how much code gets written in these languages just because decades ago they were chosen as the default language of the project and people are resistant to going full polyglot. Then everything gets written that way including cold paths, utilities, features that are hardly ever used, UI code that's bottlenecked by the network...
  - otabdeveloper4 1y ago
    All code is perf-sensitive. Also, literally every language claims "only a x2 slowdown compared to C". We still end up coding in C++, because see the first point.
    - pizlonator 1y ago
      I’m not claiming only 2x slowdown. It’s 4x for some of the programs I’ve measured. 4x > 2x. I’m not here to exaggerate the perf of Fil-C. I actually think that figuring out the true perf cost is super interesting! > All code is perf-sensitive. That can’t possibly be true. Meta runs on PHP/Hack, which are ridiculously slow. Code running in your browser is JS, which is like 40x slower than Yolo-C++ and yet it’s fine. So many other examples of folks running code that is just hella slow, way slower than “4x slower than C”
      - otabdeveloper4 1y ago
        All code is perf-sensitive. Not all code is important enough to be written as we'd like it to be.
        zelphirkalt 1y ago
        We don't like all code to be written in some C or C++ dialect.
        gf000 1y ago
        Then why use C? Take a look at actually perf-sensitive hot loops, and they are predominantly some inline assembly with a bunch of SIMD hacks, which can be 1000x times faster than C...
        otabdeveloper4 1y ago
        Unfortunately inline assembly isn't portable even to different revisions of one CPU architecture, much less different ones.
      - Sesse__ 1y ago
  - silisili 1y ago
    Super cool. What is your goal wrt performance? Is low 1.x-ish on average attainable, in your opinion?
    - pizlonator 1y ago
      I think that worst case 2x, average case 1.5x is attainable. - Code that uses SIMD or that is mostly dealing with primitive data in large arrays will get to close to 1x - Code that walks trees and graphs, like interpreted or compilers do, might end up north of 2x unless I am very successful at implementing all of the optimizations I am envisioning. - Code that is IO bound or interactive is already close to 1x
  - johncolanduoni 1y ago
    While there are certainly other reasons C/C++ get used in new projects, I think 99% not being performance or footprint sensitive is way overstating it. There's tons of embedded use cases where a GC is not going to fly just from a code size perspective, let alone latency. That's mostly where I've often seen C (not C++) for new programs. Also, if Chrome gets 2x slower I'll finally switch back to Firefox. That's tens of millions of lines of performance-sensitive C++ right there. That actually brings up another question: how would trying to run a JIT like V8 inside Fil-C go? I assume there would have to be some bypass/exit before jumping to generated code - would there need to be other adjustments?
    - kragen 1y ago
      Latency is the killer, I think. A GC can be on the order of 100 instructions.
      - pizlonator 1y ago
        It’s a concurrent GC. Latency won’t kill you I’ll admit that if you are in the business of counting instructions then other things in Fil-C will kill you. Most of the overhead is from pointer chasing. See https://fil-c.org/invisicaps https://fil-c.org/invisicaps
        kragen 1y ago
        "Concurrent" doesn't usually mean "bounded in worst-case execution time", especially on a uniprocessor. Does it in this case? InvisiCaps sound unbelievably amazing. Even CHERI hasn't managed to preserve pointer size.
        pizlonator 1y ago
        > "Concurrent" doesn't usually mean "bounded in worst-case execution time", especially on a uniprocessor. Does it in this case? Meh. I was in the real time GC game for a while, when I was younger. Nobody agrees on what it really means to bound the worst case. If you're a flight software engineer, it means one thing. If you're a game developer, it means something else entirely. And if you're working on the audio stack specifically, it means yet another thing (somewhere in between game and flight). So let me put it this way, using the game-audio-flight framework: - Games: I bound worst case execution time, just assuming a fair enough OS scheduler, even on uniprocessor. - Audio: I bound worst case execution time if you have multiple cores. - Flight: I don't bound worst case execution time. Your plane crashes and everyone is dead
  - hnlmorg 1y ago
    There’s loads of good shells and text editors written in other languages. I’m the author of a shell written in Go and it’s more capable than Zsh.
    - kragen 1y ago
      Interesting, what's it called? How does it compare to Andy Chu's Oil?
      - hnlmorg 1y ago
        It’s called Murex: https://github.com/lmorg/murex https://github.com/lmorg/murex It’s a typed shell. So you can do jq-like data manipulation against a plethora of different documents. Unlike Zsh et al that are still ostensibly limited to just whitespace-delimited lists.
        kragen 1y ago
        Interesting! Thanks for the link!
  - Sesse__ 1y ago
    > Great examples are things like shells and text editors I regularly get annoyed that my shell and text editor is slow :-) I do agree on principle, though.
  - IshKebab 1y ago
    > Some programs have a ~4x slowdown How does it compare to something like RLBox? > This is a myth. 99% of the C/C++ code you are using right now is not perf sensitive. I don't think that's true, or at best its a very contorted definition of "perf sensitive". Most code is performance sensitive in my opinion - even shitty code written in Python or Ruby. I would like it to be faster. Take Asciidoctor for example. Is that "performance sensitive"? Hell yes!
    - pizlonator 1y ago
      > How does it compare to something like RLBox? I don’t know and it doesn’t matter because RLBox doesn’t make your C code memory safe. It only containerizes it. Like, if you put a database in RLBox then a hacker could still use a memory safety bug to corrupt or exfiltrate sensitive data. If you put a browser engine in RLBox then a hacker could still pwn your whole machine: - If your engine has no other sandbox other than RLBox then they’d probably own your kernel by corrupting a buffer in memory that is being passed to a GPU driver (or something along those lines). RLBox will allow that corruption because the buffer is indeed in the program’s memory. - If the engine has some other sandbox on top of RLbox then the bad guys will corrupt a buffer used for sending messages to brokers, so they can then pop those brokers. Just as they would without RLbox. Fil-C prevents all of that because it uses a pointer capability model and enforces it rigorously. So, RLbox could be infinity faster than Fil-C and I still wouldn’t care
      - IshKebab 1y ago
        That feels like a very binary view of security. There are certainly cases where something like RLBox takes you from "horrific anything-goes C security" to "probably fine". Image parsing for example, which is a common source of vulnerabilities. So the question of performance is still relevant, even if RLBox's security properties are less tight.
        pizlonator 1y ago
        I think you're trying to compare RLBox and Fil-C because you view them both as "add more security". I get it and that's not entirely unfair, but... They're just way too different. RLBox is a containerization technology. Fil-C is a memory safety technology. Like, there's a world where you would use both of them stacked on top of one another, because Fil-C does memory safety without containerizing while RLBox does containerization without memory safety.
pjmlp 1y ago
That has been the qualm of programming since the Assembly days, unfortunately most developers aren't Ivan Suntherland, Alan Kay, Steve Jobs, Bret Victor, and other similar minded visionaries. Most of us sadly cargo cult urban myths and only believe in what is running in front of them like Saint Thomas, as to have any kind of feeling how great some things could be like. Hence why so many UNIX and C clones, instead of creating something new, to be honest those two guys were also visionaries despite some of the flaws, back in 1970's.

johncolanduoni 1y ago

What do the benchmarks look like? My main concern with this approach would be that the performance envelope would eliminate it for the use-cases where C/C++ are still popular. If throughput/latency/footprint are too similar to using Go or what have you, there end up being far fewer situations in which you would reach for it.

pizlonator 1y ago
Some programs run as fast as normally. That's admittedly not super common, but it happens. Some programs have a ~4x slowdown. That's also not super common, but it happens. Most programs are somewhere in the middle. > for the use-cases where C/C++ are still popular This is a myth. 99% of the C/C++ code you are using right now is not perf sensitive. It's written in C or C++ because: - That's what it was originally written in and nobody bothered to write a better version in any other language. - The code depends on a C/C++ library and there doesn't exist a high quality binding for that library in any other language, which forces the dev to write code in C/C++. - C/C++ provides the best level of abstraction (memory and syscalls) for the use case. Great examples are things like shells and text editors, where the syscalls you want to use are exposed at the highest level of fidelity in libc and if you wrote your code in any other language you'd be constrained by that language's library's limited (and perpetually outdated) view of those syscalls.
- baranul 1y ago
  Very good answer and agree. There seems to be a psychological component wrapped up in the mythology versus the reality of what's necessary.
- monkeyelite 1y ago
  You are making a lot of assumptions about my code.
  - pizlonator 1y ago
    I'm not meaning to. I've ported a lot of programs to Fil-C and I'm reacting to what I learn. I am curious though. What assumptions do you think I'm making that you think are invalid?
    - monkeyelite 1y ago
      - that 4x would not impact user experience - that my code is on a Unix time sharing system - that I only use C or C++ because I inherited it - that Unix tools do not benefit from efficient programming because of syscalls - that multi-threaded garbage collection would be good for perf (assuming I’m not sharing the system)
      - pizlonator 1y ago
        You are posting on HN in a browser presumably. I am familiar with the stack of C/C++ code involved in that because I was a browser dev for 10+ years. Most of that code is definitely not perf sensitive in the sense that if you slowed it down by 4x, you might not notice most of the time (Browser performance is like megapixels or megahertz … a number that marketing nerds can use to flex, but that is otherwise mostly irrelevant) When I say 99% of the C code you use, I mean “use” as a human using a computer, not “use” as a dependency in your project. I’m not here to tell you that your C or C++ project should be compiled with Fil-C. I am here to tell you that most of the C/C++ programs you use as an end user could be compiled with Fil-C and you wouldn’t experience an degraded experience if that happened
        mike_hearn 1y ago
        You're absolutely right about all of this. People under-estimate how much code gets written in these languages just because decades ago they were chosen as the default language of the project and people are resistant to going full polyglot. Then everything gets written that way including cold paths, utilities, features that are hardly ever used, UI code that's bottlenecked by the network...
- otabdeveloper4 1y ago
  All code is perf-sensitive. Also, literally every language claims "only a x2 slowdown compared to C". We still end up coding in C++, because see the first point.
  - pizlonator 1y ago
    I’m not claiming only 2x slowdown. It’s 4x for some of the programs I’ve measured. 4x > 2x. I’m not here to exaggerate the perf of Fil-C. I actually think that figuring out the true perf cost is super interesting! > All code is perf-sensitive. That can’t possibly be true. Meta runs on PHP/Hack, which are ridiculously slow. Code running in your browser is JS, which is like 40x slower than Yolo-C++ and yet it’s fine. So many other examples of folks running code that is just hella slow, way slower than “4x slower than C”
    - otabdeveloper4 1y ago
      All code is perf-sensitive. Not all code is important enough to be written as we'd like it to be.
      - zelphirkalt 1y ago
        We don't like all code to be written in some C or C++ dialect.
      - gf000 1y ago
        Then why use C? Take a look at actually perf-sensitive hot loops, and they are predominantly some inline assembly with a bunch of SIMD hacks, which can be 1000x times faster than C...
        otabdeveloper4 1y ago
        Unfortunately inline assembly isn't portable even to different revisions of one CPU architecture, much less different ones.
    - Sesse__ 1y ago
- silisili 1y ago
  Super cool. What is your goal wrt performance? Is low 1.x-ish on average attainable, in your opinion?
  - pizlonator 1y ago
    I think that worst case 2x, average case 1.5x is attainable. - Code that uses SIMD or that is mostly dealing with primitive data in large arrays will get to close to 1x - Code that walks trees and graphs, like interpreted or compilers do, might end up north of 2x unless I am very successful at implementing all of the optimizations I am envisioning. - Code that is IO bound or interactive is already close to 1x
- johncolanduoni 1y ago
  While there are certainly other reasons C/C++ get used in new projects, I think 99% not being performance or footprint sensitive is way overstating it. There's tons of embedded use cases where a GC is not going to fly just from a code size perspective, let alone latency. That's mostly where I've often seen C (not C++) for new programs. Also, if Chrome gets 2x slower I'll finally switch back to Firefox. That's tens of millions of lines of performance-sensitive C++ right there. That actually brings up another question: how would trying to run a JIT like V8 inside Fil-C go? I assume there would have to be some bypass/exit before jumping to generated code - would there need to be other adjustments?
  - kragen 1y ago
    Latency is the killer, I think. A GC can be on the order of 100 instructions.
    - pizlonator 1y ago
      It’s a concurrent GC. Latency won’t kill you I’ll admit that if you are in the business of counting instructions then other things in Fil-C will kill you. Most of the overhead is from pointer chasing. See https://fil-c.org/invisicaps https://fil-c.org/invisicaps
      - kragen 1y ago
        "Concurrent" doesn't usually mean "bounded in worst-case execution time", especially on a uniprocessor. Does it in this case? InvisiCaps sound unbelievably amazing. Even CHERI hasn't managed to preserve pointer size.
        pizlonator 1y ago
        > "Concurrent" doesn't usually mean "bounded in worst-case execution time", especially on a uniprocessor. Does it in this case? Meh. I was in the real time GC game for a while, when I was younger. Nobody agrees on what it really means to bound the worst case. If you're a flight software engineer, it means one thing. If you're a game developer, it means something else entirely. And if you're working on the audio stack specifically, it means yet another thing (somewhere in between game and flight). So let me put it this way, using the game-audio-flight framework: - Games: I bound worst case execution time, just assuming a fair enough OS scheduler, even on uniprocessor. - Audio: I bound worst case execution time if you have multiple cores. - Flight: I don't bound worst case execution time. Your plane crashes and everyone is dead
- hnlmorg 1y ago
  There’s loads of good shells and text editors written in other languages. I’m the author of a shell written in Go and it’s more capable than Zsh.
  - kragen 1y ago
    Interesting, what's it called? How does it compare to Andy Chu's Oil?
    - hnlmorg 1y ago
      It’s called Murex: https://github.com/lmorg/murex https://github.com/lmorg/murex It’s a typed shell. So you can do jq-like data manipulation against a plethora of different documents. Unlike Zsh et al that are still ostensibly limited to just whitespace-delimited lists.
      - kragen 1y ago
        Interesting! Thanks for the link!
- Sesse__ 1y ago
  > Great examples are things like shells and text editors I regularly get annoyed that my shell and text editor is slow :-) I do agree on principle, though.
- IshKebab 1y ago
  > Some programs have a ~4x slowdown How does it compare to something like RLBox? > This is a myth. 99% of the C/C++ code you are using right now is not perf sensitive. I don't think that's true, or at best its a very contorted definition of "perf sensitive". Most code is performance sensitive in my opinion - even shitty code written in Python or Ruby. I would like it to be faster. Take Asciidoctor for example. Is that "performance sensitive"? Hell yes!
  - pizlonator 1y ago
    > How does it compare to something like RLBox? I don’t know and it doesn’t matter because RLBox doesn’t make your C code memory safe. It only containerizes it. Like, if you put a database in RLBox then a hacker could still use a memory safety bug to corrupt or exfiltrate sensitive data. If you put a browser engine in RLBox then a hacker could still pwn your whole machine: - If your engine has no other sandbox other than RLBox then they’d probably own your kernel by corrupting a buffer in memory that is being passed to a GPU driver (or something along those lines). RLBox will allow that corruption because the buffer is indeed in the program’s memory. - If the engine has some other sandbox on top of RLbox then the bad guys will corrupt a buffer used for sending messages to brokers, so they can then pop those brokers. Just as they would without RLbox. Fil-C prevents all of that because it uses a pointer capability model and enforces it rigorously. So, RLbox could be infinity faster than Fil-C and I still wouldn’t care
    - IshKebab 1y ago
      That feels like a very binary view of security. There are certainly cases where something like RLBox takes you from "horrific anything-goes C security" to "probably fine". Image parsing for example, which is a common source of vulnerabilities. So the question of performance is still relevant, even if RLBox's security properties are less tight.
      - pizlonator 1y ago
        I think you're trying to compare RLBox and Fil-C because you view them both as "add more security". I get it and that's not entirely unfair, but... They're just way too different. RLBox is a containerization technology. Fil-C is a memory safety technology. Like, there's a world where you would use both of them stacked on top of one another, because Fil-C does memory safety without containerizing while RLBox does containerization without memory safety.

pjmlp 1y ago

That has been the qualm of programming since the Assembly days, unfortunately most developers aren't Ivan Suntherland, Alan Kay, Steve Jobs, Bret Victor, and other similar minded visionaries. Most of us sadly cargo cult urban myths and only believe in what is running in front of them like Saint Thomas, as to have any kind of feeling how great some things could be like. Hence why so many UNIX and C clones, instead of creating something new, to be honest those two guys were also visionaries despite some of the flaws, back in 1970's.