4 ms·

What about performance?

by badmintonbaseba 2y ago

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.
      - burntsushi 2y ago
        If you had said, "The perf difference isn't enough for me to care about," then I wouldn't have responded or said anything. That's totally fair and reasonable. Who am I to say what you should care about? If you want to spend more time waiting for shit to finish, that's your prerogative. But what you said is (emphasis mine): > For these tools, you won’t notice. > None of these tools that they’re oxidizing is compute bound just blatantly wrong and a >2x difference in perf is absolutely relevant and something I would notice personally. Maybe I'm the only one who likes sorting to be as fast as possible, but I'd guess not. > You should try that benchmark with sort compiled with Fil-C. Feel free to post a complete MRE for doing this and I'd be happy to run it.

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.
    - burntsushi 2y ago
      If you had said, "The perf difference isn't enough for me to care about," then I wouldn't have responded or said anything. That's totally fair and reasonable. Who am I to say what you should care about? If you want to spend more time waiting for shit to finish, that's your prerogative. But what you said is (emphasis mine): > For these tools, you won’t notice. > None of these tools that they’re oxidizing is compute bound just blatantly wrong and a >2x difference in perf is absolutely relevant and something I would notice personally. Maybe I'm the only one who likes sorting to be as fast as possible, but I'd guess not. > You should try that benchmark with sort compiled with Fil-C. Feel free to post a complete MRE for doing this and I'd be happy to run it.