4 ms·

And I'm not done optimizing. The perf will get better. Rust and Yolo-C will always be faster, but right now we can't know what the difference will be. Top opti

And I'm not done optimizing. The perf will get better. Rust and Yolo-C will always be faster, but right now we can't know what the difference will be. Top optimization opportunities: - InvisiCaps 2.0. While implementing the current capability model, when I was about 3/4 of the way done with the rewrite, I realized that if I had done it differently I would have avoided two branch+compares on every pointer load. That's huge! I just haven't had the appetite for doing yet another rewrite recently. But I'll do it eventually. - ABI. Right now, Fil-C uses a binary interface that relies on lowering to what ELF is capable of. This introduces a bunch of overhead on every global variable access and every function call. All of this goes away if Fil-C gets its own object file format. That's a lot of work, but it will happen in Fil-C gets more adoption. - Better abstract interpreter. Fil-C already has an abstract interpreter in the compiler, but it's not nearly as smart as it could be. For example, it doesn't have octagon domain yet. Giving it octagon domain will dramatically improve the performance of loops. - More intrinsics. Right now, a lot of libc functions that are totally memory safe but are implemented in assembly are implemented in plain Fil-C instead right now, just because of how the libc ports happened to work out. Like, say you call some <math.h> function that takes doubles and returns doubles - it's going to be slower in Fil-C today because you'll end up in the generic C code version compiled with Fil-C. No good reason for this! It's just grunt work to fix! - The calling convention itself is trash right now - it involves passing things through a thread-local buffer. It's less trashy than the calling convention I started out with (that allocated everything in the heap lmao), but still. There's nothing fundamentally preventing a Fil-C register-based calling convention, but it would take a decent amount of work to implement. There are probably other perf optimization opportunities that I'm either forgetting right now or that haven't been found yet. It's still early days!

senderista 1y ago
So you'd have to implement binfmt_misc for the new binary format? Will you need to write your own ld.so?
- pizlonator 1y ago
  Yes and yes
kragen 1y ago
The savings of two conditional branches sounds interesting; what would the change be?
- pizlonator 1y ago
  - Don’t put flags in the high bits of the aux pointer. Instead if an object has flags, it’ll have a fatter header. Most objects don’t have flags. - Give up on lock freedom of atomic pointers. This is a fun one because theoretically, it’s worse. But it comes with a net perf improvement because there’s no need to check the low bit of lowers.
  - kragen 1y ago
    Scary! I'm excited to see how it turns out.
jacquesm 1y ago
This is such an interesting project. I've always been firmly in the 'let it crash' camp for bugs, the sooner and the closer to the offending piece of code you can generate a crash the better. Maybe it would be possible to embed Fil-C in a test-suite combined with a fuzzing like tool that varies input to try really hard to get a program to trigger an abend. As long as it is possible to fuzz your way to a crash in Fil-C that would be a sign that there is more work to do. That way 'passes Fil-C' would be a bit like running code under valgrind and move the penalty to the development phase rather than the runtime. Is this feasible or am I woolgathering, and is Fil-C only ever going to work by using it to compile the production code?
- SkiFire13 1y ago
  From what I understand some things in Fil-C work "as expected" instead of crashing (e.g. dereferencing a pointer to an out of scope variable will give you the old value of that variable), so it won't work as a sanitizer.
  - 1718627440 1y ago
    You can use the built-in sanitizer from your compiler though.
    - SkiFire13 1y ago
      At that point why use Fil-C for this though?
      - 1718627440 1y ago
        Because you don't want to let it crash in production? Sanitizer for testing Fil-C for shipping.
        pornel 1y ago
        Fil-C will crash on memory corruption too. In fact, its main advantage is crashing sooner. All the quick fixes for C that don't require code rewrites boil down to crashing. They don't make your C code less reliable, they just make the unreliability more visible. To me, Fil-C is most suited to be used during development and testing. In production you can use other sandboxing/hardening solutions that have lower overhead, after hopefully shaking out most of the bugs with Fil-C.
qdotme 1y ago
Can you elaborate on what makes ELF (potentially with custom sections/extension and maybe custom ld.so plugin) insufficient? A lot of remarkably unusual stuff has been shoved into the format without breaking the tooling, so wondering what the restrictions are.
baq 1y ago
> Rust and Yolo-C will always be faster graydon points in that direction, but since you're here: how feasible is a hypothetical Fil-Unsafe-Rust? would you need to compile the whole program in Fil-Rust to get the benefits of Fil-Unsafe-Rust?
- zozbot234 1y ago
  It's reasonably easy if you can treat the Safe Rust and Fil-Unsafe-Rust code as accessing different address spaces (in the C programming sense of "a broad subset of memory that a pointer is limited to", not the general OS/hardware sense), since that's essentially what the bespoke Fil-C ABI amounts to in the first place. Which of course is not really a good fit for every use of Unsafe Rust, but might suffice for some of them.
