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”

▲

Sesse__ 5 days ago | parent | next [-]

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.

	▲	Sesse__ 5 days ago \| parent [-]
		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.

▲

otabdeveloper4 5 days ago | parent | prev [-]

All code is perf-sensitive. Not all code is important enough to be written as we'd like it to be.

▲

zelphirkalt 5 days ago | parent | next [-]

We don't like all code to be written in some C or C++ dialect.

▲

gf000 5 days ago | parent | prev [-]

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

	▲	otabdeveloper4 4 days ago \| parent [-]
		Unfortunately inline assembly isn't portable even to different revisions of one CPU architecture, much less different ones.