C++ is faster than C

[Lyberta]

So, I'm working on the proposal to get std::byte streams into C++. I already got the official paper number and looking forward to see it discussed in November New York ISO meeting.

The ultimate test of my proposal is to compare performance of file IO to what already exists in the standard. And C has FILE* based IO functions such as fopen, fread, fwrite, etc. So I've run a benchmark and guess what, I'm 30% faster in sequential reads and 38% faster in sequential writes than C.

That's pretty showing. And the only approach I use is to align syscalls with file system sectors, that's pretty basic. Why I win is because C doesn't have templates and constexpr which allow compiler to see through the code and optimize better. In fact, 90% of my code here is constexpr so it gets folded pretty directly to syscalls. I didn't even try to micro-optimize with [[likely]] and [[unlikely]]. These don't exist in C18 and are only expected in C2X, whenever that comes.

What I'm saying is, the people who blindly say that C is faster in C++ could be right in 1990s or 1980s, but modern C++ is years ahead of C in almost everything, including performance. Let the myth die and let people stop using dinosaur like C.

[smcameron]

But C is more fun than C++.

But on a more serious note, what i/o device are you talking about? I guess /dev/null is the fastest. But latencies and throughputs and syscall overhead of a real i/o device should swamp any language differences, I would expect (but maybe I'm wrong). To get the utmost performance out of high performance storage, you have to go multi-threaded... io_uring or the like. Beware of comparing a bad C++ implementation to a bad C implementation and declaring victory.

Edit: After a very quick glance at your github repo, I suspect you're not benchmarking actual i/o, but something else... data marshalling perhaps (but I might be wrong, it was a very quick glance.) For example it's not clear that you're taking the buffer cache out of the picture (via O_DIRECT).

Anyway, all that is fine, if you're getting better performance in real world applications, great. But it might not be better "i/o performance" the way storage people think of it, which tends to be along the lines of "how many 4k random reads can I do in a second?" "A million" would be a "very good performance" answer to that question say 5 years ago. I don't know what a "very good performance" answer would be today, but probably more than a million 4k random reads/sec. 5 years ago, this would require hammering on some fairly specialized storage with many CPUs concurrently. fio is the thing to test storage performance with.

Unless you're using something like NVME solid state or better, the software side of i/o performance literally does not matter. You could optimize it to the point that it was literally infinitely fast and took zero time, and it would make almost no difference because the disk is so comparatively slow. Who cares if you save a (metaphorical) second when the disk takes a (metaphorical) year to respond? Solid state storage does change this logic though, and that is a big, big change to an axiom that has previously held since the dawn of computers.

[Lyberta]

But on a more serious note, what i/o device are you talking about?

Have you bothered to click the link in the first post? It says it right from the start:

Storage: Samsung 970 EVO 500GB (NVMe, PCIe 3.0 x4)

Beware of comparing a bad C++ implementation to a bad C implementation and declaring victory.

Again, if you read the software side I use Debian Testing which usually has bleeding edge version of glibc for C library, so I was comparing against that. Would you call glibc a bad implementation?

For example it's not clear that you're taking the buffer cache out of the picture (via O_DIRECT).

I don't do that because that would require reading sectors first, update them and write them back in my own code. Again, I didn't micro-optimize.

I don't know what a "very good performance" answer would be today

I'm comparing against glibc so I don't test storage, I test how code deals with IO.

[DrMcCoy]

You know what's even faster? mmap(): https://gist.github.com/DrMcCoy/10cac8f ... 5b0ad2e395

With the added benefit of not being 10x slower than fread() when compiled with -O0.

Sure, C++ is faster than C, if you're doing silly things like consecutive tiny reads that fread() was never meant to hyper-optimize.

[Lyberta]

Does it handle file resizing? Can you write past the end of file so OS resizes the file?

Also, mmap() is not available on UEFI. I can add it later as a separate paper once the fundamental stuff is agreed upon.