Announcement

Collapse
No announcement yet.

Intel Ivy Bridge: GCC 4.8 vs. LLVM/Clang 3.2 SVN

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

  • Intel Ivy Bridge: GCC 4.8 vs. LLVM/Clang 3.2 SVN

    Phoronix: Intel Ivy Bridge: GCC 4.8 vs. LLVM/Clang 3.2 SVN

    Kicking off the Linux benchmarks this weekend are some early numbers from the GCC 4.8 and LLVM/Clang 3.2 development compilers when running on Intel's latest-generation Core i7 "Ivy Bridge" processor. GCC 4.8 and LLVM/Clang 3.2 are still months away from being formally released, but this article provides a glimpse at how the open-source compiler battle is panning out.

    http://www.phoronix.com/vr.php?view=17767

  • #2
    Good to see GCC still has a lot of fight left in it. So much so that it almost makes Apple look pretty silly for starting LLVM/Clang. LLVM/Clang still doesn't compile a LOT of apps and on top of that still doesn't beat GCC in performance most of the time on the apps that it does compile.

    So the only thing LLVM/Clang has going for it right now is the more user-friendly compiler errors and warnings? Hard to imagine LLVM/Clang ever being a true replacement for GCC, at least not for several more years.

    Comment


    • #3
      Originally posted by Sidicas View Post
      Good to see GCC still has a lot of fight left in it. So much so that it almost makes Apple look pretty silly for starting LLVM/Clang. LLVM/Clang still doesn't compile a LOT of apps and on top of that still doesn't beat GCC in performance most of the time on the apps that it does compile.

      So the only thing LLVM/Clang has going for it right now is the more user-friendly compiler errors and warnings? Hard to imagine LLVM/Clang ever being a true replacement for GCC, at least not for several more years.
      OMG, GCC fanboy much? In case you didn't know: Competition is a good thing. Btw GCC and LLVM are tools. Use them for your advantage.

      Comment


      • #4
        Originally posted by log0 View Post
        OMG, GCC fanboy much? In case you didn't know: Competition is a good thing. Btw GCC and LLVM are tools. Use them for your advantage.
        OMG,you are Clang fancrap, idiot crap people fuck with stupid shitty clang! clang is worse than dog shit!

        Comment


        • #5
          Clang is welcome to compete, but I don't know if it'll ever catch up. Apple is so focused on form over function that they'd rather have beautiful, prosaic compiler warnings/errors, like "Hello, John. That is a very clever piece of code you have written, but unfortunately it violates the C99 standard, because it ...".

          Right now, Clang may have faster compile times, but that's because it doesn't optimize things nearly as well as gcc. It gets absolutely slaughtered on binary size and the thing that matters the most; performance. Who cares if it takes a long time to compile? Build servers are usually high-end multi-core multi-cpu servers anyway.

          Comment


          • #6
            Originally posted by allquixotic View Post
            Right now, Clang may have faster compile times, but that's because it doesn't optimize things nearly as well as gcc. It gets absolutely slaughtered on binary size and the thing that matters the most; performance. Who cares if it takes a long time to compile? Build servers are usually high-end multi-core multi-cpu servers anyway.
            Thanks for that information. It would have been nice to include a benchmark of compilation time into the article itself to give a broader perspective...

            Comment


            • #7
              Sigh.

              1) A year ago Clang/LLVM was nowhere close to competing with GCC. Now it not only is caught up on some benchmarks, but actually ahead on others. And yet some doofuses want to make claims like "it will never catch up." Currently behind, yes, but it's improving at a much faster rate than GCC does.

              2) GCC's internals suck. Even many of the people who work on GCC agree that it sucks. Companies like Facebook and Google are moving to Clang because GCC costs them far more money to develop with, even if they do perhaps use GCC for release mode compiles.

              3) Clang has tool support. GCC does not, and probably never will, _by design_. This is what the doofuses never seem to understand. Nobody really gives a crap if LLVM compiles code that runs faster. Really, it doesn't matter. What does matter is that you can write high-quality analysis tools, refactoring tools, IDEs, etc. with Clang. You cannot write them with GCC, because GCC goes out of its way to stop people from doing it. You can completely remove the actual ability to output machine code from Clang and it would still be one of the most important projects around for C++ developers.

              4) The only areas that you see very large differences in performance between Clang and GCC are in OpenMP bound tests. That will be fixed, and when the feature lands, most of the gaps will shrink. There will no longer be massive crazy differences in performances on any benchmark for people to point out and sensationalize. Apps that don't use OpenMP (e.g., most of them) likewise don't see huge gaps in performance between GCC and Clang. Again, GCC may lead on most (but apparently not all) tests, but only by small margins that really just don't matter.

              5) Clang offers significantly better error diagnostics. Yes, this matters. Calling it "form over function" is absolutely ridiculous -- the diagnostics _are the freaking function_ in a developer tool, for ****'s sake. I compile a release mode version of an application a few times per release. I develop, test, and debug code thousands of times per release. If I were forced to choose only one compiler, I'm going to choose the one that saves me massive amounts of time during development rather than the one that has a 5% speed boost, and I'll take all the money saved in my time and just buy a faster CPU. (Of course, in time, it won't be a trade-off anymore, as per point 1.) To say that "performance matters most" is just flat out preposterous and wrong: even as a AAA game developer, it really just isn't that big of a difference to care. (Granted, we can do dev in the intelligent compiler and then compile in release mode in the optimizing compiler. Having both is good!) We care about shaving off engineer time, cutting hundreds of thousands of dollars from costs. We do not care about the minimum specs being "6 year old computer" instead of "6.3 year old computer."

              6) Clang and LLVM both are essential to the current Linux graphics stack. Anyone posting on a site like Phoronix and insulting Clang or LLVM is a very sad, confused individual. Unless you don't want optimized shaders, efficient software rendering, and OpenCL support, I guess.

              Clang/LLVM is developed at a ridiculously rapid pace by developers from a wide range of companies (not just Apple), and a very significant portion of the professionals who actually use compilers in advanced scenarios (rather than cluelessly debating them on forums and occasionally compiling something) are migrating from GCC to Clang. Probably a reason for that. Probably at least 6 of them. Of course GCC is not irrelevant today, and is not going to be irrelevant any time soon, but to doubt that Clang is becoming more and more relevant is just silly. It will be some time before it supplants GCC on Linux, if it ever does, but frankly who cares? "Is default compiler on Linux distros" is about as important as "is default desktop background."

              Comment


              • #8
                Some AMD love

                i would like to see similar benchmarks, but with AMD hardware.
                Just to see if how much the compilers can optimise with an AMD Bulldozer/PhenomII hardware.

                Comment


                • #9
                  Originally posted by China_Guy View Post
                  OMG,you are Clang fancrap, idiot crap people fuck with stupid shitty clang! clang is worse than dog shit!
                  Wow, you seem to have some serious emotional issues. Have you considered psychological treatment?

                  Comment


                  • #10
                    Can you somehow test server/desktop software

                    Can you somehow test apache/dns performance?
                    Also interested in browser rendering speed/js speed test
                    Test running some interpreted languages (can python be compiled with LLVM?)

                    Comment


                    • #11
                      Clangs better error diagnostics...

                      5) Clang offers significantly better error diagnostics. Yes, this matters. Calling it "form over function" is absolutely ridiculous -- the diagnostics _are the freaking function_ in a developer tool, for ****'s sake. I compile a release mode version of an application a few times per release. I develop, test, and debug code thousands of times per release. If I were forced to choose only one compiler, I'm going to choose the one that saves me massive amounts of time during development rather than the one that has a 5% speed boost, and I'll take all the money saved in my time and just buy a faster CPU. (Of course, in time, it won't be a trade-off anymore, as per point 1.) To say that "performance matters most" is just flat out preposterous and wrong: even as a AAA game developer, it really just isn't that big of a difference to care. (Granted, we can do dev in the intelligent compiler and then compile in release mode in the optimizing compiler. Having both is good!) We care about shaving off engineer time, cutting hundreds of thousands of dollars from costs. We do not care about the minimum specs being "6 year old computer" instead of "6.3 year old computer."
                      Umm GCC people are disputing your claims
                      http://gcc.gnu.org/wiki/ClangDiagnosticsComparison

                      Comment


                      • #12
                        Originally posted by elanthis View Post
                        Sigh.

                        1) A year ago Clang/LLVM was nowhere close to competing with GCC. Now it not only is caught up on some benchmarks, but actually ahead on others. And yet some doofuses want to make claims like "it will never catch up." Currently behind, yes, but it's improving at a much faster rate than GCC does.
                        It's a lot easier to improve when you start out with nothing. There is absolutely no reason to suspect that improving from completely unoptimized, barely-working codegen (which is, necessarily, how LLVM/Clang or any compiler starts out its life), to matching 75-80% of gcc's performance, is an indicator that they'll achieve the last 20-25% delta and even pull ahead.

                        In all of the benchmarks I've seen so far, all of LLVM's so-called "wins" are statistically insignificant, i.e. within 5%. Furthermore, not all of gcc's wins are due solely to the absence of OpenMP on LLVM; some of the benchmarked programs don't use OpenMP at all, yet still exhibit a 20% delta favoring gcc. Clearly, llvm has a long way to go. The problem is that the last mile is 10 times harder than the previous hundred miles; the last 10 feet are 10 times harder than the last mile; the last inch is 10 times harder than the last foot; and so on (the analogy works better with the metric system but I'm too lazy to edit what I typed).

                        Unless llvm literally copy and pastes much of the micro optimization stuff from gcc, there is no reason to think that they will implement those expensive optimizations in any sort of reasonable timeframe. Look how long it took gcc to develop them. Moreover, there wasn't really any other good open source competition to gcc at the time that the gcc devs were developing those optimizations, so they pretty much had to do them from scratch. Now, you might say that llvm developers could just study the overall algorithmic approach that gcc takes to optimizing so well, and base their own optimizations on that. But by your own admission, the internal architecture of gcc and llvm are wildly different. So llvm will not be able to easily copy and paste from gcc, even if they were permitted to do so by the license, because of the difference in architecture. In short, llvm will have to do things "mostly" from scratch, whereas gcc had to invent optimizations "entirely" from scratch.

                        Originally posted by elanthis View Post
                        2) GCC's internals suck. Even many of the people who work on GCC agree that it sucks. Companies like Facebook and Google are moving to Clang because GCC costs them far more money to develop with, even if they do perhaps use GCC for release mode compiles.
                        I can perhaps understand Google working with GCC's internals. But why in God's name would an application development company like Facebook have to even look at the GCC source code? I mean, come on -- as the author of C, C++, Vala, C# and Java codebases spanning upwards of 50k SLOC, I've never once encountered some programming problem or compiler error within my program and thought "gee, I'd better try and hack on the compiler". You have to be writing some pretty edge-case, non-portable code to even reach that point. Stick with well-supported constructs and paradigms (design patterns) and you can type out hundreds of lines of code at a time with an extremely small warning/error rate, without even using an IDE. It's not rocket science.

                        Anyway, the whole point of a compiler is that it is a tool; it's not the end product in itself. Having complex internals vs. well-documented and elegant internals does not add any sort of value to the end product. Having a compiler that produces fast code (or small code, depending on your needs) is a value-added attribute. Having a compiler that is simply well-designed is not, by itself, a value-added attribute. If forced to choose between a compiler that has more/better value-added attributes versus one that does not, it should be a no-brainer for anybody who has ever taken a business class, or even anyone whose goal is to deliver high quality products to whomever their customers are.

                        Originally posted by elanthis View Post
                        3) Clang has tool support. GCC does not, and probably never will, _by design_. This is what the doofuses never seem to understand. Nobody really gives a crap if LLVM compiles code that runs faster. Really, it doesn't matter. What does matter is that you can write high-quality analysis tools, refactoring tools, IDEs, etc. with Clang. You cannot write them with GCC, because GCC goes out of its way to stop people from doing it. You can completely remove the actual ability to output machine code from Clang and it would still be one of the most important projects around for C++ developers.
                        I'm a big fan of developer tools and anything that enhances productivity. But I've seen some pretty incredible stuff with Eclipse CDT's gcc integration, and even more incredible stuff with Visual Studio's integration with the Microsoft C++ compiler. But neither gcc nor the Microsoft C++ compiler have "tool support" in the same way that Clang/LLVM do. So how is it possible that both the open source community and a proprietary company have used inferior toolchains to produce superior IDEs? Maybe I'm missing something, but I can refactor C++ code pretty damn well with Eclipse CDT or Visual Studio.

                        I recall Michael posting an article/video a few months ago about some developer working on advanced tooling using LLVM, and I remember being pretty impressed. I mean, if you take this kind of thing to its logical extreme, C++ could almost start to approach the maintainability and productivity of Java, which is a huge feat for such a terrible language. So why don't we invest all those man-hours into the slow LLVM/Clang to make it as easy to develop with as Java, just so we can say C++ is the best? Meanwhile our "C++" will be almost as slow as Java because we aren't using a compiler that has fully explored runtime performance optimization.

                        Originally posted by elanthis View Post
                        4) The only areas that you see very large differences in performance between Clang and GCC are in OpenMP bound tests. That will be fixed, and when the feature lands, most of the gaps will shrink. There will no longer be massive crazy differences in performances on any benchmark for people to point out and sensationalize. Apps that don't use OpenMP (e.g., most of them) likewise don't see huge gaps in performance between GCC and Clang. Again, GCC may lead on most (but apparently not all) tests, but only by small margins that really just don't matter.
                        For certain classes of program, sure, 10% performance doesn't matter. Common desktop software is to the point that it barely scratches the surface of what a modern CPU is capable of. But anything computationally-intensive is going to care a lot about even a 1% performance delta, to say nothing of 10%. You may not be able to notice the difference between Clang and gcc for Firefox or GNOME, but everything from video processing to scientific applications is extremely performance-sensitive, and slow-performing code can impact schedules by hours, days or even weeks, or require hardware upgrades that wouldn't be necessary otherwise.

                        Originally posted by elanthis View Post
                        5) Clang offers significantly better error diagnostics. Yes, this matters. Calling it "form over function" is absolutely ridiculous -- the diagnostics _are the freaking function_ in a developer tool, for ****'s sake. I compile a release mode version of an application a few times per release. I develop, test, and debug code thousands of times per release. If I were forced to choose only one compiler, I'm going to choose the one that saves me massive amounts of time during development rather than the one that has a 5% speed boost, and I'll take all the money saved in my time and just buy a faster CPU. (Of course, in time, it won't be a trade-off anymore, as per point 1.) To say that "performance matters most" is just flat out preposterous and wrong: even as a AAA game developer, it really just isn't that big of a difference to care. (Granted, we can do dev in the intelligent compiler and then compile in release mode in the optimizing compiler. Having both is good!) We care about shaving off engineer time, cutting hundreds of thousands of dollars from costs. We do not care about the minimum specs being "6 year old computer" instead of "6.3 year old computer."
                        "Having both is good" is the first sane thing you've said. And of course good error messages matter for large scale applications where triaging a problem is prohibitively difficult. But you're overlooking one thing.

                        Now, more than ever, gcc is poised to be able to produce better diagnostics than it has in the past. With the introduction of C++ into gcc's source code, internal APIs are being rewritten in an object-oriented manner, replacing old spaghetti code with a layered architecture that at least belongs in the same discussion as LLVM's architecture, even if LLVM is "even more layered" or "even more well-designed".

                        The point is, while LLVM is trying to catch up to gcc's performance, gcc is trying to catch up to LLVM's usefulness to developers. People are working on both sides to make both compilers better in their weaknesses. Claiming that gcc's complex/unmaintainable internals make it unable to match LLVM in the long run is plain wrong, if for no other reason than the fact that gcc's internals are actively being rewritten as we speak. But (hopefully) they'll be maintaining all of the optimizations they have today, just sitting them on top of more object boxes, separating it out into more shared libraries, etc. to make the code more maintainable.

                        I disagree, however, that the point of a compiler is to provide good diagnostics. I would rather that the compiler focus on what it does best -- compiling -- and run a different, separate tool that tells me why my code is bad.

                        Actually, I'm a huge fan of clang analyzer. That is exactly the kind of application that LLVM is best at. All hail the open source equivalent to Coverity, which I hope will in time produce even better diagnostics than Coverity itself, and then some.

                        In my perfect world, clang would -- as you said somewhere above -- be unable to actually codegen a built and linked binary. Its sole focus would be on helping developers improve their code by eliminating incorrect code (compiler errors, inadvisable practices, slow code, non-standard-compliant code, and so on). Clang could very easily fit into the open source ecosystem this way.

                        If Clang DOES fully catch up with gcc on performance of compiled code, that's great -- but I think it unlikely because clang is much more valuable if efforts are concentrated on its diagnostics, which you yourself admitted are the most important aspect of a developer tool (not to be confused with a compiler). Clang seems more focused on being a developer tool from the get-go, so why not just push that angle and leave the release builds to gcc?

                        Originally posted by elanthis View Post
                        6) Clang and LLVM both are essential to the current Linux graphics stack. Anyone posting on a site like Phoronix and insulting Clang or LLVM is a very sad, confused individual. Unless you don't want optimized shaders, efficient software rendering, and OpenCL support, I guess.
                        This is an honest question, because I don't know the answer for certain; but what in the world does Clang have to do with the Linux graphics stack? AFAIK only the core LLVM libraries are used. Sure, you can compile Mesa with clang; but it'll be needlessly slower than compiling it with gcc. I swear I've built and linked many a build of r600g and nouveau with the LLVM libraries installed but without the clang binary installed on my system. Maybe you're alluding to the fact that developers are using clang analyzer to help them diagnose their code? That's fine, for a developer tool, but that still doesn't make it a good compiler for the purpose of fast codegen.

                        Originally posted by elanthis View Post
                        Clang/LLVM is developed at a ridiculously rapid pace by developers from a wide range of companies (not just Apple), and a very significant portion of the professionals who actually use compilers in advanced scenarios (rather than cluelessly debating them on forums and occasionally compiling something) are migrating from GCC to Clang. Probably a reason for that. Probably at least 6 of them. Of course GCC is not irrelevant today, and is not going to be irrelevant any time soon, but to doubt that Clang is becoming more and more relevant is just silly. It will be some time before it supplants GCC on Linux, if it ever does, but frankly who cares? "Is default compiler on Linux distros" is about as important as "is default desktop background."
                        Okay, smartass. Insulting everyone who uses gcc is just as stupid as insulting everyone who uses LLVM. As it stands right now, they serve vastly different purposes, which doesn't make them incompatible, and there's no reason not to use both of them as the situation demands. The truly intelligent engineer won't just blindly migrate to the latest fad project because it's new and cool; they will use whatever best fits the situation at hand. So let's TL;DR this whole discussion:

                        First, as a premise: the year is 2012. Let's not get ahead of ourselves here.
                        • Are you compiling a release build? Then use GCC!
                        • Are you already familiar with GCC's error messages and know what to do when you see one? Then use GCC!
                        • Are you stumped by an error, or looking to improve the quality of your code? Then use clang or clang-analyzer!
                        • Are you writing a graphics driver and don't have the manpower / time to develop your own optimizing shader compiler? Then use LLVM!

                        Now, the year is 2014. Oh, wait -- I was about to make a similar list as above but with what the situation will be in 2014, but then I realized that I misplaced my crystal ball. Maybe you have it over there and can find it for me, elanthis?

                        Comment


                        • #13
                          It would have made sense from my perspective to include results from the latest released versions of Clang and GCC, i.e. to see how their performance has evolved rather than start another pointless GCC vs. Clang bash.

                          Comment


                          • #14
                            Originally posted by allquixotic View Post
                            I mean, if you take this kind of thing to its logical extreme, C++ could almost start to approach the maintainability and productivity of Java, which is a huge feat for such a terrible language.
                            Writing ten page essays and then hiding gems like this in the middle. 8/10 trolling.

                            Comment


                            • #15
                              Originally posted by allquixotic View Post
                              This is an honest question, because I don't know the answer for certain; but what in the world does Clang have to do with the Linux graphics stack? AFAIK only the core LLVM libraries are used. Sure, you can compile Mesa with clang; but it'll be needlessly slower than compiling it with gcc. I swear I've built and linked many a build of r600g and nouveau with the LLVM libraries installed but without the clang binary installed on my system.
                              Clang can parse OpenCL source code and produce LLVM bytecode from it, you dick head.
                              You need clang in the Linux compute stack.

                              Comment

                              Working...
                              X