Announcement

Collapse
No announcement yet.

Apple's LLVM 3.1 Clanging On Intel Sandy Bridge

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

  • Apple's LLVM 3.1 Clanging On Intel Sandy Bridge

    Phoronix: Apple's LLVM 3.1 Clanging On Intel Sandy Bridge

    After delivering benchmarks in March showing the performance gains of GCC 4.7 on Intel's Sandy Bridge processors, here's a look at how the latest LLVM/Clang 3.1 compiler from Apple is shaping up for these latest Intel CPUs.

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

  • #2
    Oh, Apple's llvm. I wonder why some people from Debian do even bother to play with this? It's so slow. Btw. congratulations to freebsd devs for having enough courage to switch. You're no longer dependent on GPL licensed compiler and you must be really happy now.

    Comment


    • #3
      LLVM's great for JIT work. Other than that, it's simply a toy.

      Comment


      • #4
        Originally posted by blinxwang View Post
        LLVM's great for JIT work. Other than that, it's simply a toy.
        That's what I keep hearing, and it's getting old. We know that it's a toy, that's why Michael and others like to play with it. Being a toy now does not preclude it from being a serious tool in the future.

        Comment


        • #5
          It's a serious tool now.

          Most of those benchmarks are only a little slower on LLVM. The OpenMP ones make GCC look way more impressive than it is, especially given that only a very few fringe packages even use OpenMP. When Clang supports that, those spectacular-looking gaps will close up. Future revisions of LLVM's optimizers will also close up the other smaller gaps.

          The advantage of LLVM/Clang -- and the reason why Apple, Google, Facebook, and various other big companies all pay engineers to work on it -- goes far, far beyond a few percentage points of optimization.

          Even as a game developer, I couldn't care less about GCC's tiny lead. Hell, most of us put up with Visual C++, which is hardly competitive with GCC anymore in terms of raw optimization. At the end of the day, the tools we use to develop the software vastly outweigh the compiler itself. The tools that Clang facilitates lets development go that much faster, with vastly superior static analysis, IDE support, reflection support, code refactoring, scripting binding, etc., not to mention the LLDB tool. The tools that Microsoft built for Visual C++, especially its debugging tools and IDE, are still best in class on Windows, especially when paired with Visual Assist X -- but a Clang-based IDE can still do far better. The tools that exist for GCC are Vim and ctags, and a debugger that is awkward to use because it's near impossible to integrate nicely with a graphical editor. The sooner GCC stops being the official compiler for half the console systems, the happier I'll be.

          Comment


          • #6
            Which brings me to another point: toys can do cool stuff too, which may be more important in some situations than raw performance.

            For instance, llvm's debugging tools, or a small helecopter with a camera, or an RC plain with radar, or a robot with an arm used to disarm or detonate bombs, etc..

            Comment


            • #7
              Originally posted by elanthis View Post
              It's a serious tool now.
              Where exactly? With being so slow? Stop kidding.

              Most of those benchmarks are only a little slower on LLVM. The OpenMP ones make GCC look way more impressive than it is, especially given that only a very few fringe packages even use OpenMP. When Clang supports that, those spectacular-looking gaps will close up. Future revisions of LLVM's optimizers will also close up the other smaller gaps.
              When llvm will catch up in this case GCC will be far ahead of it.

              The advantage of LLVM/Clang -- and the reason why Apple, Google, Facebook, and various other big companies all pay engineers to work on it -- goes far, far beyond a few percentage points of optimization.
              Close minded trolling as usual. How is this advantage while there are many more people and companies paying its engineers to work on GCC? Red Hat, AMD, Intel, Google, IBM. The reason why apple support its crappy llvm is just because they cannot ship the latest and greatest GCC. We're not talking about few percentage points of optimization if you didn't notice, but even about hundred points.

              Even as a game developer, I couldn't care less about GCC's tiny lead.
              Troll alert. GCC is not only far more popular, but much faster - even few times. How to speak with trolls?

              The sooner GCC stops being the official compiler for half the console systems, the happier I'll be.
              The sooner llvm and Apple will die the world will be better.

              Comment


              • #8
                Originally posted by elanthis View Post
                It's a serious tool now.
                Agreed.

                Originally posted by elanthis View Post
                Future revisions of LLVM's optimizers will also close up the other smaller gaps.
                LLVM/Clang will improve but so will GCC (as can be shown here in the difference between GCC 4.6 and 4.7), there's no certainty that LLVM will ever 'catch up'. On the other hand it could end up passing GCC in optimization, we simply don't know. What we do know is that GCC currently generates faster code than Clang/LLVM, and it has been the case for as long as I've been benchmarking them and I've seen no indication of Clang/LLVM closing the gap.

                Originally posted by elanthis View Post
                The advantage of LLVM/Clang -- and the reason why Apple, Google, Facebook, and various other big companies all pay engineers to work on it -- goes far, far beyond a few percentage points of optimization.
                The company name dropping doesn't really work in LLVM/Clang's favour as there's certainly more corporate paid developers for GCC with Red Hat, IBM, Google, CodeSourcery, Suse amongst others. LLVM/Clang is primarily a one man (corporation) show. Also when it comes to GCC, the code enhancements makes it back to the project due to the licence which is not necessarily the case with LLVM. Given how 'intellectual property!' is the new corporate battlecry I see an increasing chance of companies not contributing back 'unless they have to'. Also I have little to no trust in Apple when it comes to not keeping certain LLVM/Clang enhancements proprietary as we go along. Also, given that Apple stands for the vast majority of Clang/LLVM development it very much mirrors Apple's particular needs (ObjC, C, C++) which may turn out to be quite limiting.

                Originally posted by elanthis View Post
                Even as a game developer, I couldn't care less about GCC's tiny lead.
                Well the 'tiny' lead isn't that 'tiny' actually, particularly when using advanced optimizations like PGO where I can get around 20% increased performance compared to Clang/LLVM.

                As for tools and integration, LLVM offers much better possibilities here obviously given how modular it is (although GCC is improving in this area aswell), still the only solution I know of which integrates Clang/LLVM is XCode which is proprietary as per Apple's lock-in strategy and thus only available on OSX.

                I think LLVM/Clang is a great asset to the foss ecosystem and in particular it offers great competition to GCC. Still, even though you wish it wasn't so, GCC remains the de facto open source compiler toolchain and I don't see that changing anytime soon. It supports more architectures, more languages, has a higher level of compability and it generates faster code. Personally I will never return to the proprietary toolchains and therefore GCC remains my primary compiler since I know it and all it's enhancements will remain free open source. LLVM/Clang is really promising and it's JIT framework is a great gift to the open source ecosystem but I can't shake the fear that LLVM could turn into a base for a proprietary plugin/frontend/backend jungle with little code being contributed back to the main project. I hope I'm wrong though.

                Either way I look forward to using both these compilers interchangeably in the future as I am now while taking advantage of the enhancements made to each.

                Comment


                • #9
                  I guess I fall somewhere between kraftman and XorEaxEax:
                  Some of the debugging/... stuff is far better with Clang/LLVM; that alone makes it useful.
                  Also, GCC gets some of its speed by doing optimzations that never should happen (for example, one time there was a "security bug" in the kernel: GCC optimized out a null pointer check)
                  On the other hand, it's Objective C (IIRC), it's Apple, it's slower, it can't build a working kernel...
                  Leave it for debugging stuff; I don't want that on my system (though you'd better set CFLAGS right for GCC).
                  And I don't want a toolchain depending on anything Apple.

                  Comment


                  • #10
                    Originally posted by Ibidem View Post
                    I guess I fall somewhere between kraftman and XorEaxEax:
                    Some of the debugging/... stuff is far better with Clang/LLVM; that alone makes it useful.
                    Also, GCC gets some of its speed by doing optimzations that never should happen (for example, one time there was a "security bug" in the kernel: GCC optimized out a null pointer check)
                    On the other hand, it's Objective C (IIRC), it's Apple, it's slower, it can't build a working kernel...
                    Leave it for debugging stuff; I don't want that on my system (though you'd better set CFLAGS right for GCC).
                    And I don't want a toolchain depending on anything Apple.
                    I have similar opinion like you. I can understand Clang/llvm is useful in some cases, but overall GCC is far ahead of it. When comes to Linux kernel you will be much safer with GCC than Clang/llvm, because GCC is much more widely tested.

                    Comment


                    • #11
                      Originally posted by Ibidem View Post
                      Also, GCC gets some of its speed by doing optimizations that never should happen (for example, one time there was a "security bug" in the kernel: GCC optimized out a null pointer check)
                      Well, I am totally pro-GCC. At the same time, I don't mean LLVM is bad. The fact that LLVM is hanged on Apple is bad though.

                      Why I think GCC is better even though its optimization is buggy?
                      1) That GCC does wrong optimization does not mean other compilers don't.
                      How about a compiler that does not do optimization? That would be like that 0-CPU-kernel April fools joke. Sure we can make a computer secure by removing optimization. we can also remove c language as well, to prevent optimization error as well as programmer's run-time error. What I want to say is removing the optimization is not a solution, but a regression. Furthermore, history tells us such compilers should still have bugs.
                      2) GCC is extensively used on all systems. It is no surprising that we find a bug in it, just like any other programs. However, even when it is been so extensively used, yet we rarely find bugs in it. This is a solid proof that it is, surprisingly, bug-proof.
                      3) A lot more bugs are produced not by optimization, but by programmers themselves. So who should be blamed more?

                      Comment


                      • #12
                        It's a programmer that made the optimization in the first place, so obviously a programmer get's the blame. However, it's not always the fault of someone writing for (e.g.) the Linux kernel that should be blamed for an optimization that was written into the compiler. How many optimizations have been put into gcc since the first stable release? Do you expect everyone who compiles code with gcc to know about all those optimizations?

                        On the other hand, you can't expect everyone who writes compiler optimizations to know every consequence of the optimization on every piece of code that's ever compiled and touches that code-path. There could be any number of variations of code that use the optimization without a single bug appearing, but just one that uses it (correctly) and produces a bug for no apparent reason.

                        That is why a zero-optimized build (which you can do with gcc too, btw) is useful: it allows you to catch bugs in code that are caused solely by optimizations, and whose root may be in the compiler itself. clang/llvm can be useful in a similar way: If it's written well, it can be used to find bugs (in the compiler or the program itself) which prevent a program from compiling correctly in gcc.

                        Comment


                        • #13
                          While I can see many of the comments here are strongly biased, there should be no real doubts about the benefits of clang. Because it is a more modern, modular compiler, it offers amazing advantages during development. The IDE easily, continuously, checks all the syntax for you, and have great suggestions on how to fix it. Every single thing the compiler understands, the IDE understands too. This is truly great for the developer and developers of IDE's and various programming tools. Your programming just goes incredibly much faster because of this. So it's far more than a toy. Too bad then, that there are so many more developers behind gcc than clang. If all those gazillions of working hours total spent on developing for gcc were spent on clang instead, that would be truly awesome. Perhaps it is suffering from the fact that Apple associated their name too closely with the project... but then again, if they didn't, clang would probably just be some little-known curiousity for die-hard nerds. I see that the main performance difference is because of lacking support for OpenMP in clang. Considering that clang is a relatively new project making incredibly rapid progress, I wouldn't be too surprised if they catch up soon. Time will tell, but clearly the gcc team is much bigger than the clang team.
                          Last edited by Balthazar; 05-05-2012, 09:11 AM. Reason: clarification + typo

                          Comment


                          • #14
                            LLVM isn't trying to replace GCC

                            You guys have a really narrow viewpoint about LLVM. It's a compiler *framework* that just happens to also compile C/C++ code pretty well. But its existence isn't justified by only that capability. It's relatively easy to make a front-end for its intermediate representation, which is what I did for a compilers course. But you can go as deep as you need. It's going to have a far-reaching effect that's much more powerful than compiling old C code 10% faster. There are many examples of what it enables, here's one: http://vmkit.llvm.org/

                            Comment


                            • #15
                              Well, just to be clear, Clang is the frontend (C-language frontend) and came much later than LLVM (for a long time LLVM used GCC as frontend and still can by using the dragonegg plugin), also Clang comes directly from Apple, while LLVM originated in academia.

                              As for the modularity and it's possible 'symbiosis' with the IDE, it certainly offers these features but sofar I've only seen them employed in the proprietary XCode which severely limits it's overall potential (and having suffered through a weekend with XCode when helping a friend port some software to his Mac, I'm NOT impressed with it, it was slow and crashed and sometimes just hung and you couldn't even kill it!?, granted this is was not likely due to any integration with clang but after hearing how great XCode supposedly is I just had to get this rant out, sorry). Anyway, as it stands I don't know of any other IDE which integrates to Clang, nor do I know of any which is in development so the integration buzzword means very little outside the Apple realm as of now. Hopefully we will see some such solution emerge (or maybe I've just missed it?) as integration between ide and frontend certainly has benefits.

                              Originally posted by Balthazar View Post
                              While I can see many of the comments here are strongly biased
                              So are yours, so why even point to bias at all?

                              Originally posted by Balthazar View Post
                              I see that the main performance difference is because of lacking support for OpenMP in clang.
                              Yes in these benchmarks it is, however I see an overall difference of 5-15% even in software which doesn't rely on openmp.

                              Originally posted by Balthazar View Post
                              Considering that clang is a relatively new project making incredibly rapid progress, I wouldn't be too surprised if they catch up soon.
                              Well, relative to GCC it certainly is, still it's been around since atleast 2005 (Apple didn't open source it until 2007 though) so it's not exactly 'new'. As for the catching up thing, I've been hearing that even since clang was first released, and I've seen no indication of the performance gap closing. But like I said earlier in this thread, that doesn't mean it won't, it may trounce GCC in optimization in the coming years, or GCC might increase the gap even further. Personally I'm interested in what performance I get out of the compiled code _now_, I can always switch compiler later (and for the record, I use both of them at work and home and although GCC has gotten much better in it's error reporting I certainly still hold Clang/LLVM higher in that regard).

                              Originally posted by garytr24 View Post
                              But its existence isn't justified by only that capability. It's relatively easy to make a front-end for its intermediate representation,
                              Agreed, I'd actually say that as far as the open source ecosystem in general, it's existance is already justified by how often it is used to build JIT compilers for a great variety of targets. However it's usefulness as a JIT framework doesn't mean it's the best choice as a static compiler, and sofar it lags behind GCC in many areas such as supported architectures, languages and as already mentioned performance of generated code.

                              There seems to be a tendency amongst the clang/llvm advocates of wanting GCC to more or less disappear (not pointing at you) which to me is just insane, just as the notion that clang/llvm should disappear which seems mainly to be the result of deep distrust towards Apple (that distrust is warranted imo but that doesn't take away from llvm's usefulness). We are enjoying the best possible situation now where we have two really strong open source free compiler toolchains/frameworks which are engaging in friendly competition, why would we ever want that to change? Ok so it could be better if there was even more competition, maybe path64 (ekopath)?.

                              Comment

                              Working...
                              X