Announcement

Collapse
No announcement yet.

GCC vs. Clang Compilers On The Intel Core i9 With Clear Linux

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

  • GCC vs. Clang Compilers On The Intel Core i9 With Clear Linux

    Phoronix: GCC vs. Clang Compilers On The Intel Core i9 With Clear Linux

    For those curious about the GCC versus LLVM Clang compilers with Intel's new Core i9 7900X, earlier this month I had ran some compiler benchmarks on this high-end processor...

    http://www.phoronix.com/scan.php?pag...i9-Clear-Linux

  • #2
    The FFTW benchmark was the only one where -march=native had a big really impact, but only for clang. Not sure why you specifically for that benchmark said there was no impact.

    Comment


    • #3
      For compiler benchmarks, I'd expect the benchmark for time it takes to compile some binaries to be followed by a benchmark of the said binaries' performance. Otherwise results aren't that meaningful.

      Comment


      • #4
        Originally posted by bug77 View Post
        For compiler benchmarks, I'd expect the benchmark for time it takes to compile some binaries to be followed by a benchmark of the said binaries' performance. Otherwise results aren't that meaningful.
        For most users, the time to compile is largely meaningless and only care about the resulting performance. But for those concerned about the compile time performance, there are a few results in this article.
        Michael Larabel
        http://www.michaellarabel.com/

        Comment


        • #5
          Thank you, Michael, for these benchmarks but I want to mention it's not clear to me what is being measured in each of them. For example, the first SQLIte result is measuring seconds to complete a task that I would guess is compilation, except you then mention faster performance with Clang. Is that faster compiler performance or performance of the binary?

          IMO, if possible, the best option would be to have PTS automatically add a label to the result image, such as "Time to compile" or "Time to complete 10,000 inserts," depending on the benchmark being run.

          Comment


          • #6
            Originally posted by Michael View Post

            For most users, the time to compile is largely meaningless and only care about the resulting performance. But for those concerned about the compile time performance, there are a few results in this article.
            sed s/most/reasonable/

            I've my share of complaints about slow compile times. Even without those, it's still nice to know whether you're spending twice the time in order to get 2% faster binaries. And yes, I know you supposedly compile once and run a million times. Unfortunately, until you ship, you still get to compile hundreds, if not thousands of times.
            Anyway, it was just a suggestion, I'm fully aware you don't have the resources to test everything under the Sun.

            Comment


            • #7
              Originally posted by Michael View Post

              For most users, the time to compile is largely meaningless and only care about the resulting performance. But for those concerned about the compile time performance, there are a few results in this article.
              I'd trade double the compile time for a 10% performance gain any day.

              Comment


              • #8
                Originally posted by doublez13 View Post

                I'd trade double the compile time for a 10% performance gain any day.
                Exactly, hence why these results largely focus just on the resulting binary performance.
                Michael Larabel
                http://www.michaellarabel.com/

                Comment


                • #9
                  Originally posted by bug77 View Post
                  I've my share of complaints about slow compile times. Even without those, it's still nice to know whether you're spending twice the time in order to get 2% faster binaries. And yes, I know you supposedly compile once and run a million times. Unfortunately, until you ship, you still get to compile hundreds, if not thousands of times.
                  Keep in mind that real development is incremental. You only compile .c/.cpp -> .o. Linking also takes time with large projects. Compiling a single change into .o is really fast.

                  Comment


                  • #10
                    Originally posted by caligula View Post

                    Keep in mind that real development is incremental. You only compile .c/.cpp -> .o. Linking also takes time with large projects. Compiling a single change into .o is really fast.
                    That's not a given. Java compiler doesn't do that by default, but if you use maven or gradle (which everybody does), then you get incremental compiles. Then there's stuff like (now defunct?) GWT which would take its sweet time producing a separate JS file for each browser you wanted to support and for each browser one file for each language. For bonus points, the whole thing wasn't even multithreaded, but don't quote on that.
                    So I hope it's a little more clear where I'm coming from now.

                    Comment

                    Working...
                    X