Most active commenters
  • otabdeveloper4(4)

←back to thread

597 points pizlonator | 11 comments | | HN request time: 0.085s | source | bottom
Show context
crawshaw ◴[] No.45134578[source]
It is great that Fil-C exists. This is the sort of technique that is very effective for real programs, but that developers are convinced does not work. Existence proofs cut through long circular arguments.
replies(2): >>45134840 #>>45135366 #
johncolanduoni ◴[] No.45134840[source]
What do the benchmarks look like? My main concern with this approach would be that the performance envelope would eliminate it for the use-cases where C/C++ are still popular. If throughput/latency/footprint are too similar to using Go or what have you, there end up being far fewer situations in which you would reach for it.
replies(1): >>45134852 #
pizlonator ◴[] No.45134852[source]
Some programs run as fast as normally. That's admittedly not super common, but it happens.

Some programs have a ~4x slowdown. That's also not super common, but it happens.

Most programs are somewhere in the middle.

> for the use-cases where C/C++ are still popular

This is a myth. 99% of the C/C++ code you are using right now is not perf sensitive. It's written in C or C++ because:

- That's what it was originally written in and nobody bothered to write a better version in any other language.

- The code depends on a C/C++ library and there doesn't exist a high quality binding for that library in any other language, which forces the dev to write code in C/C++.

- C/C++ provides the best level of abstraction (memory and syscalls) for the use case.

Great examples are things like shells and text editors, where the syscalls you want to use are exposed at the highest level of fidelity in libc and if you wrote your code in any other language you'd be constrained by that language's library's limited (and perpetually outdated) view of those syscalls.

replies(8): >>45134950 #>>45135063 #>>45135080 #>>45135102 #>>45135517 #>>45136755 #>>45137524 #>>45143638 #
1. otabdeveloper4 ◴[] No.45135063[source]
All code is perf-sensitive.

Also, literally every language claims "only a x2 slowdown compared to C".

We still end up coding in C++, because see the first point.

replies(2): >>45135091 #>>45135539 #
2. pizlonator ◴[] No.45135091[source]
I’m not claiming only 2x slowdown. It’s 4x for some of the programs I’ve measured. 4x > 2x. I’m not here to exaggerate the perf of Fil-C. I actually think that figuring out the true perf cost is super interesting!

> All code is perf-sensitive.

That can’t possibly be true. Meta runs on PHP/Hack, which are ridiculously slow. Code running in your browser is JS, which is like 40x slower than Yolo-C++ and yet it’s fine. So many other examples of folks running code that is just hella slow, way slower than “4x slower than C”

replies(2): >>45135732 #>>45137035 #
3. Dylan16807 ◴[] No.45135539[source]
> All code is perf-sensitive.

I'm doing some for loops in bash right now that could use 1000x more CPU cycles without me noticing.

Many programs use negligible cycles over their entire runtime. And even for programs that spend a lot of CPU and need tons of optimizations in certain spots, most of their code barely ever runs.

> Also, literally every language claims "only a x2 slowdown compared to C".

I've never seen anyone claim that a language like python (using the normal implementation) is generally within the same speed band as C.

The benchmark game is an extremely rough measure but you can pretty much split languages into two groups: 1x-5x slowdown versus C, and 50x-200x slowdown versus C. Plenty of popular languages are in each group.

replies(1): >>45135748 #
4. otabdeveloper4 ◴[] No.45135732[source]
All code is perf-sensitive. Not all code is important enough to be written as we'd like it to be.
replies(2): >>45136464 #>>45136736 #
5. otabdeveloper4 ◴[] No.45135748[source]
> I've never seen anyone claim that a language like python (using the normal implementation) is generally within the same speed band as C.

Live long enough and you will. People claimed it about PyPy back in the day when it was still hype.

replies(1): >>45135813 #
6. Dylan16807 ◴[] No.45135813{3}[source]
Pypy is not the normal implementation. I was specifically excluding special implementations that only do part of a language and do it much faster. Especially with something like pypy that has extremely good best case scenarios, people can get too excited.
7. zelphirkalt ◴[] No.45136464{3}[source]
We don't like all code to be written in some C or C++ dialect.
8. gf000 ◴[] No.45136736{3}[source]
Then why use C? Take a look at actually perf-sensitive hot loops, and they are predominantly some inline assembly with a bunch of SIMD hacks, which can be 1000x times faster than C...
replies(1): >>45149572 #
9. Sesse__ ◴[] No.45137035[source]
FWIW, I just tested it on a random program I wrote recently, and it went from 2.085 seconds with Clang+jemalloc to 18.465 seconds with Fil-C. (No errors were reported, thank goodness!) So that's a 9x new worst case for you :-) It's basically a STL performance torture test, though. TBH I'm impressed that Fil-C just worked on the first try for this.
replies(1): >>45138643 #
10. Sesse__ ◴[] No.45138643{3}[source]
And on the next one, a SIMD-heavy searcher thingie (where it found a real bug, though thankfully “only” reading junk data that would be immediately discarded!), it went from 7.723 to 379.56 seconds, a whopping 49x slowdown.
11. otabdeveloper4 ◴[] No.45149572{4}[source]
Unfortunately inline assembly isn't portable even to different revisions of one CPU architecture, much less different ones.