“Hello world” is slower in C++ than in C (Linux)

https://lemire.me/blog/2022/08/09/hello-world-is-slower-in-c-than-in-c-linux/

by ibobev • 4 years ago

26 65 4 years ago

Well, the C++ iostream library is slower. A truer comparison could be to compile the same code in both.

butz2• 4 years ago

Very interesting to compare assembly code of both variants. C ends up with 10 lines of assembly code (https://godbolt.org/z/EeTTefjfq), and C++ variant - 42 lines (https://godbolt.org/z/5T5qWc56h).

khitchdee3• 4 years ago

C++ is slow and bloated but people just hide that under the rug.

qsdf381002• 4 years ago

C++ is a language, while iostream is one of the many C++ tools available to write to the standard output. It’s available by default, it’s part of the standard library, but you don’t have to use it. printf is also available, and will be as fast as using it from C.

Note that in most cases, the speed of writing to standard output is irrelevant unless you are implementing cat or some command line text processing tool.

I find iostream very convenient and type safety is a big plus compared to printf. It’s also very easy to implement your own handlers for your own types.

dvfjsdhgfv• 4 years ago

I don't believe anyone tries to hide it. Except a couple of well-known cases, C++ is (relatively slightly) slower than C, but it's far more powerful. You can argue about compile times - yes, there is a huge difference here; also some specific features like virtual methods are slow - but overall, C++ is one of the fastest languages available.

pjmlp9• 4 years ago

I get exactly the same 10 lines using C++.

https://godbolt.org/z/fTPM35Erq

As the "C code" is also valid C++.

butz2• 4 years ago

Of course, same code compiles into same asm, but in original article author is comparing different source code for C++, which includes iostream and stdlib.h.

psyclobe• 4 years ago

tl;dr iostreams is bloated and slow

charcircuit2• 4 years ago

Isn't the C version missing a fflush to be equivalent?

jonathrg3• 4 years ago

Strictly speaking yes (or the "C++ version" could replace std::endl with \n), but the observable behavior isn't going to change much. The runtime is going to flush the output buffer at program exit anyway.

charcircuit2• 4 years ago

But couldn't it effect the observable behaviour of the time it takes to execute?

Dwedit• 4 years ago

More like Iostream is slower than writing to stdout's file handle.

jonathrg3• 4 years ago

What we are testing by running these programs is the overhead due to the choice of programming language.

That's just wrong. The first example is a perfectly fine hello world in C++. This is overhead due to the choice of API used to print to stdout

It's well known that a typical iostream implementation is slower than a typical printf implementation, which is why printf is still used in C++ and one of the reasons we got std::format in C++20

guyomes• 4 years ago

Moreover, if strings are the only thing to print, and speed is the only thing to care about, then "puts" is a good alternative too.

BaculumMeumEst• 4 years ago

A post this ignorant and reductive is something I would expect from a freshman student of computer science, not a professor. Embarrassing.

newbieuser• 4 years ago

HN is a great site for people who want attention. It's funny that this article is on the front page but ¯\_(ツ)_/¯

kragen5• 4 years ago

People get to be professors because they spend their time investigating things they don't understand (that is, that they're ignorant about), not because they spend all their time doing things they already understand well. You just aren't used to seeing that process in action (it usually isn't blogged), so you project your own embarrassment onto Lemire, who doesn't deserve it.

fluoridation2• 4 years ago

Well, I would expect a professor to not waste their time experimenting to learn something that's already been documented. So yes, there are things a professor should be embarrassed for not knowing.

TillE• 4 years ago

"Investigating" is an extremely generous term for this blog post which attempts no such thing.

A serious person would have at least drilled down into the assembly, this is just an incredibly childish experiment with no follow-up.

matrix_overload3• 4 years ago

"Investigating" means taking apart and systematically analyzing, exponentially cutting down the problem space. Making hypotheses, validating them, discarding the unconfirmed ones, and navigating further down the causal tree until you find the root cause. What this blog post is all about is called "bitching", pardon my French.

And it kinda makes sense given the tremendous pay gap between the academia and industry in Computer Science. So if instead of joining a startup or a corporate research team, you decide to sit in a University job, you are either lazy, or don't like accountability, or both. Sorry.

vkazanov3• 4 years ago

