Announcement

Collapse
No announcement yet.

GCC 4.6/4.7 vs. LLVM-Clang 3.0/3.1 Compilers

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

  • GCC 4.6/4.7 vs. LLVM-Clang 3.0/3.1 Compilers

    Phoronix: GCC 4.6/4.7 vs. LLVM-Clang 3.0/3.1 Compilers

    With LLVM/Clang 3.1 due out next week, here's a look at the compiler performance of the GCC 4.6 and 4.7 compilers compared to LLVM-Clang 3.0 and a recent LLVM-Clang 3.1 SVN snapshot...

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

  • #2
    LLVM is now almost there.

    Comment


    • #3
      No its not

      Clang is further away then it was before the last update. GCC 4.7 has made significant gains on its self and is still a much better all round choice for the vast majority of use cases.

      Why on earth would anyone replace a perfectly good compiler that is guaranteed to remain free software, with something that can be taken proprietary at any point? Even if there are small gains to be had (which there are not) risk that your compiler can be closed off to you (BSD Licence) vs no risk of the compiler being closed off (GPL) seems like a fairly obvious choice to me.


      I am wondering why this site is so interested in clang. maybe there are some vested interests? I can't see any other reason for it...

      Comment


      • #4
        Please ignore the troll. Do NOT reply to him.

        Comment


        • #5
          that was my first post...

          how on earth did you come to that conclusion?

          I have made factual observations that have ramifications should clang become the new standard compiler.

          I like honest debate RealNC. You however seem to be in the business of making cheap-shot accusations.

          - BSD gives selfish interests the ability to screw everyone over.
          That's fine by the way. I am NOT suggesting that you should not rely on BSD licensed software if you want to. I'd just like to make sure everyone is clear on the potential problems of using such software.

          GPL does not give vested interests the ability to screw everyone over.

          Comment


          • #6
            Originally posted by fnoss View Post
            how on earth did you come to that conclusion?

            I have made factual observations that have ramifications should clang become the new standard compiler.

            I like honest debate RealNC. You however seem to be in the business of making cheap-shot accusations.

            - BSD gives selfish interests the ability to screw everyone over.
            That's fine by the way. I am NOT suggesting that you should not rely on BSD licensed software if you want to. I'd just like to make sure everyone is clear on the potential problems of using such software.

            GPL does not give vested interests the ability to screw everyone over.
            Oh no that flamewar again. Please just stop it before this grows.

            We all know the differences between GPL-like (copyleft) and BSD-like licenses.
            Last edited by bachinchi; 05-07-2012, 04:27 PM. Reason: typo

            Comment


            • #7
              Say Apple for some reason makes clang proprietary, can the open source community not fork and continue to develop the last open source version of clang before it became proprietary?

              Comment


              • #8
                Originally posted by jayrulez View Post
                Say Apple for some reason makes clang proprietary, can the open source community not fork and continue to develop the last open source version of clang before it became proprietary?
                Google, Facebook, Red Hat, VMware, Cray, etc. etc. all employ far more Clang/LLVM developers than Apple does. They will keep it open. I'm at a C++ SG meeting hosted by Microsoft, and I heard from Chandler Carruth (Google) that the LLVM community are getting LLVM/Clamg moved to be managed by its own non-profit, so community direction and ownership should cease to be anything but a straw man hypothetical soon. It'll be no different than fearing that Apache might turn proprietary tomorrow.

                So far as "why Clang," the answer continues to be "tools". GCC is all but useless for IDE code completion and custom static analysis, and is outright completely useless for automated refactoring and code transformations, as GCC intentionally lacks the necessary information in its AST.

                GCC is also difficult to hack on, which is why so many people who want to work on compilers for fun have jumped on the Clang train. GCC works very well, yes, but only because there is a small core of very dedicated folks who've spent a decade or more accumulating knowledge on the code base. GCC may even be at greater risk of disappearing when you rely on it, because the project has a large "bus factor": too much of its success is dependent on a small number of very difficult to replace people. Clang is easy to jump into and hence getting new people up to expert levels on its internals is much much easier.

                Comment


                • #9
                  Originally posted by fnoss View Post
                  GPL does not give vested interests the ability to screw everyone over.
                  Except that GPL is a vested interest in itself.

                  GCC codebase is a mess and poorly documented. LLVM is clean and well documented. That's why clang is exciting.

                  Comment


                  • #10
                    Why is there no -O flag set on the 7-zip test? It's absolotely pointless to benchmark code when you don't actually use ANY optimizations.

                    Comment


                    • #11
                      Originally posted by elanthis View Post
                      Google, Facebook, Red Hat, VMware, Cray, etc. etc. all employ far more Clang/LLVM developers than Apple does. They will keep it open. I'm at a C++ SG meeting hosted by Microsoft, and I heard from Chandler Carruth (Google) that the LLVM community are getting LLVM/Clamg moved to be managed by its own non-profit, so community direction and ownership should cease to be anything but a straw man hypothetical soon. It'll be no different than fearing that Apache might turn proprietary tomorrow.

                      So far as "why Clang," the answer continues to be "tools". GCC is all but useless for IDE code completion and custom static analysis, and is outright completely useless for automated refactoring and code transformations, as GCC intentionally lacks the necessary information in its AST.

                      GCC is also difficult to hack on, which is why so many people who want to work on compilers for fun have jumped on the Clang train. GCC works very well, yes, but only because there is a small core of very dedicated folks who've spent a decade or more accumulating knowledge on the code base. GCC may even be at greater risk of disappearing when you rely on it, because the project has a large "bus factor": too much of its success is dependent on a small number of very difficult to replace people. Clang is easy to jump into and hence getting new people up to expert levels on its internals is much much easier.
                      Thank you elanthis. I understand this. However, my question was an hypothetical "if" which I would still like a factual answer for. I'm not afraid llvm-clang will be taken one day and I highly doubt it will be. I Just want to understand what would be possible "if" it does.

                      Comment


                      • #12
                        Say Apple for some reason makes clang proprietary, can the open source community not fork and continue to develop the last open source version of clang before it became proprietary?
                        They can't "make clang proprietary". they can take the code, re-license and start a privative fork off that ... but in that case the code of clang would still be open and the community can keep the work with it.
                        GPL doesn't give any *absoluto* warranty about privative abuse (as some people want you to think), we had PLENTY of examples of that even in the kernel itself (if we put it that way). so this is nonsense, lot's of BSD-licensed projects may be forked or re-used partially, but the original project is still open ... so no, it doesn't threaten in any way the FOSS community. but as I said in the previous thread: licensing is a hard topic, the BSD is a license that is hard to pick where to use. in some cases it's a better choice than GPL, sometimes it's the other way.

                        It's not a black or white thing, it's a topic with much more colors.

                        Regards.

                        P.S → Here's an article I cited in the previous thread that I would like to link again : http://www.theregister.co.uk/2011/05...rs_and_takers/
                        Last edited by vertexSymphony; 05-08-2012, 03:37 AM.

                        Comment


                        • #13
                          Originally posted by vertexSymphony View Post
                          They can't "make clang proprietary". they can take the code, re-license and start a privative fork off that ... but in that case the code of clang would still be open and the community can keep the work with it.
                          GPL doesn't give any *absoluto* warranty about privative abuse (as some people want you to think), we had PLENTY of examples of that even in the kernel itself (if we put it that way). so this is nonsense, lot's of BSD-licensed projects may be forked or re-used partially, but the original project is still open ... so no, it doesn't threaten in any way the FOSS community. but as I said in the previous thread: licensing is a hard topic, the BSD is a license that is hard to pick where to use. in some cases it's a better choice than GPL, sometimes it's the other way.

                          It's not a black or white thing, it's a topic with much more colors.

                          Regards.

                          P.S → Here's an article I cited in the previous thread that I would like to link again : http://www.theregister.co.uk/2011/05...rs_and_takers/
                          Thanks for your reply and explanation. I was simply baffled that every time something is posted about llvm and or clang there is a subset of users here who always express negatively towards it. I believe everyone has the right to prefer a particular licence, but given your explanation, to me the zeal of some of these members is borderline irrational. If there is no way that Apple or any other company can simply deprive one of the use or sources of llvm and clang, then there is no need for rejecting the project.

                          On the other hand, improvements to clang can only serve to make gcc better. Theoretically, given the licences, gcc can use code from llvm and clang. If what they fear is that people will start a mass migration from gcc to clang and cause clang to stagnate, then clang would not be at fault, but gcc for not providing improvements to be more usable to developers.

                          I understand there are people who will choose a compiler based on the licence, but they are the minority. The majority of people will simply use the best tool for the job be it clang or gcc or any other compiler.

                          So there does not need to be a religious war among compilers because of licences.

                          Comment


                          • #14
                            I can understand why many people would be completely turned off from a topic as soon as a related but unfamiliar and polarizing side of the topic gets brought up. On one hand the LLVM project is doing some things right in the compiler area. Elanthis' post on the merits of this project is the best in this thread at explaining LLVM/Clang's strengths. In spite of the relatively unimpressive benchmarks it showed in this article relative to GCC, it did manage to stay close to GCC performance and this new tool does have some features that make it easier to use for those who are unfamiliar with GCC.

                            That being said, it is impossible to cover the topic of free and open source software without also covering the important related topic of licensing. Ignoring the licensing issue actually does a disservice to free software software in general, because without the type of FOSS licensing we now have we would not have a free software community to begin with. Not only that, but the idea of free software itself is being attacked more now than at any time in the past with all the patent-related legal issues and challenges being raised. If the people who benefit from and contribute to the free software community don't take a healthy and vocal approach to licensing (which needs to be done in order to continue the existence of our community) then who will? There will always be lawyers and others who will do so for a fee, but they will only be around so long as there is money to pay them.

                            This is one area where the differences between BSD and GPL arise. It should be no wonder that the BSD license is the preferred licence for companies who contribute to open source. The reason for this is simple: these organizations want to reserve the right to at any time take a replica of the open source project they have contributed to and then only contribute their changes and improvements to their walled-off version of the project. What is lost in this process is the fact that their new changes and benefits are made possible by (and exist only because of) the open source project they have taken from. In short, these organizations that operate in this manner take much more than they give back to the project. Many organizations see BSD-licenced projects merely as a free resource, and they see the developers who contribute to those projects as little more than free labor to benefit from. These organizations have no interest in contributing to the project to the same extent that they plan to gain from the project. BSD-style licenses allow this to occur much more so than GPL-style licenses. The GPL (and other similar licenses) ensure reciprocity to a much greater extent given our current legal reality.

                            On a side note, sometimes you hear people complaining about the complexity of the GPL in relation to other open-source licenses. But this is not a fault of the GPL itself. This perceived complexity is the result of working within our society's current legal framework to ensure a certain level of reciprocity continues to be apart of any free software contribution that is GPL licensed.

                            These licensing issues are easily overlooked by many people who enjoy free software. It is natural to instead focus on learning new skills from these projects and pointing out the achievements (in technical functionality, organization and project management) of some projects over others. After all, many people who are interested in open source come from a technical or educational background (as opposed to a legal or humanitarian background). But the legal and social ramifications of free software don't go away (and are not made any less important) by choosing not to focus on those key issues. In fact, it is many times just the opposite.

                            Comment


                            • #15
                              Originally posted by jayrulez View Post
                              Thanks for your reply and explanation. I was simply baffled that every time something is posted about llvm and or clang there is a subset of users here who always express negatively towards it. I believe everyone has the right to prefer a particular licence, but given your explanation, to me the zeal of some of these members is borderline irrational. If there is no way that Apple or any other company can simply deprive one of the use or sources of llvm and clang, then there is no need for rejecting the project.

                              On the other hand, improvements to clang can only serve to make gcc better. Theoretically, given the licences, gcc can use code from llvm and clang. If what they fear is that people will start a mass migration from gcc to clang and cause clang to stagnate, then clang would not be at fault, but gcc for not providing improvements to be more usable to developers.

                              I understand there are people who will choose a compiler based on the licence, but they are the minority. The majority of people will simply use the best tool for the job be it clang or gcc or any other compiler.

                              So there does not need to be a religious war among compilers because of licences.
                              Think that this is very symbolical, that's why some GNU soldiers are sensitive about this ... if GCC is obsolete and replaced by Clang, it would mean less % of "GNU" in "GNU/Linux" until we find that we don't actually have to call the system GNU/Linux if we can ship a system that is GNU-free (people at FreeBSD camp is working hard on this ... mostly because they don't feel good about shipping GPLv3 code - and that's why they use gcc 4.2 atm, the last gplv2 version of gcc-, that very own technical differences with clang thing damaged GCC a lot )

                              And yes, they can't deny anyone the use of open BSD licensed code, as long as no patents are involved, same situation as GPLv2 ... GPLv3 is whole another story because it cover patents but also adds some more differences that you may or may not wish.
                              people at GNU can take code (if they want) from Clang, basically because BSD and MIT are compatible with GPL ... but it doesn't work the other way.

                              They pretty much get anal with the idea of a company making a privative fork (stuff allowed by the license, consciously chosen by the developer ), make money off that and not giving back code !! (stuff that GPL requires, but can be circumvented in some ways) but this whole idea requires an analysis on it's own, because we usually comfort ourselves with short-sighted reasoning without asking more stuff like if the company would not give code anyways by ignoring the GPL-licensed code !! (happens, ask yourselves why some liberally-licensed projects exists in the first place ... in fact, that's the reason of why GPLv3 code is being keeped FAR away from FreeBSD base code).

                              I don't say they are wrong, but they don't show the entire picture, the arguments are partial and the words they choose leaves a lot to be desired (for example, they talk about "closing code" which suggests that existing free and open code, with his open source community and governance stops existing in a second, wich is ridiculous ... because that doesn't happen when you fork ). The idea is to know the consequences of a licensing (your rights and your obligations) and think about future without bad information like GNU zealots *tend* to spread and move on what best suits your needs.

                              And yes, the licenses war are nonsense, like programming language wars and such ... people forget that these are tools and that you use the right tool for the job. you don't make religions about tools and you don't use the same tool for every job !!!

                              Sorry if this post is messy, it's terribly late in here.
                              Last edited by vertexSymphony; 05-09-2012, 12:52 AM.

                              Comment

                              Working...
                              X