- kobebrookskC3 1y ago
  what would fil-rust do that miri doesn't?
  - baq 1y ago
    e.g. validate safety across safe/unsafe boundaries
    - estebank 1y ago
      Miri does do that? It is not aware of the distinction to begin with (which is one of the use cases of the tool: it lets us exercise safe code to ensure there aren't memory violations caused by incorrect MIR lowering). I might be mistaking what you mean. Miri's big limitation is not being able to interface with FFI.
      - baq 1y ago
        hmmm I thought miri was used in the compiler for static analysis, wasn't aware it's a runtime interpreter. I guess the primary reason would be running hardened code in production without compromising performance too much, same as you would run Fil-C compiled software instead of the usual way. I've no idea if it's feasible to run miri in prod.
pjmlp 1y ago
Love your Yolo-C remark. :)

senderista 1y ago

So you'd have to implement binfmt_misc for the new binary format? Will you need to write your own ld.so?

pizlonator 1y ago
Yes and yes

kragen 1y ago

The savings of two conditional branches sounds interesting; what would the change be?

pizlonator 1y ago
- Don’t put flags in the high bits of the aux pointer. Instead if an object has flags, it’ll have a fatter header. Most objects don’t have flags. - Give up on lock freedom of atomic pointers. This is a fun one because theoretically, it’s worse. But it comes with a net perf improvement because there’s no need to check the low bit of lowers.
- kragen 1y ago
  Scary! I'm excited to see how it turns out.

jacquesm 1y ago

This is such an interesting project. I've always been firmly in the 'let it crash' camp for bugs, the sooner and the closer to the offending piece of code you can generate a crash the better. Maybe it would be possible to embed Fil-C in a test-suite combined with a fuzzing like tool that varies input to try really hard to get a program to trigger an abend. As long as it is possible to fuzz your way to a crash in Fil-C that would be a sign that there is more work to do. That way 'passes Fil-C' would be a bit like running code under valgrind and move the penalty to the development phase rather than the runtime. Is this feasible or am I woolgathering, and is Fil-C only ever going to work by using it to compile the production code?

SkiFire13 1y ago
From what I understand some things in Fil-C work "as expected" instead of crashing (e.g. dereferencing a pointer to an out of scope variable will give you the old value of that variable), so it won't work as a sanitizer.
- 1718627440 1y ago
  You can use the built-in sanitizer from your compiler though.
  - SkiFire13 1y ago
    At that point why use Fil-C for this though?
    - 1718627440 1y ago
      Because you don't want to let it crash in production? Sanitizer for testing Fil-C for shipping.
      - pornel 1y ago
        Fil-C will crash on memory corruption too. In fact, its main advantage is crashing sooner. All the quick fixes for C that don't require code rewrites boil down to crashing. They don't make your C code less reliable, they just make the unreliability more visible. To me, Fil-C is most suited to be used during development and testing. In production you can use other sandboxing/hardening solutions that have lower overhead, after hopefully shaking out most of the bugs with Fil-C.

qdotme 1y ago

Can you elaborate on what makes ELF (potentially with custom sections/extension and maybe custom ld.so plugin) insufficient? A lot of remarkably unusual stuff has been shoved into the format without breaking the tooling, so wondering what the restrictions are.

baq 1y ago

> Rust and Yolo-C will always be faster graydon points in that direction, but since you're here: how feasible is a hypothetical Fil-Unsafe-Rust? would you need to compile the whole program in Fil-Rust to get the benefits of Fil-Unsafe-Rust?

zozbot234 1y ago
It's reasonably easy if you can treat the Safe Rust and Fil-Unsafe-Rust code as accessing different address spaces (in the C programming sense of "a broad subset of memory that a pointer is limited to", not the general OS/hardware sense), since that's essentially what the bespoke Fil-C ABI amounts to in the first place. Which of course is not really a good fit for every use of Unsafe Rust, but might suffice for some of them.
kobebrookskC3 1y ago
what would fil-rust do that miri doesn't?
- baq 1y ago
  e.g. validate safety across safe/unsafe boundaries
  - estebank 1y ago
    Miri does do that? It is not aware of the distinction to begin with (which is one of the use cases of the tool: it lets us exercise safe code to ensure there aren't memory violations caused by incorrect MIR lowering). I might be mistaking what you mean. Miri's big limitation is not being able to interface with FFI.
    - baq 1y ago
      hmmm I thought miri was used in the compiler for static analysis, wasn't aware it's a runtime interpreter. I guess the primary reason would be running hardened code in production without compromising performance too much, same as you would run Fil-C compiled software instead of the usual way. I've no idea if it's feasible to run miri in prod.

pjmlp 1y ago

Love your Yolo-C remark. :)