4 ms·

Cool project! I take it the goal is that, overhead being acceptable, most C / C++ programmes don't actually "have to be" rewritten in something like Rust? I wo

• pornel 11mo ago
  Note that Fil-C is a garbage-collected language that is significantly slower than C. It's not a target for writing new code (you'd be better off with C# or golang), but something like sandboxing with WASM, except that Fil-C crashes more precisely.
  • thesz 11mo ago
    From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang" Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most interpreters are. The ROOT C/C++ interpreter is 20+ times slower than binary code, for example.
    • silotis 11mo ago
      Cryptographic software is probably close to a best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. As long as Fil-C is able to avoid doing anything expensive in the inner loops you get good performance.
      • thesz 11mo ago
        > best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. This describes most C programs and many, if not most, C++ programs. Basically, this is how C/C++ code is being written, by avoiding memory management, especially in tight loops.
        • silotis 11mo ago
          This depends heavily on what problem domain you're talking about. For example, a DBMS is necessarily going to shuffle a lot of data into and out of memory.
          • jandrewrogers 11mo ago
            Most databases do almost no memory management at runtime, at least not in any conventional sense. They mostly just DMA disk into and out of a fixed set of buffers. Objects don't have a conventional lifetime.
            • deleted 11mo ago
              [deleted]
          • quotemstr 11mo ago
            It depends. Consider DuckDB or another heavily vectorized columnar DB: there's a big part of the system (SQL parser, storage chunk manager, etc.) that's not especially performance-sensitive and a set of tiny, fast kernels that do things like predicate-push-down-based full table scans, ART lookups, and hash table creation for merge joins. DuckDB is a huge pile of C++. I don't see a RIIR taking off before AGI. But you know what might work? Take current DuckDB, compile it with Fil-C, and use a new escape hatch to call out to the tiny unsafe kernels that do vectorized high-speed columnar data operations on fixed memory areas that the buffers safe code set up on behalf of the unsafe kernels. That's how it'd probably work if DuckDB were implemented in Rust today, and it's how it could be made to work with Fil-C without a major rewrite. Granted, this model would require Fil-C's author to become somewhat less dogmatic about having no escape hatches at all whatsoever, but I suspect he'll un-harden his heart as his work gains adoption and legitimate use-cases for an FFI/escape hatch appear.
            • kragen 11mo ago
              > DuckDB is a huge pile of C++. I don't see a RIIR taking off before AGI. While I'm not a big fan of rewriting things, all of DuckDB has been written in the last 10 years. Surely a rewrite with the benefit of hindsight could reach equivalent functionality in less than 10 years?
    • vacuity 11mo ago
      Along with the sibling comment, microbenchmarks should not be used as authoritative data when the use case is full applications. For that matter, highly optimized Java or Go may be "1 to 4 times as slow as plain C". Fil-C has its merits, but they should be described carefully, just with any technology.
      • nicoburns 11mo ago
        Or JavaScript for that matter
      • thesz 11mo ago
        I replied to unwarranted (to my eye) call that Fil-C is significantly slower than plain C. Fil-C has its drawbacks, but they should be described carefully, just with any technology.
        • vacuity 11mo ago
          I maintain that microbenchmarks are not convincing, but you have a fair point that GP's statement is unfounded, and now I've made a reply to GP to that effect.
    • MangoToupe 11mo ago
      What does "significantly" mean to you? To my ear, "significantly" means "statistically significant".
  • galangalalgol 11mo ago
    What language do people considering c as an option for a new project consider? Rust is the obvious one we aren't going to discuss because then we won't be able to talk about anything else, Zig is probably almost as well loved and defended, but it isn't actually memory safe, just much easier to be memory safe. As you say, c# and go, also maybe f# and ocaml if we are just writing simple c style stuff none of those would look all that different. Go jhs some ub related to concurrency that people run into, but most of these simple utilities are either single threaded or fine grained parallel which is pretty easy to get right. Julia too maybe?
    • summarity 11mo ago
      In terms of GC quality, Nim comes to mind.
      • galangalalgol 11mo ago
        I keep ignoring nim for some reason. How fast is it with all the checks on? The benchmarks for it julia, and swift typically turn off safety checks, which is not how I would run them.
        • adgjlsfhk1 11mo ago
          In Julia, at least, bounds checks tend to be a pretty minor hit (~20%) unless the bounds check gets in the way of vectorization
        • cb321 11mo ago
          Since anything/0 = infinity, these kinds of things always depend upon what programs do and as a sibling comment correctly observes how much they interfere with SIMD autovectorization and sevral other things. That said, as a rough guideline, nim c -d=release can certainly be almost the same speed as -d=danger and is often within a few (single digits) percent. E.g.: .../bu(main)$ nim c -d=useMalloc --panics=on --cc=clang -d=release -o=/t/rel unfold.nim Hint: mm: orc; opt: speed; options: -d:release 61608 lines; 0.976s; 140.723MiB peakmem; proj: .../bu/unfold.nim; out: /t/rel [SuccessX] .../bu(main)$ nim c -d=useMalloc --panics=on --cc=clang -d=danger -o=/t/dan unfold.nim Hint: mm: orc; opt: speed; options: -d:danger 61608 lines; 2.705s; 141.629MiB peakmem; proj: .../bu/unfold.nim; out: /t/dan [SuccessX] .../bu(main)$ seq 1 100000 > /t/dat .../bu(main)$ /t /t$ re=(chrt 99 taskset -c 2 env -i HOME=$HOME PATH=$PATH) /t$ $re tim "./dan -n50 <dat>/n" "./rel -n50 <dat>/n" 225.5 +- 1.2 μs (AlreadySubtracted)Overhead 4177 +- 15 μs ./dan -n50 <dat>/n 4302 +- 17 μs ./rel -n50 <dat>/n /t$ a (4302 +- 17)/(4177 +- 15) 1.0299 +- 0.0055 /t$ a 299./55 5.43636... # kurtosis=>5.4 sigmas is not so significant Of course, as per my first sentence, the best benchmarks are your own applications run against your own data and its idiosyncratic distributions. EDIT: btw, /t -> /tmp which is a /dev/shm bind mount while /n -> /dev/null.
  • quotemstr 11mo ago
    WASM is a sandbox. It doesn't obviate memory safety measures elsewhere. A program with a buffer overflow running in WASM can still be exploited to do anything that program can do within in WASM sandbox, e.g. disclose information it shouldn't. WASM ensures such a program can't escape its container, but memory safety bugs within a container can still be plenty harmful.
    • bonzini 11mo ago
      At least WASM can be added incrementally. Fil-C is all or nothing and it cannot be used without rebuilding everything. In that respect a sandbox ranks lower in comprehensiveness but higher in practicality and that's the main issue with Fil-C. It's extremely impressive but it's not a practical solution for C's memory safety issues.
    • CryZe 11mo ago
      You can buffer overflow in fil-c and it won't detect it unless the entire buffer was its own stack or heap allocation with nothing following it (and also it needs to be a multiple of 16 bytes, cause that's padding that fil-c allows you to overflow into). So it arguably isn't much different from wasm. Quick example: typedef struct Foo { int buf[2]; float some_float; } Foo; int main(void) { Foo foo = {0}; for (size_t i = 0; i < 3; ++i) { foo.buf[i] = 0x3f000000; printf("foo.buf[%zu]: %d\n", i, foo.buf[i]); } printf("foo.some_float: %f\n", foo.some_float); } This overflows into the float, not causing any panics, printing 0.5 for the float.
  • vacuity 11mo ago
    A GC lang isn't necessarily significantly slower than C. You should qualify your statements. Moreover, this is a variant of C, which means that the programs are likely less liberal with heap allocations. It remains to be seen how much of a slowdown Fil-C imposes under normal operating conditions. Moreover, although it is indeed primarily suited for existing programs, its use in new programs isn't necessarily worse than, e.g., C# or Go. If performance is the deciding factor, probably use Rust, Zig, Nim, D, etc. .
  • fithisux 11mo ago
    Test with Fil-C, compile with gcc into production. Easy.
• ibejoeb 11mo ago
  Filip of Fil-C is at Epic. Epic owns the copyright.