Announcement

Collapse
No announcement yet.

Moving Towards Building The Linux Kernel With Clang

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

  • #16
    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?

    Originally posted by pingufunkybeat View Post
    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.
    Partially incorrect.

    Completely correct, that *any* GPL is banned on Apple market.

    But remember, you don't need to opensource *ANYTHING* you build with GCC. This is sad, but it is fair and true.

    The real reason is quite simple - GCC is built and licensed from ground up in a way to prevent closing itself, or parts of it, or its extensions down.

    Apple can easily use some closed source LLVM extension to build its own parts, and you will be required to purchase it and be dependent on it.

    Comment


    • #17
      Originally posted by elanthis View Post
      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.
      This technical aspect is true, yet completely and utterly irrelevant. It is VERY easy to make something "superior" after someone alrealy makes the failures, in fact this is the right way for things to evolve. GCC "monolithic" structure, although it does support extensions, is due to prevent writing closed source extensions that will make developers dependent upon it and eliminate any "openness". If someone needs an improvement, he can easily apply it upstream. Upstream will reject anything closed, so efforts to submit closed source will fail and project will successfully remain OPEN. This is not the case with LLVM.

      This can be easily proven by two facts:
      1) first, newer project (LLVM) NOT using *any* GPL and instead picking up BSD license.

      BSD license is proven to be prioritized over GPL for single reason: BSD promotes closed source software.

      2) second, the name choosen is NOT "GCC" or anything related to "GCC". Compare to "Mplayer" and its fork "mplayer2".

      --
      Still, I am not aware of any LLVM proprietary extension, placed in strategically vital position. So, there is no need for GPL-based LLVM fork.


      Originally posted by elanthis View Post
      then evil vile horrible proprietary companies
      This assumption is correct. They ARE evil and vile.
      Last edited by crazycheese; 11-05-2012, 05:26 AM.

      Comment


      • #18
        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.
        Mr Gates, nothing is wrong with "free" software. It kicks your ass so high, you confuse closed source problems, which you listed above, with ones of the free software.

        Forking is quite normal, due to inability for *any* system define *perfect* build-up from ground up without starting.
        Those who question will look like idiots for a minute till answer. Those who not, will stay idiots forever.
        Modularity leads to deficiency in performance, one thing is faster than two+, even perfectly optimized multicores never achieve 100% performance of single core.
        Still, with size comes complexity and with complexity call for modularity.

        Regarding "GPL zealots", they fight for the freedom, so they are many times better than "Proprietary Sluts" such as yourself.

        Comment


        • #19
          Originally posted by crazycheese View Post
          1) first, newer project (LLVM) NOT using *any* GPL and instead picking up BSD license.

          BSD license is proven to be prioritized over GPL for single reason: BSD promotes closed source software.

          2) second, the name choosen is NOT "GCC" or anything related to "GCC". Compare to "Mplayer" and its fork "mplayer2".

          --
          Still, I am not aware of any LLVM proprietary extension, placed in strategically vital position. So, there is no need for GPL-based LLVM fork.
          1) BSD allows closed source software. Promoting would suggests that it is easier to write closed extensions on BSD code than open source extensions, which certainly isn't the case.

          2) the important word is "fork". mplayer2 is a fork of mplayer. LLVM does not reuse GCC code, nor any other GCC asset, so why on earth would it reuse the name? The name chosen is not icc either...

          --
          Ok so let's say there is a proprietary extension in LLVM, two cases:
          - open source developers can write the same thing. They write it, and continue to use LLVM. It costs them the same amount of work than if the project was GPLed.
          - open source devs cannot write the same thing. They don't, and they still couldn't have written it if the project was GPLed. Still the same situation as if the project was GPLed.
          The key aspect is that closed source components written to block other actors are never open sourced. Corporations in that position prefer to rewrite/buy elsewhere the whole thing anyway than make such sacrifices.

          Comment


          • #20
            Originally posted by erendorn View Post
            - open source developers can write the same thing. They write it, and continue to use LLVM. It costs them the same amount of work than if the project was GPLed.
            For a GPL licenced product it would either be released as open source of not made in the first place. So the same or better then non-GPLed.

            Originally posted by erendorn View Post
            - open source devs cannot write the same thing. They don't, and they still couldn't have written it if the project was GPLed. Still the same situation as if the project was GPLed.
            The project would have gone down a different path that didn't require this (probably because of copyright), or dropped long ago saving lots of waisted time. So better then the non-GPLed.

            Comment


            • #21
              So basicly its 99% the lisence that drives this project am I right?

              I mean yes its nice to have some cool features and stuff, but if you really dont care about speed why the hell would you wann use C? Then you would use python/javascript or something like that. But for some parts speed matters, and then in most cases 10% more speed or less matters also. So if thats right and the benchmarks are true that in 99% of the cases this new compiler results in noticable slower blobs, I dont see much usecases.

              Or is it guarantied that you can take code that runs with this compiler and compile it for production systems than without any code changes with gcc? Than you could maybe use that for having better developer-experience and in the end compile it with gcc so the end users get the speed on this parts that are written in C to have speed. (The only reason a sane person would write code in C).

              Comment


              • #22
                Maybe they are aiming for GCC like speed with a cleaner code base, and that is what drives them...

                Comment


                • #23
                  Originally posted by AJenbo View Post
                  For a GPL licenced product it would either be released as open source of not made in the first place. So the same or better then non-GPLed.


                  The project would have gone down a different path that didn't require this (probably because of copyright), or dropped long ago saving lots of waisted time. So better then the non-GPLed.
                  Sure, "not made" is always a good state for a component. A bit short on the usefulness, but full of potential

                  Comment


                  • #24
                    Originally posted by crazycheese View Post
                    Partially incorrect.

                    Completely correct, that *any* GPL is banned on Apple market.

                    ...

                    The real reason is quite simple - GCC is built and licensed from ground up in a way to prevent closing itself, or parts of it, or its extensions down.

                    Apple can easily use some closed source LLVM extension to build its own parts, and you will be required to purchase it and be dependent on it.
                    This is why I don't like LLVM/Clang (and one of the main reasons I don't like Apple).

                    I'm not going to say all proprietary software is bad, but it does not belong in this environment, nor does the enablement of it (things like LLVM/Clang).
                    Last edited by fuzz; 11-05-2012, 01:44 PM.

                    Comment


                    • #25
                      I still laugh when people thinking that only having one compiler able to compile the linux kernel is a good idea...

                      Comment


                      • #26
                        Originally posted by crazycheese View Post
                        Partially incorrect.

                        Completely correct, that *any* GPL is banned on Apple market.

                        But remember, you don't need to opensource *ANYTHING* you build with GCC. This is sad, but it is fair and true.

                        The real reason is quite simple - GCC is built and licensed from ground up in a way to prevent closing itself, or parts of it, or its extensions down.

                        Apple can easily use some closed source LLVM extension to build its own parts, and you will be required to purchase it and be dependent on it.
                        How will you be required to pay for it??
                        LLVM is BSD licensed, and as long as the Copyright holder(which isn't Apple) doesn't change the license, it will ever be. And thus, LLVM will ever be an opensource project.
                        Anything Apple can do is take the code from LLVM, modify it, and distribute it how they want. However, that again doesn't change the license of LLVM.

                        Comment


                        • #27
                          Originally posted by erendorn View Post
                          1) BSD allows closed source software. Promoting would suggests that it is easier to write closed extensions on BSD code than open source extensions, which certainly isn't the case.
                          I repeat yet again - BSD PROMOTES CLOSED SOURCE SOFTWARE.

                          GPL allows closed source software.

                          Nothing in BSD will prevent closing down. Everything in GPL is designed to keep seperate from closed source.

                          BSD is not free software, it is "public software", public domain plus small copyright notice.

                          This is the single difference that results in 3 clause vs 5 page license difference.

                          Pay attention to MacOSX, its in essence a stolen BSD.

                          And BSD crowd is trolling Linux, how them should be desktop OS too and how Linux prevents it. This is ridiculous they don't storm Apple for some things to put back! They are what their license is.

                          Comment


                          • #28
                            Originally posted by BitRot View Post
                            How will you be required to pay for it??
                            LLVM is BSD licensed, and as long as the Copyright holder(which isn't Apple) doesn't change the license, it will ever be. And thus, LLVM will ever be an opensource project.
                            Anything Apple can do is take the code from LLVM, modify it, and distribute it how they want. However, that again doesn't change the license of LLVM.
                            How are apple users required to pay for DRMed MacOSX, when its simply BSD-licensed BSD?

                            Easy. Proprietary modules above and between, which are strategically important.

                            This is not critical, unless you actually NEED Apple to work. At this point, the "free version" is useless. Just as Darwin.

                            Originally posted by fuzz View Post
                            I'm not going to say all proprietary software is bad, but it does not belong in this environment, nor does the enablement of it (things like LLVM/Clang).
                            Acknowledging all its cons, proprietary software is fine, unless it is aggressive or trying to become a vital part. Which many actually *try*, because if one is vital and costs money, the whole crowd will stream through it and the coins will sing in the water trader pocket. As well as control, since its about IT and not generic product trading.
                            Last edited by crazycheese; 11-05-2012, 06:35 PM.

                            Comment


                            • #29
                              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.
                              hmm, sounds like windows you are talking about... but it can*t be as you are talking about somthing like oss.... strange.

                              oh you mean internet explorer... oh wait, also not open source... dammit! gimme some minutes, i'll be back.

                              Comment


                              • #30
                                Originally posted by erendorn View Post
                                Ok so let's say there is a proprietary extension in LLVM, two cases:
                                - open source developers can write the same thing. They write it, and continue to use LLVM. It costs them the same amount of work than if the project was GPLed.
                                - open source devs cannot write the same thing. They don't, and they still couldn't have written it if the project was GPLed. Still the same situation as if the project was GPLed.
                                The key aspect is that closed source components written to block other actors are never open sourced. Corporations in that position prefer to rewrite/buy elsewhere the whole thing anyway than make such sacrifices.
                                Please read Adobe Flash license. Short version: if you ever used any Flash component (including Player), you agreed to License conditions. One of the conditions is - you may neither reverse engineer, nor create any clean reimplementation of it. Once you used it even once, you can't rewrite it.

                                And then, there is this patent thingy. Real cheap if you are a corporation.
                                This cancels out your first variant.

                                However, if the license didn't have this clause, should they need it, they would rewrite it, since they are not bound by agreements.

                                And then the precedent is still not happened, the bomb is ticking, until then its just enough to know that its lying there waiting for the day.

                                And yes, from the technical side, its always good to rewrite the stuff once more to get rid of deep architectural mistakes, and having one more compiler with unique build-up is a good thing.

                                Comment

                                Working...
                                X