Hacker News Reader

Comment by pizlonator | Hacker News Reader

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

View on HN

What about performance?

For these tools, you won’t notice.

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?

> 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.

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.

"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/delug...

That’s for compute bound workloads. None of these tools that they’re oxidizing is compute bound

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?

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.

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.

I don't know what two sorts you're comparing, but I'm guessing neither one of them is compiled in Fil-C. Is it really the case that the Rust one is 2x faster? Or is it that the C one is 2x faster? Also, it's just one benchmark of sort, so for all we know the two sort implementations really have the same perf if you test a broader set of cases.

The interesting question - going back to my original post - is what the Fil-C slow down would be. Just because a program takes 100% CPU doesn't mean it'll experience bad overheads when compiled with Fil-C.

I don't know what you mean by "complete MRE". You can download the Fil-C binaries and point coreutils' configure script at the compiler and see what happens. It's not hard.

> I don't know what two sorts you're comparing

I showed you in my original comment. Both are C. One is the `sort` that comes with macOS, as shown at `/usr/bin/sort`, and the other is from GNU coreutils.

> Also, it's just one benchmark of sort, so for all we know the two sort implementations really have the same perf if you test a broader set of cases.

Sure, you're welcome to come up with a more comprehensive benchmark suite to support YOUR claim that tools like `sort` are not "compute bound" and you won't "notice" a difference in speed. I agree that 1 benchmark is insufficient to make generalized claims about performance. But it is very obviously better than 0 benchmarks (which is the number you have provided to support your claim).

In the interest of over-communicating, please note the qualification I gave originally: for files cached in RAM.

> I don't know what you mean by "complete MRE". You can download the Fil-C binaries and point coreutils' configure script at the compiler and see what happens. It's not hard.

Cool, then you should be able to show me a transcript of the precise commands necessary to do this very easily!

Reply on news.ycombinator.com