Announcement

Collapse
No announcement yet.

FreeBSD 10 To Use Clang Compiler, Deprecate GCC

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

  • FreeBSD 10 To Use Clang Compiler, Deprecate GCC

    Phoronix: FreeBSD 10 To Use Clang Compiler, Deprecate GCC

    As indicated by the Q1-2012 FreeBSD Status Report, LLVM's Clang compiler is quickly replacing GCC for this popular BSD operating system. The developers are also making much progress in a GNU-free C++11 stack. For FreeBSD 10 they're aiming for Clang as the default C/C++ compiler, deprecate GCC, and to have a BSD-licensed C++ stack...

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

  • #2
    Code compiled with Clang is still slower than fuck, WHY DO WE NOT WANT GCC AGAIN? God, this is like Wayland replacing X11. Lets just replace something that works better with a newer crappier version just because it is new!

    Comment


    • #3
      Originally posted by LinuxID10T View Post
      Code compiled with Clang is still slower than fuck, WHY DO WE NOT WANT GCC AGAIN? God, this is like Wayland replacing X11. Lets just replace something that works better with a newer crappier version just because it is new!
      In FreeBSD's case, I think the reason they want Clang/LLVM is because they're license purists. Yes, they seriously would rather take a compiler producing shit for code output (very large and very slow binaries) over a GPLed compiler.

      They're also banking on the hope that LLVM will improve. But Apple's engineers are no smarter than the folks who maintain GCC: the fact is that it will take a great many years to mature LLVM to the point that GCC is matured. Compilers aren't simple and you can't write a really good one overnight. LLVM might become as good as GCC 4.x someday, but if the high rate of contribution to GCC continues, it will probably continue to retain some edge over LLVM/Clang, especially on its traditionally most popular target of x86/x86_64.

      This is a demonstration that the FSF isn't the only organization that are license purists. It's telling that the BSD camp always attacks the FSF camp for being GPL license purists, yet when it comes down to deciding which compiler to include in the leading BSD operating system, they base their decision not on technical issues but on license issues. Idealists will never change...

      Comment


      • #4
        x11 works better, you are kidding right? that's why most x.org devs support or even actively work on wayland. including x11 veteran keith packard.

        Comment


        • #5
          Originally posted by garegin View Post
          x11 works better, you are kidding right? that's why most x.org devs support or even actively work on wayland. including x11 veteran keith packard.
          Lets just forget for the second that X11 already has far, far more features than Wayland. Computers are getting faster all the time, if feature bloat is a problem, it shouldn't be now. I am sick of people that keep trying to reinvent the wheel. WHY?!? Yeah, X11 is old, but it works. The time can be better put into far more useful things. Just my opinion.

          Comment


          • #6
            Originally posted by allquixotic View Post
            In FreeBSD's case, I think the reason they want Clang/LLVM is because they're license purists. Yes, they seriously would rather take a compiler producing shit for code output (very large and very slow binaries) over a GPLed compiler.
            Licence purists, sure. But really even though Clang/LLVM produces less performant code (~5-15%) it's certainly anything but a 'shit' compiler.

            However since FreeBSD would not ship any GPLv3 licenced code (due to their corporate sponsors/customers iirc) they were stuck on GCC 4.2 which is like what, 5 years old now? So it's not surprising that the second that Clang/LLVM showed up they decided to switch, not only is it a better compiler than the ~5 year old GCC 4.2 they are stuck with, it also in line with their licence ideology. The transition has taken quite some time due to Clang/LLVM's lack of maturity but it will eventually happen in full. I see this as a good thing, I think the BSD's having to rely on GPL licenced code all these years (particularly in such an important area as the compiler toolchain) has been a sore point for the BSD advocates and has helped fuel further friction, and we could use LESS of that.

            However the 'Clang is quickly replacing GCC' line... 'quickly'? He even states later in the 'article' that the switch has been ongoing since 2009 !

            Comment


            • #7
              Originally posted by XorEaxEax View Post
              Licence purists, sure. But really even though Clang/LLVM produces less performant code (~5-15%) it's certainly anything but a 'shit' compiler.

              However since FreeBSD would not ship any GPLv3 licenced code (due to their corporate sponsors/customers iirc) they were stuck on GCC 4.2 which is like what, 5 years old now? So it's not surprising that the second that Clang/LLVM showed up they decided to switch, not only is it a better compiler than the ~5 year old GCC 4.2 they are stuck with, it also in line with their licence ideology. The transition has taken quite some time due to Clang/LLVM's lack of maturity but it will eventually happen in full. I see this as a good thing, I think the BSD's having to rely on GPL licenced code all these years (particularly in such an important area as the compiler toolchain) has been a sore point for the BSD advocates and has helped fuel further friction, and we could use LESS of that.

              However the 'Clang is quickly replacing GCC' line... 'quickly'? He even states later in the 'article' that the switch has been ongoing since 2009 !
              It is far slower than that in most cases. 5-15% my ass.

              Comment


              • #8
                Code compiled with Clang is still slower than fuck, WHY DO WE NOT WANT GCC AGAIN? God, this is like Wayland replacing X11. Lets just replace something that works better with a newer crappier version just because it is new!
                Basically because they're stuck with GCC 4.2 because of the change of licensing (they were fine with GPLv2, but GPLv3 added some new stuff that *investors* and some other people didn't like) ... so the toolchain was rotting more and more as time passed, thankfully clang appeared (devs were looking at other options) to the rescue and not only that, it also caugh a lot of interesting stuff at the code !! that with libcxxrt and libc++ made an interesting case for the c++11 stack

                Run a bench of GCC 4.2 against LLVM/Clang 3.1 ... that if we ignore features. IMHO you're really honoring your nickname

                In FreeBSD's case, I think the reason they want Clang/LLVM is because they're license purists. Yes, they seriously would rather take a compiler producing shit for code output (very large and very slow binaries) over a GPLed compiler.
                A "purely bsd licensed system" is a more coherent licensing for the rest of the system and project's philosophy IMHO ... but that's mostly "a plus" for the devs.
                for the code speed and size, can you provide proper tests to show those grossly big numbers?

                This is a demonstration that the FSF isn't the only organization that are license purists. It's telling that the BSD camp always attacks the FSF camp for being GPL license purists, yet when it comes down to deciding which compiler to include in the leading BSD operating system, they base their decision not on technical issues but on license issues. Idealists will never change...
                Are you subscribed to freebsd-hackers, freebsd-current and the new freebsd-toolchain? (and some others I can't remember now) obviously, reading all the related discussions ... because what you said is a really cute story.
                Last edited by vertexSymphony; 05-13-2012, 01:01 AM.

                Comment


                • #9
                  Originally posted by LinuxID10T View Post
                  It is far slower than that in most cases. 5-15% my ass.
                  Not unless I employ optimizations not available in Clang/LLVM, like profile guided optimization or openmp in which case yes GCC often runs circles around Clang/LLVM but it's a bit 'unfair' as these are rather 'exotic' optimizations not always in use and also that they will eventually make their way into Clang/LLVM.

                  Comment


                  • #10
                    So if I understand the BSD guys in this forum correctly:

                    - FreeBSD uses GCC 4 because of *license issues* with newer version (namely their *sponsors* don't want then to use GPL3)
                    - FreeBSD will use LLVM/Clang since they don't want to use GCC > 4
                    - FreeBSD does not switch compiler for license reasons <= write black, then say white, that doesn't work
                    - LLVM/Clang are only 5-15% (15% is quite a bit btw) slower than GCC *if* you don't use GCC optimization cuz it's unfair if you do. I mean why in hell wouldn't you use GCC optimizations for your code? that doesn't make any sense

                    Well what all that tells me? I used to like FreeBSD but I see more and more value in the GPL. Pretty obviously being forced to choices by sponsors, aka by money, isn't really my vision of open source (yeah they're allowed to have that vision, but I find the free software one much more attractive).

                    Comment


                    • #11
                      Originally posted by XorEaxEax View Post
                      Not unless I employ optimizations not available in Clang/LLVM, like profile guided optimization or openmp in which case yes GCC often runs circles around Clang/LLVM but it's a bit 'unfair' as these are rather 'exotic' optimizations not always in use and also that they will eventually make their way into Clang/LLVM.
                      See, the thing is that Clang will pretty much always be years behind in performance. Is anybody drawing parallels between this and the open source graphics vs propriety graphics situation? LMFAO

                      Comment


                      • #12
                        Well what all that tells me? I used to like FreeBSD but I see more and more value in the GPL. Pretty obviously being forced to choices by sponsors, aka by money, isn't really my vision of open source (yeah they're allowed to have that vision, but I find the free software one much more attractive).
                        Sorry, but GPL-licensed projects are driven by money too (for example : http://lwn.net/Articles/395961/) ... the manpower difference between a full-time programmer and a hobbist is BIG and you see that when decisions are made

                        Comment


                        • #13
                          Originally posted by LinuxID10T View Post
                          Lets just forget for the second that X11 already has far, far more features than Wayland. Computers are getting faster all the time, if feature bloat is a problem, it shouldn't be now. I am sick of people that keep trying to reinvent the wheel. WHY?!? Yeah, X11 is old, but it works. The time can be better put into far more useful things. Just my opinion.
                          Sadly, X11 is old and can't compete with Windows and OS X solutions. Wayland is big step forward unlike Clang/llvm which is big step backward for now.

                          Comment


                          • #14
                            Originally posted by vertexSymphony View Post
                            Sorry, but GPL-licensed projects are driven by money too (for example : http://lwn.net/Articles/395961/) ... the manpower difference between a full-time programmer and a hobbist is BIG and you see that when decisions are made
                            Apples to oranges. Linux developers are being payed and he was talking about sponsors that seems to be deciding what's good for BSD.

                            Comment


                            • #15
                              Originally posted by LinuxID10T View Post
                              See, the thing is that Clang will pretty much always be years behind in performance.
                              That's impossible to say, however yes I will say that it is currently quite a bit behind GCC. However those with agendas can always skew the statistics to their liking, one of which is the choice of optimization flags. For instance Micheal recently published a test between GCC 4.6/4.7 and LLVM-Clang 3.0/3.1 where he did a 7-zip benchmark with no optimization flags. That means that the compilers (atleast GCC) makes no attempts to optimize the code, hence from a benchmark standpoint it's worthless. However choosing this likely gave Micheal the statistic he wanted, which was a win for Clang/LLVM. Another thing is synthetic tests vs real-world tests, synthetic tests can be very misgiving, case in point:

                              I made my own benchmark script for 7-zip which I ran on a core i7, comparing GCC 4.7 against Clang 3.0, I tested both the synthetic benchmark which is built into 7-zip and also did a real-world benchmark of actually compressing a file (in this case an arch linux ISO, I'm an arch guy, what can I say), here are the results at different optimization levels:

                              Code:
                              GCC    -O0 -march=corei7   1m2.420s  (real-world benchmark, less is better)
                              GCC    -O0 -march=corei7   5354      (synthetic benchmark, more is better)
                              Clang  -O0 -march=corei7   1m1.143s  (real-world benchmark, less is better)
                              Clang  -O0 -march=corei7   5446      (synthetic benchmark, more is better)
                              GCC    -O1 -march=corei7   0m32.008s (real-world benchmark, less is better)
                              GCC    -O1 -march=corei7   11375     (synthetic benchmark, more is better)
                              Clang  -O1 -march=corei7   0m35.316s (real-world benchmark, less is better)
                              Clang  -O1 -march=corei7   11650     (synthetic benchmark, more is better)
                              GCC    -O2 -march=corei7   0m31.076s (real-world benchmark, less is better)
                              GCC    -O2 -march=corei7   11704     (synthetic benchmark, more is better)
                              Clang  -O2 -march=corei7   0m34.550s (real-world benchmark, less is better)
                              Clang  -O2 -march=corei7   11808     (synthetic benchmark, more is better)
                              GCC    -O3 -march=corei7   0m29.432s (real-world benchmark, less is better)
                              GCC    -O3 -march=corei7   11890     (synthetic benchmark, more is better)
                              Clang  -O3 -march=corei7   0m34.335s (real-world benchmark, less is better)
                              Clang  -O3 -march=corei7   11796     (synthetic benchmark, more is better)
                              As we can see, on this synthetic benchmarks, Clang/LLVM wins up until -O3 where GCC wins, so by choosing -O0 up to -O2 and only using synthetic benchmarking Clang/LLVM would come out the winner. However given that -O3 is the option where the compiler is supposed to favour speed over anything else (like code size) then I can't see why someone, if they only test ONE option would test anything else, unless of course you want the results to reflect some agenda.

                              And looking past the synthetic benchmark and at the real-world benchmark which is what actually reflects the REAL usage of 7-zip, GCC wins across the board, with a very noticeable performance increase.

                              Here's the script I made (sorry for my poor bash script-fu), it will automatically download p7zip and an arch linux iso (just the first time, not every run!) which it will compress in the real-world test. There's also support for ICC (intel compiler) testing there but I didn't use it for this test. The results of the benchmarking is saved in p7zip-results.txt in the same directory from which you run the script:

                              Code:
                              #!/bin/bash
                              name=p7zip_
                              version=9.20.1
                              dir=$name$version
                              results=../p7zip-results.txt
                              makefile=makefile.linux_amd64
                              arg="./bin/7za a -mx9 -m0=LZMA2:d128m -mmt dummy.7z archlinux-2011.08.19-netinstall-i686.iso"
                              arg2="./bin/7za b"
                              
                              # change flags according to the optimization settings you want to benchmark
                              gccflags="-O3 -march=corei7"
                              clangflags="-O3 -march=corei7"
                              iccflags="-O3 -march=corei7"
                              
                              # uncomment compilers to be tested (obviously they need to have been installed)
                              gcc=1
                              clang=1
                              #icc=1
                              
                              if [ ! -d $dir ]; then
                              	echo "Downloading and extracting p7zip..."
                              	wget -q http://downloads.sourceforge.net/project/p7zip/p7zip/${version}/p7zip_${version}_src_all.tar.bz2
                              	bzip2 -q -d "$dir"_src_all.tar.bz2
                              	tar xf "$dir"_src_all.tar
                              fi
                              
                              cd $dir
                              
                              if [ ! -e archlinux-2011.08.19-netinstall-i686.iso ]; then
                              	echo "Downloading iso..."
                              	wget -q http://ftp.ds.hj.se/pub/os/linux/archlinux/iso/2011.08.19/archlinux-2011.08.19-netinstall-i686.iso
                              fi
                              
                              # access the file for cache purposes else the first real-world test will likely suffer in disk read performance. 
                              tar cvf dummy.tar archlinux-2011.08.19-netinstall-i686.iso
                              rm dummy.tar
                              
                              
                              if [ ! -z $gcc ]; then
                              # GCC ----------------------------------------------------------------------------------------------------
                              cp $makefile makefile.machine
                              sed -i "s/OPTFLAGS=-O/OPTFLAGS=$gccflags/" makefile.machine
                              make clean
                              make -j5
                              clear
                              echo "Benchmarking..."
                              bench=`{ time ${arg}; } 2>&1 | grep real | awk '{print $2}'`
                              echo -e "GCC\t\t$gccflags\t\t$bench\t(real-world benchmark, less is better)" >> $results
                              bench=`{ ${arg2}; } 2>&1 | grep Tot | awk '{printf $4}'`
                              echo -e "GCC\t\t$gccflags\t\t$bench\t\t(synthetic benchmark, more is better)" >> $results
                              rm dummy.7z
                              fi
                              
                              if [ ! -z $clang ]; then
                              # CLANG/LLVM ---------------------------------------------------------------------------------------------
                              cp $makefile makefile.machine
                              sed -i "s/OPTFLAGS=-O/OPTFLAGS=$clangflags/" makefile.machine
                              sed -i 's/CXX=g++/CXX=clang++/' makefile.machine
                              sed -i 's/CC=gcc/CC=clang/' makefile.machine
                              make clean
                              make -j5
                              clear
                              echo "Benchmarking..."
                              bench=`{ time ${arg}; } 2>&1 | grep real | awk '{print $2}'`
                              echo -e "Clang\t\t$clangflags\t\t$bench\t(real-world benchmark, less is better)" >> $results
                              bench=`{ ${arg2}; } 2>&1 | grep Tot | awk '{printf $4}'`
                              echo -e "Clang\t\t$clangflags\t\t$bench\t\t(synthetic benchmark, more is better)" >> $results
                              rm dummy.7z
                              fi
                              
                              
                              if [ ! -z $icc ]; then
                              # ICC ---------------------------------------------------------------------------------------------
                              cp $makefile makefile.machine
                              sed -i "s/OPTFLAGS=-O/OPTFLAGS=$iccflags/" makefile.machine
                              sed -i 's/CXX=g++/CXX=icpc/' makefile.machine
                              sed -i 's/CC=gcc/CC=icc/' makefile.machine
                              make clean
                              make -j5
                              clear
                              echo "Benchmarking..."
                              bench=`{ time ${arg}; } 2>&1 | grep real | awk '{print $2}'`
                              echo -e "ICC  \t\t$iccflags\t\t$bench\t(real-world benchmark, less is better)" >> $results
                              bench=`{ ${arg2}; } 2>&1 | grep Tot | awk '{printf $4}'`
                              echo -e "ICC  \t\t$iccflags\t\t$bench\t\t(synthetic benchmark, more is better)" >> $results
                              rm dummy.7z
                              fi
                              
                              echo "Done! Open '$results' to see the benchmark results."

                              Comment

                              Working...
                              X