On Tuesday 21 April 2009 17:58:15 Mel Flynn wrote: > On Tuesday 21 April 2009 17:37:50 David Naylor wrote: > > On Tuesday 21 April 2009 10:32:04 Mel Flynn wrote: > > > Hi David, > > > > > > On Monday 20 April 2009 21:48:39 David Naylor wrote: > > > > There has been an article recently published by phoronix > > > > (http://www.phoronix.com/scan.php?page=article&item=pcbsd_vs_kubuntu&; > > > >nu m= 1) that compares PC-BSD to Kubuntu. Kubuntu uses GCC 4.3.3 > > > > compared to FreeBSD's GCC 4.2.2. There is a considerable performance > > > > difference between the two OS's, the article contributes this > > > > difference to the compiler. > > > > > > Nice shot in the dark, since except the calculations a lot of these are > > > influenced by "journaled FS vs stock UFS". > > > > I know, benchmarking anything but the simplest things are influenced by > > too many factors. Pity it doesn't provide an unbiased comparison of > > FreeBSD and Linux. > > That and comparing apples and pears as default configured fruit, don't > usually work well. Of course it appeals to the end user "which fruit is > healthier".
:-) > > > > In order to check if this is so (and to get the speed improvements of > > > > GCC 4.3+) one needs to compile the ports (and preferable world/kernel > > > > as well) with GCC 4.3+. > > > > > > It's license is incompatible with world/kernel. > > > > What type of incompatibility. I know FreeBSD has reservations about > > GPLv3 (I personally don't understand why everyone cannot be friends and > > use BSD Licenses). So is this a policy incompatibility or a legal one > > (i.e. would it be 'illegal' for me to use GCC 4.3+ to compile > > world/kernel, as an end-user/consumer of FreeBSD). I assume the same > > discussion applies to binutils. > > Policy. Only legal issue in FreeBSD for the end user is WITH_IDEA. Thanks for sorting that out. Good news for me. > > > That said, install > > > lang/gcc43 and set CC/CXX for ports. World/kernel would be a lot > > > harder. Maybe setting WITHOUT_GCC in /etc/src.conf and setting CC/CXX > > > would work, but there's quite a few modifications to gcc that aren't in > > > ports lang/gcc, so I have my doubts. > > > > I suppose it would be nice if there was an easy way to use an > > out-of-source compiler in FreeBSD. Like set PORTS_COMPILER=gcc43 and the > > port will installed and used... One may have dreams. > > cat <<'EOF' >> /etc/make.conf > .if !empty(.CURDIR:M/usr/ports/*) > CC=/usr/local/bin/gcc43 > CXX=/usr/local/bin/g++43 > .endif > EOF > > Pretty close, huh? Kinda, it is what I was thinking about (or just symlinking cc, cxx to the proper programs). Of course if this is implemented 'properly' in ports then auto-dependencies and all that will be added. I was actually thinking about replacing the standard compiler by a) not installing gcc 4.2.2 (i think WITHOUT_GCC, as mentioned by yourself) b) installing latest gcc: # make -C /usr/ports/lang/gcc43 install DESTDIR=/new/freebsd/system PREFIX=/usr -DWITHOUT_JAVA [ With symlinks from gcc43 -> gcc, etc] c) Hoping this works Well something like that (with extra hope) > > > > Is there an easy way to set this up and does anyone know the > > > > compatibility of world/kernel/ports with GCC 4.3+? > > > > > > > > Also has anyone tried this and benchmarked the result? > > > > > > Not me, but be sure to stick around for the new non-gcc compiler coming > > > to a FreeBSD near you. And with the work done by Marcel Molenaar on > > > gpart, hopefully we can have ZFS and gjournal as choices in the > > > installer. > > > > You mean llvm, waiting patiently. I suppose my suggestion above will > > become even more important (at least for compiling ports) since it will > > be a while till llvm has decent c++ support. > > Yeah, I don't know how that's gonna work if llvm is ready for base, but no > c++. I guess we'll have to sit out g++ 4.2 for a while. If you're in the > position to do so, I'd do their benchmarks with ZFS and see how much > difference that already makes. Well, llvm does support C++ (with the gcc frontend) so that shouldn't be too much of a problem. clang is more of the issue but I suppose we could always have llvm-clang for C and llvm-gcc for C++ (until clang gets full C++ support).
signature.asc
Description: This is a digitally signed message part.