Huh? It measures 2 idiomatic ways to print a string. Printf is faster, it's expected. This is just a note checking common sense. Totally worth doing it, especially for a scientist!

PS The author is... not just any professor.

pjmlp9• 4 years ago

Last time I checked my C++ compiler also had support for printf.

kjeetgill• 4 years ago

I agree completely. Lemire's blog is usually a gold mine when it comes to detailed low level algorithms and encoding problems but this is the second time I've seen a post just come off so amateurish.

And I've been a huge fan of his.

He just comes off as really removed from whole program and language wide thinking — and maybe he's just a bit too distanced from it given his specialty.

billpg• 4 years ago

That surprises me. If you had asked me, I'd have said that with normal optimizations switched on, both programs would boil down to exactly the same single function call that copies a byte-array to the stdout stream. I would have to wonder if there any optimisations someone has missed if there's even a tiny difference.

In the C world, I could image there's a loop at runtime scanning the printf string for % characters, but I would equally imagine that the compiler people have made a special case for printf that silently replaces printf calls with a single string literal parameter with no %s are replaced with a puts call. (Which itself gets optimised to to a byte-array copy.)

danjoredd• 4 years ago

I thought that this was well known?

magila• 4 years ago

Iostream's performance problems have been well known for decades. This post is striking shallow and uninformed for something coming from a professor "focused on software performance".

not2b2• 4 years ago

Nope. The equivalent in C++ is not

std::cout << "hello world" << std::endl;

but is, rather,

std::cout << "hello world\n";

The std::endl doesn't just print an '\n' character, it also does a buffer flush.

CoastalCoder3• 4 years ago

I'm not sure how we define "equivalent" here.

If we're talking about the majority of C++ code I see in commercial systems, then `std::endl` is definitely used more than `'\n'` to emit a line-break.

(std::endl also has the benefit of doing the right thing across different operating systems)

plorkyeran2• 4 years ago

std::cout << "\n"; will emit \r\n on Windows by default.

not2b2• 4 years ago

In the code I write and review I care about the buffer-flush semantics and will revise, or ask for a revision, if excessive flushing will result from too many std::endl uses when generating large volumes of output. It isn't just an academic point; you might want to look at that code to see if std::endl is justified. It is appropriate if you want to guarantee that a given record reaches the output file quickly, and if not much is written it's a don't-care.

pjmlp9• 4 years ago

Being pedantic, the equivalent C++ is still his printf example, as it is valid C++ code.

One isn't forced to use iostreams, format, or now the new kid in town, print.

cesarb• 4 years ago

Besides the std::endl gotcha others already mentioned: IIRC, just including the <iostream> header is enough to make it run some extra initialization code before main().

matrix_overload3• 4 years ago

This is such an ignorant and low-effort post.

The author did not bother to check whether the delay comes from the library loading time vs. the actual string formatting.

He is complaining about a single millisecond difference (that is near the measurement error) and haven't bothered to run the entire thing in a loop and get the difference to something meaningful (where the terminal performance can eat away any noticeable differences).

He picked a completely unrealistic metric (console output is usually meant to be read by humans, so it was never optimized for +- millisecond performance).

He doesn't distinguish between the language (C++) and the I/O API (printf() vs iostream).

The main advantage of C++ is that if you bother to understand how it works, you can let the compiler/debugger do a lot of mind-numbing and error-prone work that C developers proudly do by hand (collections, RAII, inline templates with concepts) at exactly 0.0 runtime overhead. The key is "if you bother to understand how it works". If you randomly pick an arbitrary API and complain how it's worse than a different arbitrary API from C for an arbitrary use case, it only shows your own incompetence.

jenscow2• 4 years ago

The post is "Hello world" is slower in C++, not "C++ is slower" or anything else.

The speed of the Hello world application is the metric and they used hyperfine - a benchmarking tool.

__ryan__• 4 years ago

From the article:

I do not believe that printing ‘hello world’ itself should be slower or faster in C++, at least not significantly. What we are testing by running these programs is the overhead due to the choice of programming language.

MaulingMonkey2• 4 years ago

The post is "Hello world" is slower in C++, not "C++ is slower" or anything else.

The post pretty clearly blames "C++" if you read more than the title - note the "due to C++" here:

