Clang 3.4 Performance Very Strong Against GCC 4.9
Phoronix: Clang 3.4 Performance Very Strong Against GCC 4.9
After earlier this month delivering LLVM Clang 3.3/3.4 benchmarks for the new compiler infrastructure out of Apple, today are results that directly compare the new LLVM Clang 3.4 performance against the stable GCC 4.8.2 compiler and GCC 4.9.0 development compiler under various C/C++ benchmarks.
Can You, please, do same tests with AMD FX-8350 Piledriver CPU? This is very interesting, how clang compiled binaries performs on AMD CPUs compared to GCC compiled ones.
Seems like our company's projects now can switch to use Clang by default.
Thanks and Happy New Year!
It's on my TODO list eventually. Unfortunately only have one latest-generation AMD system due to AMD's lack of cooperation recently with Phoronix and it's often tasked with other workloads for testing so it's harder to do more AMD tests.
Originally Posted by leonmaxx
Anyone with experience of compiling Mesa with it?
I don't understand. Are those runtime values for apps or only some theoretic compile times, that nodobdy cares anyway?
Originally Posted by mike4
If you read with attention the graphs, you can notice the unit measured :
bench BLAKE2 -> Cycles per byte
bench BOTAN -> Mega bytes per second
bench FLAC Audio encoding -> Second (time to encode a file, the less is better)
bench Timed PHP Compilation -> Seconds (time to compile php, this is a compile time)
The results aren't theoretic at all, lot of them are the results of real software doing real things (encoding a wav file, rendering a 3D scene, time to compress with bzip2 etc..).
Not with the latest git, but I am running Mesa 10.0.1 with a git from about two weeks ago and it works fine.
Originally Posted by przemoli
Strange, can't reproduce anything close to that with the LU numbers, admittedly on i7-2600, but that is for -O3 -march=native pretty much the same thing, AVX but not AVX2 support.
gcc 4.9 20131230 numbers look like:
Composite Score: 1569.78
FFT Mflops: 254.65 (N=1048576)
SOR Mflops: 1131.31 (1000 x 1000)
MonteCarlo: Mflops: 563.64
Sparse matmult Mflops: 1780.87 (N=100000, nz=1000000)
LU Mflops: 4118.40 (M=1000, N=1000)
and clang 3.4 SVN (as of today):
Composite Score: 1566.95
FFT Mflops: 255.41 (N=1048576)
SOR Mflops: 1617.87 (1000 x 1000)
MonteCarlo: Mflops: 528.94
Sparse matmult Mflops: 1804.41 (N=100000, nz=1000000)
LU Mflops: 3628.12 (M=1000, N=1000)
While LU got tiny bit better from clang 3.3 to 3.4, it is just 1-2% improvement (from multiple runs).
compile time is very important too.
Originally Posted by mike4
When I used clang for a project at work a while back (a few million lines, with precompiled headers) I was rather disappointed with the (rather hyped) compilation speed. It's not faster than the other compilers we use. The thing (I think) is I'm compiling with debug symbols (symbols, but optimized or a mixed optimization level in different parts, but always with symbols). It might just be something with that specific project, but when compile time is benchmarked it looks like it is usually without debug symbols. A program is build countless of times by its developers, and we want symbols (for use in debuggers ourself or with crash dumps from testers or users). In my opinion compile times with symbols is more (or at least as) important than without as most users use precompiled programs in most cases anyway, with the exception of gentoo users and when people are applying custom patches.
That is not to say that it is a bad compiler, it's about on par with the others in the case above, I was just a bit surprised. And I would like benchmarking of compile times to test with symbols as well (as benchmark sometimes directs effort).
On the other hand, faster compilers would probably be detrimental to my fencing.