Announcement

Collapse
No announcement yet.

Clang 3.4 Performance Very Strong Against GCC 4.9

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Hello, Michael!

    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!

    Comment


    • #3
      Originally posted by leonmaxx View Post
      Hello, Michael!

      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.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        Anyone with experience of compiling Mesa with it?

        Comment


        • #5
          I don't understand. Are those runtime values for apps or only some theoretic compile times, that nodobdy cares anyway?

          Comment


          • #6
            Originally posted by mike4 View Post
            I don't understand. Are those runtime values for apps or only some theoretic compile times, that nodobdy cares anyway?

            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..).

            Comment


            • #7
              Originally posted by przemoli View Post
              Anyone with experience of compiling Mesa with it?
              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.

              Comment


              • #8
                Can't reproduce

                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).

                Comment


                • #9
                  Originally posted by mike4 View Post
                  I don't understand. Are those runtime values for apps or only some theoretic compile times, that nodobdy cares anyway?
                  compile time is very important too.

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X