Announcement

Collapse
No announcement yet.

Moving Towards Building The Linux Kernel With Clang

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

  • Moving Towards Building The Linux Kernel With Clang

    Phoronix: Moving Towards Building The Linux Kernel With Clang

    While it hasn't been a news item for a couple months, a group of developers are still hard at work to advance the LLVM/Clang compiler and the Linux kernel to a point where this alternative compiler to GCC can be used for building the Linux kernel...

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

  • #2
    Any bench marks for this kernel?

    Comment


    • #3
      Originally posted by AJenbo View Post
      Any bench marks for this kernel?
      GCC is faster or much faster in most cases.
      http://www.phoronix.com/scan.php?pag...m32_svn1&num=1

      Comment


      • #4
        Originally posted by JS987 View Post
        GCC is faster or much faster in most cases.
        http://www.phoronix.com/scan.php?pag...m32_svn1&num=1
        Yeah, but it would still be interesting to see how it affects things in general to have the kernel compiled this way (so i would sugest having the actual test be compiled with the same compiler for both test runs).

        Comment


        • #5
          Originally posted by JS987 View Post
          GCC is faster or much faster in most cases.
          http://www.phoronix.com/scan.php?pag...m32_svn1&num=1
          None of the "much faster" cases will affect the kernel in any way (they're all parts of highly specialized benchmarks that opt in to non-standard C/C++ extensions, e.g. OpenMP, rather than coding those features natively; Clang is gaining OpenMP), and many of the rest will also have small to little impact on the kernel (SIMD/auto-vectorization support, etc.).

          Benchmarks of user-space programs that are themselves highly specialized really can't do more than vaguely hint at what the kernel compiled performance will be.

          Comment


          • #6
            Originally posted by elanthis View Post
            Clang is gaining OpenMP
            Good for them, OpenMP is brilliant and far superior to having to do your own thread management every time you have a "for" loop.

            OpenMP is a wonderful and necessary technology in the age where 8-core processors are increasingly common, and even mobile phones are becoming multi-core.

            Comment


            • #7
              What's wrong with GCC?

              Can someone point out once again, what exactly is wrong with GCC?

              I'm not one to say that side projects are useless as I think that 95% of side projects have some merit, but this?

              What's the upside?

              Comment


              • #8
                Originally posted by halfmanhalfamazing View Post
                Can someone point out once again, what exactly is wrong with GCC?
                Its license changed from GPL v2 to GPL v3.

                Apple refuses to use GPL v3 software, probably because of the patent provisions that would interfere with Apple's ability to sue every living organism in the universe.

                After the license changed, Apple poured huge amounts of money into Clang. The rise of Clang is essentially Apple showing the FSF the middle finger. They built their entire product line on GCC, but didn't like the license change and now they are replacing it with their own compiler. The bonus is that they can close it whenever they want.

                It's good to have more options, as long as they're standards-compliant. Clang will take over some of GCC's share on closed, proprietary systems (like MacOSX) and BSDs (because they prefer BSD-licensed software), but it will probably never endanger GCC on Linux.
                Last edited by pingufunkybeat; 11-04-2012, 04:37 PM.

                Comment


                • #9
                  Originally posted by pingufunkybeat View Post
                  Its license changed from GPL v2 to GPL v3.
                  The license thing is why Apple is pushing LLVM, certainly. But politics aside, LLVM has the benefit of being a younger project with a much cleaner architecture - the result being that it's much easier to extend, and to embed into other systems. In contrast, GCC is big and monolithic - it's almost impossible to re-use any piece of it. The GCC devs are trying to change that, but they've got decades worth of accumulated code that makes the job harder.

                  The effect of this is that LLVM-based tools are a lot more attractive to other projects. If you write an IDE, the only way to hook into GCC is to fork out and run the compiler binary, and parse the console output to read the error messages. Whereas Clang/LLVM can be used as a library - run it in-process, and deal with input and output through a decent API.

                  Comment


                  • #10
                    Originally posted by halfmanhalfamazing View Post
                    Can someone point out once again, what exactly is wrong with GCC?
                    It embodies everything that is wrong with "free" software. From the idiotic bureaucracy of the steering committee to the horrible code documentation to the inability to address bugs in a timely manner to the rejection of bugfixes because of who wrote them.

                    It's a bloated steaming pile of stuff even without the idiocy of gpl zealots that left people with a choice, fork gcc (again) or start a new compiler from scratch.

                    Comment


                    • #11
                      Originally posted by yogi_berra View Post
                      It embodies everything that is wrong with "free" software. From the idiotic bureaucracy of the steering committee to the horrible code documentation to the inability to address bugs in a timely manner to the rejection of bugfixes because of who wrote them.

                      It's a bloated steaming pile of stuff even without the idiocy of gpl zealots that left people with a choice, fork gcc (again) or start a new compiler from scratch.
                      This folks is the reason not to sniff glue and/or huff paint, its makes you believe and say things that are not true.

                      Comment


                      • #12
                        Originally posted by yogi_berra View Post
                        It embodies everything that is wrong with "free" software. From the idiotic bureaucracy of the steering committee to the horrible code documentation to the inability to address bugs in a timely manner to the rejection of bugfixes because of who wrote them.

                        It's a bloated steaming pile of stuff even without the idiocy of gpl zealots that left people with a choice, fork gcc (again) or start a new compiler from scratch.
                        lol, this 'setaming pile' has been powering all open source systems and a huge amount of proprietary solutions across a huge amount of architectures (more than any other) for a _very_ long time and it's success is evident in how these systems, Linux in particular has made a huge impact on the computing landscape, in everything from servers, hpc, embedded and mobile.

                        If it's everything thats 'wrong with free software' then there's obviously nothing wrong with free software, you need to power-up your anti-gpl-fsf trolling.

                        Comment


                        • #13
                          Originally posted by AJenbo View Post
                          Yeah, but it would still be interesting to see how it affects things in general to have the kernel compiled this way (so i would sugest having the actual test be compiled with the same compiler for both test runs).
                          I'd say the kernel is one of the system components where there is the least opportunity for a compiler toolchain switch to provide a notable performance increase given how optimized it already is by using compiler extensions and hand-written assembly in areas where performance really counts. Also atleast on the x86-64 architecture Clang/LLVM generally generates slower code than GCC so it's extremely unlikely there's any performance to be gained there.

                          On the other hand as mentioned in the 'article' Qualcomm which seems to be the company interested in getting clang/llvm building Linux is ARM based and perhaps Clang/LLVM has an upper hand on ARM optimization against GCC, I have never benchmarked on that architecture so I don't know. Still I doubt think there's much of a performance boost to be had on the kernel from a compiler standpoint, that said it's always a guess until you see actual numbers.

                          Comment


                          • #14
                            Originally posted by XorEaxEax View Post
                            that said it's always a guess until you see actual numbers.
                            My point excatly

                            Also i might highlight unexpected things about the kernel.

                            Comment


                            • #15
                              Originally posted by halfmanhalfamazing View Post
                              Can someone point out once again, what exactly is wrong with GCC?

                              I'm not one to say that side projects are useless as I think that 95% of side projects have some merit, but this?

                              What's the upside?
                              Long Version

                              Clang is a superior compiler frontend. Whether or not LLVM is a superior backend (by "speed benchmark" standards it is not, yet; there are other reasons one might prefer it, however), Clang is faster to compile, tends to provide better diagnostics (GCC did some catching up after being slapped in the face with how awful its diagnostics were, but Clang isn't sitting still), Clang MUCH easier to extend and improve, has fantastic analysis tools, and has been explicitly built to be reused as a higher-level tool aside from simply compiling code into assembler.

                              GCC has tons of cruft and is difficult to work with; this has led to a general problem gaining new contributors, a slow exodus of existing developers (especially to Clang, which is more or less feature comparable but friendlier to work on), and requires lots of expert knowledge to even make a simple bug fix (as opposed to Clang, where even a total newbie can jump in and start doing pretty interesting things pretty quickly).

                              Part of this is a very explicit difference in design. GCC is an integrated whole that is not intended to be separable at all. Very very explicitly, in fact, and not for _any_ technical reason: it was because RMS was afraid that if the GCC frontend and GCC backend were usable independently, then evil vile horrible proprietary companies might use one or the other with a proprietary tool. Clang, on the other hand, was designed with full knowledge of the fact that the absolute least important thing that a compiler frontend can be used for in this day and age is the actual compilation. All the real action -- all the work that saves developers times and makes them enjoy their job -- takes place in higher level development tools, which require deep language integration. Given the huge complexity of C++, very few such tools have been developed, and most of them are quite flawed. (Visual Assist X generally is considered the best of such tools, and as a frequent user, I can attest to how often it screws up and pissed me off; compare to modern Java or C# environments where the tools are more or less perfect.) Clang allows more such tools to be written (particularly, FOSS tools, which do not currently compete favorably with their proprietary rivals) and allows them to have an excellent understanding of the language -- the exact same understanding of the language as the compiler itself, in fact.

                              Being able to compile the code is thus secondary to Clang's real strength. It's still important, however, since there are some features Clang enables that GCC frowns upon (easy injection of user-specified code in the appropriate places for application-specific instrumentation, for example), and additionally because you can't be sure your frontend actually works 100% correctly if you aren't using it to generate working code (since the only way to know that your model of the code is correct is to run the code's test cases, which require it to be compiled).

                              Also, LLVM is possibly going to be faster than GCC in the future. Given the rate of change between the two projects, it's quite likely that'll happen, assuming LLVM development doesn't start to drastically slow down or GCC drastically speed up. While it's true there aren't a lot of low-hanging fruit left for LLVM in terms of performance, there's still a lot of opportunities for it to match and then pull ahead of GCC, and it's simply easier to write those optimization for LLVM's framework than it is to write them for GCC's. That is, again, very valuable if you're a compiler developer.

                              There's also features that LLVM itself provides that GCC does not. LLVM has a JIT mode, which has been used for some very interesting things (like a massively updated and more complete CINT). LLVM has a very interesting IR model, which has allowed for projects like Portable NaCl which would otherwise be incredibly difficult to pull off. I'm unsure what if any benefits there are for kernel developers, but there are certainly a good number of them for userspace developers.

                              Shot Version

                              The key goal of Clang is to support tools like fully accurate code completion, large-scale invasive automatic refactoring support, highly detailed static analysis, semantic and structural analysis for automatic documentation/binding generation, user customizable instrumentation and code morphing, and so on. Being able to use even just one of those tools when developing the kernel makes it entirely worth ensuring that Clang/LLVM are capable of fully and correctly parsing (and then compiling) the kernel source code.

                              Comment

                              Working...
                              X