Hacker News Reader

Hacker News

Comment by diimdeep | Hacker News Reader

Full thread

diimdeep

Is it slower again ? [1]

[1] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html

View on HN

https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.htm...

From the article:

I think this is the first time in quite a few releases where we end up with an overall regression. However, the situation is not quite as bad as it looks.

In particular, the large regression on the right is due to enabling C++17 by default. The close to two times slowdown in 7zip O0 builds comes down to STL headers becoming 2-3 times as large in C++17.

While this is sad, and I had to edit out some choice words on the C++ standardization committee (I hear that this gets even worse in C++20), at least this does not affect non-clang compilers (e.g. Rust) and C code.

Meanwhile VC++ does just fine, thanks to how it handles incremental compilation, incremental linking and now modules.

I've been working both with Clang and MSVC nearly daily for the last 10 years. My impression during that whole time is that MSVC (on Windows) is universally slower than Clang (on Linux or macOS, Clang on Windows is also not exactly a performance wonder though).

Clang might have become slower over time, but it still has a long way to go until it gets down to MSVC's average performance.

Only if you aren't using pre-compiled headers, or hot code reloading, alongside incremental compilation and linking.

Shouldn't people expect compile times to be slower at -O3? Presumably the improvements are better optimizations, many of which trade compile time for execution time. Now if it's getting slower at -O0, that might be a concern.

There are dynamic interpreted languages that use LLVM as a way to compile fast paths (the details are more complicated). For such languages how fast the heavily-optimized code is compiled matters. Julia is a great example.

In this particular case though, no it does not seem it matters, as the slowdown is related to C++ headers in the newer standard lib, not to the low-level compilation.

Is Julia using -O3? I would find that surprising as it is not recommended. -O3 could be a good starting point, but with maturity a frontend should be evaluating individual passes.

"One of the most common mistakes made by new language frontend projects is to use the existing -O2 or -O3 pass pipelines as is. These pass pipelines make a good starting point for an optimizing compiler for any language, but they have been carefully tuned for C and C++, not your target language. You will almost certainly need to use a custom pass order to achieve optimal performance."

https://www.llvm.org/docs/Frontend/PerformanceTips.html

You are right, Julia is indeed customizing how exactly the compilation happens (with a ton of higher-level compiler customization happening in Julia).

You can see the impact on Rust here: https://perf.rust-lang.org/compare.html?start=2d0a7def330ed9...

The tl;dr is that check builds are faster (i.e. optimization quality has improved) while debug/opt builds are mixed, but slightly slower when averaged over everything.

Yeah, LLVM is a dog, about twice as slow and GCC and 20 times slower than TCC:

   gcc-11.2  -O0     0.02
   clang-12.0.1 -O0  0.04
   tcc               0.002

I wish TCC was still being maintained and supported by modern toolchains.

[1]: https://forum.nim-lang.org/t/8677

What makes you thing TCC isn't maintained anymore?

Doing a search for "TCC compiler" (to avoid very unrelated stuff) gives a homepage of:

https://www.bellard.org/tcc/

... which says at the top:

    Note: I am no longer working on TCC. Check the mailing list to get up to date information.

So, sounds pretty dead. But actually following the suggestion and taking a look at the mailing list helps:

https://lists.nongnu.org/archive/html/tinycc-devel/2023-03/t...

And the source code repo seems pretty active:

https://repo.or.cz/w/tinycc.git

It can't be used to build against recent versions of musl or static glibc because they require thread-local variables, meaning it pretty much can only be used with dynamic glibc.

You’re benchmarking clang 12, not clang 16.

Reply on news.ycombinator.com