LLVM Clang Compiler Optimization Benchmarks From -O0 To -O3 -march=native

[phoronix]

Phoronix: LLVM Clang Compiler Optimization Benchmarks From -O0 To -O3 -march=native

As some recent GCC 5.2 compile tuning tests with various CFLAGS/CXXFLAGS were of interest to a number of Phoronix readers, hare are some benchmarks with a number of different compiler flag tests when using the LLVM Clang 3.8 compiler...

http://www.phoronix.com/scan.php?page=news_item&px=LLVM-3.8-Tuning-Tests-Xeon

[ryao]

This is an improvement on the usual benchmarks, but you should have included `-march=native` with each of the other optimization levels. In particular, `-O3 -march=native` is not necessarily better than `-O2 -march=native`.

[duby229]

Yeah, I definitely agree. I've never committed to LLVM as a C compiler yet simply because with portage GCC "just works". But at the least with GCC -03 causes some problems and can in some situations induce compile failures that are caused by indescribable behavior. I always build everything with -02 -march=native. It is true there may be packages that do perform better with -03, but those should only be considered on a case by case basis, and for most people it just isn't worth the time. If You have some load that you are expecting it to take weeks or months to complete, then perhaps -03 would be worth considering for that specific package.

[FireBurn]

This is an improvement on the usual benchmarks, but you should have included `-march=native` with each of the other optimization levels. In particular, `-O3 -march=native` is not necessarily better than `-O2 -march=native`.

Agreed

[lethal]

I don't understand.
You mentioned gcc 5.2 results, but how do you compare the clang results with the gcc ones ?
gcc tests were done on a i7-4558U, and clang's on a xeon...

Otherwise what's the usefulness of this ? To know that -O2 is more optimized than -O0 ?
Or to know that -O0 is faster to compile ?

[Michael]

I don't understand.
You mentioned gcc 5.2 results, but how do you compare the clang results with the gcc ones ?
gcc tests were done on a i7-4558U, and clang's on a xeon...

Otherwise what's the usefulness of this ? To know that -O2 is more optimized than -O0 ?
Or to know that -O0 is faster to compile ?

This isn't meant to compare to the GCC ones, just for showing difference between levels.

[caligula]

I don't understand.
You mentioned gcc 5.2 results, but how do you compare the clang results with the gcc ones ?
gcc tests were done on a i7-4558U, and clang's on a xeon...

Otherwise what's the usefulness of this ? To know that -O2 is more optimized than -O0 ?
Or to know that -O0 is faster to compile ?

Comparison with GCC will be another article. It's impossible to include both in the same article.

[Krejzi]

Oh wow. I recently switched my source based distribution compiler so I build as much as possible with clang/clang++ + libc++. It would've been nice if you threw in the -Ofast flag which you've been known to be using. My flags are -march=sandybridge -pipe -fomit-frame-pointer -Ofast -fstack-protector-strong. My CPU is an i5 Sandybridge Laptop CPU, so -march=sandybridge should be equivalent to -march=native. I am not sure if -fstack-protector-strong adds some overhead, but I can say I didn't notice any improvements over -O2 -march=sandybridge when I switched to -Ofast -march=sandybridge, at least not visible to naked eye.

[duby229]

Oh wow. I recently switched my source based distribution compiler so I build as much as possible with clang/clang++ + libc++. It would've been nice if you threw in the -Ofast flag which you've been known to be using. My flags are -march=sandybridge -pipe -fomit-frame-pointer -Ofast -fstack-protector-strong. My CPU is an i5 Sandybridge Laptop CPU, so -march=sandybridge should be equivalent to -march=native. I am not sure if -fstack-protector-strong adds some overhead, but I can say I didn't notice any improvements over -O2 -march=sandybridge when I switched to -Ofast -march=sandybridge, at least not visible to naked eye.

The problem with -fomit-frame-pointer is that it makes it harder when you need to file bug reports. You'll see a lot of people complain at you for that. I suggest that i you ever need to file a bug report you should recompile everything down the dependency chain without it first. In which case you'll likely save a bunch time if you just don't use it in the first place.

[Krejzi]

The problem with -fomit-frame-pointer is that it makes it harder when you need to file bug reports. You'll see a lot of people complain at you for that. I suggest that i you ever need to file a bug report you should recompile everything down the dependency chain without it first. In which case you'll likely save a bunch time if you just don't use it in the first place.

I know what the flag does. The "package manager"'s debug mode removes -fomit-frame-pointer and adds -g, resulting in enough debug info when I need it. Easy enough to trigger a rebuild in such occasions.