3 ms·

I think that all of those tools can be recompiled with Fil-C today and you get memory safety while retaining the original functionality.

badmintonbaseba 2y ago
What about performance?
- pizlonator 2y ago
  For these tools, you won’t notice.
  - badmintonbaseba 2y ago
    What modifications are needed to run through Fil-C, if any? It looks like you forked some of the software to run through Fil-C. Are you subsetting the language, or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C?
    - pizlonator 2y ago
      > What modifications are needed to run through Fil-C, if any? Most likely none. The most likely bugs you'll encounter are due to Fil-C using musl, not glibc (that always leads to some incompatibilities for GNU code). > Are you subsetting the language No. > or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C? Sometimes, but rarely.
      - badmintonbaseba 2y ago
        Super interesting. Tempting to hook it up with conan to build our dependencies and set it up with our unit tests at least. If incompatibilities are mostly due to the libc then I don't think any of our C++ dependencies would care.
- ape4 2y ago
  "Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. I'm actively working on performance optimizations for Fil-C, so that 4x number will go down." source https://github.com/pizlonator/llvm-project-deluge/blob/deluge/Manifesto.md https://github.com/pizlonator/llvm-project-deluge/blob/delug...
  - pizlonator 2y ago
    That’s for compute bound workloads. None of these tools that they’re oxidizing is compute bound
    - burntsushi 2y ago
      For the very common case of a file already being in RAM, tools like `sort` are absolutely compute bound. On my M2 mac mini: $ hyperfine "LC_ALL=C sort < subtitles2018.en" "LC_ALL=C gsort < subtitles2018.en" Benchmark 1: LC_ALL=C sort < subtitles2018.en Time (mean ± σ): 2.007 s ± 0.005 s [User: 1.940 s, System: 0.064 s] Range (min … max): 1.997 s … 2.015 s 10 runs Benchmark 2: LC_ALL=C gsort < subtitles2018.en Time (mean ± σ): 898.5 ms ± 9.7 ms [User: 2795.8 ms, System: 93.6 ms] Range (min … max): 875.0 ms … 906.9 ms 10 runs Summary LC_ALL=C gsort < subtitles2018.en ran 2.23 ± 0.02 times faster than LC_ALL=C sort < subtitles2018.en Info about the tools: $ which sort /usr/bin/sort $ which gsort /opt/homebrew/bin/gsort $ brew info coreutils | head -n3 ==> coreutils: stable 9.6 (bottled), HEAD GNU File, Shell, and Text utilities https://www.gnu.org/software/coreutils/ There are other tools in coreutils for which this applies as well. The GNU tools have overall been pretty heavily optimized. Why do you think they did that if it literally didn't matter? Just for shits & giggles?
      - pizlonator 2y ago
        I can't remember the last time I cared about how long the sort tool took to run. Probably never. You should try that benchmark with sort compiled with Fil-C.

badmintonbaseba 2y ago

What about performance?

pizlonator 2y ago
For these tools, you won’t notice.
- badmintonbaseba 2y ago
  What modifications are needed to run through Fil-C, if any? It looks like you forked some of the software to run through Fil-C. Are you subsetting the language, or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C?
  - pizlonator 2y ago
    > What modifications are needed to run through Fil-C, if any? Most likely none. The most likely bugs you'll encounter are due to Fil-C using musl, not glibc (that always leads to some incompatibilities for GNU code). > Are you subsetting the language No. > or do those libraries/applications run into some "benign" UB under normal operation that is caught by Fil-C? Sometimes, but rarely.
    - badmintonbaseba 2y ago
      Super interesting. Tempting to hook it up with conan to build our dependencies and set it up with our unit tests at least. If incompatibilities are mostly due to the libc then I don't think any of our C++ dependencies would care.
ape4 2y ago
"Fil-C is currently 1.5x slower than normal C in good cases, and about 4x slower in the worst cases. I'm actively working on performance optimizations for Fil-C, so that 4x number will go down." source https://github.com/pizlonator/llvm-project-deluge/blob/deluge/Manifesto.md https://github.com/pizlonator/llvm-project-deluge/blob/delug...
- pizlonator 2y ago
  That’s for compute bound workloads. None of these tools that they’re oxidizing is compute bound
  - burntsushi 2y ago
    For the very common case of a file already being in RAM, tools like `sort` are absolutely compute bound. On my M2 mac mini: $ hyperfine "LC_ALL=C sort < subtitles2018.en" "LC_ALL=C gsort < subtitles2018.en" Benchmark 1: LC_ALL=C sort < subtitles2018.en Time (mean ± σ): 2.007 s ± 0.005 s [User: 1.940 s, System: 0.064 s] Range (min … max): 1.997 s … 2.015 s 10 runs Benchmark 2: LC_ALL=C gsort < subtitles2018.en Time (mean ± σ): 898.5 ms ± 9.7 ms [User: 2795.8 ms, System: 93.6 ms] Range (min … max): 875.0 ms … 906.9 ms 10 runs Summary LC_ALL=C gsort < subtitles2018.en ran 2.23 ± 0.02 times faster than LC_ALL=C sort < subtitles2018.en Info about the tools: $ which sort /usr/bin/sort $ which gsort /opt/homebrew/bin/gsort $ brew info coreutils | head -n3 ==> coreutils: stable 9.6 (bottled), HEAD GNU File, Shell, and Text utilities https://www.gnu.org/software/coreutils/ There are other tools in coreutils for which this applies as well. The GNU tools have overall been pretty heavily optimized. Why do you think they did that if it literally didn't matter? Just for shits & giggles?
    - pizlonator 2y ago
      I can't remember the last time I cared about how long the sort tool took to run. Probably never. You should try that benchmark with sort compiled with Fil-C.