> Yet if these numbers are to be believed, there is a significant penalty due to C++ for tiny program executions, under Linux.
The speed of the Hello world application is the metric

And it's a poor metric, mostly testing process setup/teardown.

and they used hyperfine - a benchmarking tool.

And benchmarking tools are only as good as their usage and application.

A more apples-to-apples comparison would be to use `\n` instead of `std::endl`, and `std::ios_sync_with_stdio(false)` to avoid excessive syncronization with C I/O. Admittedly, neither particularly helps here: I observe most of the overhead the article does merely by switching out clang/gcc for clang++/g++ on the same C source code, with ~6ms-9ms total runtime under wsl, or ~9ms (no measurable difference between the C++ or C code) when compiled with cl 19.15.26732.1 and run on windows. This is mostly measuring process setup/teardown and OS I/O overhead: redirecting stdout to null, I don't see a significant perf impact until I put the printing in some rather large loops:

    #include <stdio.h>
    #include <stdlib.h>

    int main() {
        for (int i=0; i<1000000; ++i) printf("hello world\n");
        return EXIT_SUCCESS;
    }

    #include <iostream>
    #include <stdlib.h>

    int main() {
        std::ios::sync_with_stdio(false);
        for (int i=0; i<1000000; ++i) std::cout << "hello world\n";
        return EXIT_SUCCESS;
    }

Guess which is faster? The C++ version, oddly enough, both on wsl ubuntu linux:

    /mnt/c/local/ben$ clang++ -Os hello_world.cpp && cargo run --bin bench --quiet --release
    average runtime: 36.78434ms
    /mnt/c/local/ben$ clang -Os hello_world.c && cargo run --bin bench --quiet --release
    average runtime: 86.33667ms
    /mnt/c/local/ben$ clang++ -O3 hello_world.cpp && cargo run --bin bench --quiet --release
    average runtime: 36.34467ms
    /mnt/c/local/ben$ clang -O3 hello_world.c && cargo run --bin bench --quiet --release
    average runtime: 86.75787ms

And on windows:

    C:\local\ben>cl /nologo /O2 hello_world.cpp && cargo run --bin bench --quiet --release
    hello_world.cpp
    C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include\xlocale(319): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
    average runtime: 1.44849203s

    C:\local\ben>cl /nologo /O2 hello_world.c && cargo run --bin bench --quiet --release
    hello_world.c
    average runtime: 1.75088561s

Take these numbers with a massive grain of salt: Launching the first subprocess is extra expensive (on the order of 90-100ms) and included in the above averages, distoring them, presumably from delayed loading or initialization of a library in the benchmarking process as subsequent runs of the benchmarking process show the same overhead for the first subprocess[1]. Meanwhile, the author of the original article is calling overhead that has to be rounded up to 1ms a "huge penalty".

(EDIT[1]: to rule out first-access overhead being from windows defender or similar, I confirmed that launching a sacrificial, unrelated, first subprocess such as "cmd /C ver" eliminates the overhead for the first "./a.out" execution)

blastonico• 4 years ago

The author knows C++ (https://github.com/simdjson/simdjson) and writes a lot about his performance experiments. I don't see why he - or anybody else - shouldn't raise such questions and arguments without having people (like you) getting angry about it. Is it offensive?

Anyway, he has a point, `cout` is used extensively as a logging mechanism. If you don't see that "single millisecond" making any difference, you certainly haven't work on a relevant system.

pjmlp9• 4 years ago

Then he should know his "C example" is valid C++ code.

galkk• 4 years ago

Such lazy post.

Even doing this:

* gcc max performance compilation option (-O3) https://godbolt.org/z/18ejPnzrj

* gcc min compilied size compilation options: https://godbolt.org/z/EK1Tzznes

without any written work will give much more insights into differences between C++ and C implementations

pjmlp9• 4 years ago

What a ridiculous statement, first of all the first example is also C++ code, and compiles to exactly the same set of machine instructions,

https://godbolt.org/z/8jYh79e7e

Second, everyone ones knows that iostream flexibility and type safety comes with a price.

Third, the modern way is to use fmt, or std::format.

andy-x• 4 years ago

So, if C printf is slower than assembler code that outputs "hello world", then C is garbage?

“Hello world” is slower in C++ than in C (Linux)

Related Stories