4 ms·

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

• silotis 1y 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 1y 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 1y 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 1y 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 1y ago
          [deleted]
      • quotemstr 1y 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 1y 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?
          • jitl 1y ago
            the sqlite RIIR is going quite well: https://turso.tech/blog/beyond-the-single-writer-limitation-with-tursos-concurrent-writes https://turso.tech/blog/beyond-the-single-writer-limitation-... (sqlite is quite a bit smaller than DuckDB tho)
            • kragen 1y ago
              Is it? It's much less new.
              • jitl 1y ago
                for one, duckdb includes all of sqlite (and many other dependencies). it knows how to do things like efficiently query over parquet files in s3. it's expansive - a swiss army knife for working with data wherever it's at. sqlite is a "self contained system" depending on no external software except c standard library for target os: > A minimal build of SQLite requires just these routines from the standard C library: > memcmp(), memcpy(), memmove(), memset(), strcmp(), strlen(), strncmp() > Most builds also use the system memory allocation routines: > malloc(), realloc(), free() > Default builds of SQLite contain appropriate VFS objects for talking to the underlying operating system, and those VFS objects will contain operating system calls such as open(), read(), write(), fsync(), and so forth Quoting from the appropriately named https://sqlite.org/selfcontained.html https://sqlite.org/selfcontained.html as a very rough and unfair estimate between the two project's source, sqlite is about 8% the size of duckdb: $ pwd /Users/jitl/src/duckdb/src $ sloc . ---------- Result ------------ Physical : 418092 Source : 317274 Comment : 50113 Single-line comment : 46187 Block comment : 3926 Mixed : 4415 Empty block comment : 588 Empty : 55708 To Do : 136 Number of files read : 2611 ---------------------------- $ cd ~/Downloads/sqlite-amalgamation-3500400/ $ sloc . ---------- Result ------------ Physical : 34742 Source : 25801 Comment : 8110 Single-line comment : 1 Block comment : 8109 Mixed : 1257 Empty block comment : 1 Empty : 2089 To Do : 5 Number of files read : 2 ----------------------------
      • thesz 1y ago
        I am professional database developer. We do not do what you are thinking we are doing. ;)
        • silotis 1y ago
          I was thinking less about the DB data itself and more about temporary allocations that have to be made per-request. The same is true for most server software. Even if arenas are used to reduce the number of allocations you're still doing a lot more memory management than a typical cryptographic benchmark.
• vacuity 1y 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 1y ago
    Or JavaScript for that matter
  • thesz 1y 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 1y 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 1y ago
  What does "significantly" mean to you? To my ear, "significantly" means "statistically significant".