Cooking LLVM in FreeBSD 8
On Ivoras'FreeBSD page, ``What's cooking for FreeBSD 8'' http://ivoras.sharanet.org/freebsd/freebsd8.html one can read about the possible substitution of GCC by LLVM (among other candidates). Under the assumption that LLVM is selected, would this mean that FreeBSD will somehow integrate the OCaml compiler? Of course OCaml is already in the ports, but if it is somehow integrated in the base system, there is serious opportunities to write system tools with this language. -- Cheers, Michaël ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
On Ivoras'FreeBSD page, ``What's cooking for FreeBSD 8'' http://ivoras.sharanet.org/freebsd/freebsd8.html LLVM site shows it's something like precompiler+runtime compiling. will it be used that way, or as usual compiler? the first way sound really good (single binary for every arch, and optimized at runtime) but i think it will need HUGE change in system. second would be just a replacement one can read about the possible substitution of GCC by LLVM (among other candidates). Under the assumption that LLVM is selected, would this mean that FreeBSD will somehow integrate the OCaml compiler? Of course OCaml is already in the ports, but if it is somehow integrated in the base system, there is serious opportunities to write system tools with this language. -- Cheers, Michaël ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
On Tue, Mar 17, 2009 at 01:49:24PM +0100, Wojciech Puchar wrote: On Ivoras'FreeBSD page, ``What's cooking for FreeBSD 8'' http://ivoras.sharanet.org/freebsd/freebsd8.html LLVM site shows it's something like precompiler+runtime compiling. will it be used that way, or as usual compiler? I think the idea is to get away from gcc with its evil GPL3 license as the default compiler. To that end, it looks like decent strides are being made with the clang front end to llvm: http://wiki.freebsd.org/BuildingFreeBSDWithClang I got bored one day and installed the port, set CC=ccc in /etc/make.conf then built a few ports with it to benchmark against various gcc incantations. (Very unscientific, so I won't post numbers). I wasn't quite bored enough to try a make world with it, though. But according the the link I provide, it appears to be 99% of the way there. As best I can tell, there would be a non-trvial performance loss with using clang at this point. At wth least with the version that's currently in the ports tree (I didn't try building from the latest svn version). It does look promising, though. I hope it'll eventually surpass gcc in optimization of code. I'm sure others are anxious for license purity within the base system. -- Geoff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
I think the idea is to get away from gcc with its evil GPL3 license as the very good move. i wasn't aware that usable GCC replacement exist, as it was probably the only reason to keep communist licenced programs with master FreeBSD sources. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
It does look promising, though. I hope it'll eventually surpass gcc in actually - it's matter of measurement. for example - gcc generated code is very fast, but often in expense of code size. Even -Os compiled programs are quite large. Large code=less efficient caching=SLOWER overall performance with mixed load and lots of task switching which is normal under unix. Even if this new compiler generates slightly slower but SMALLER code, it could produce overall-faster system ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
On Tue, Mar 17, 2009 at 03:19:52PM +0100, Wojciech Puchar wrote: I think the idea is to get away from gcc with its evil GPL3 license as the very good move. i wasn't aware that usable GCC replacement exist, as it was probably the only reason to keep communist licenced programs with master FreeBSD sources. Please don't read too much into my remark, as I don't like to engage in license ideology debates. I like GPL, BSD, and all the zillions of other open source variants. In my pre-coffee mental haze this morning, I didn't phrase it in such a way to denote that it was mostly a toungue-in-cheek comment about the motivation to replace the venerable gcc from the base system (which, for technical reasons, I personally feel to be a worthy goal). -- Geoff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
On Tue, Mar 17, 2009 at 03:27:37PM +0100, Wojciech Puchar wrote: It does look promising, though. I hope it'll eventually surpass gcc in actually - it's matter of measurement. for example - gcc generated code is very fast, but often in expense of code size. Even -Os compiled programs are quite large. Large code=less efficient caching=SLOWER overall performance with mixed load and lots of task switching which is normal under unix. Even if this new compiler generates slightly slower but SMALLER code, it could produce overall-faster system I'm a big supporter of small, efficient binaries. In fact, I'll often put -Os in my /etc/make.conf CFLAGS setting. This only rarely improves raw speed over more agressive optimization flags, however. I use it primarily for programs that are huge to begin with (Firefox, for example) or programs that have many instances running (my shell, my terminal program, etc.) for the sake of conserving memory. I tested clang (ccc), the stock 7.1 gcc (4.2.1), and gcc 4.3.4, using -Os and -O0, -O2, and -O3. For raw speed, gcc43 with -O3 took the lead. In every case, even the stock gcc beat ccc. To be honest, I didn't pay too much attention to the binary size, though I'm pretty sure both gcc variants beat ccc in that benchmark. Like I said before, I wasn't overly scientific in my methodology. I compiled the zip port for my tests (very fast compile). I ran the same task in a loop 5 times, and took the mean of the timings from time. I did pre-load the file into filesystem cache by reading it with dd before the calls to zip (which wrote to /dev/null). In every case, ccc was last in performance when compared with the same CFLAGS. However, I didn't have time to see if, for example, -O3 for ccc resulted in a faster binary than -O0 for gcc. I wish lang/tcc would run under amd64. Talk about small binaries! Somebody with a compulsion for benchmarking could put this to the test. After seeing Roland's benchmarking zeal in the best archiver thread, maybe he should join the fun. ;-) -- Geoff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
master FreeBSD sources. Please don't read too much into my remark, as I don't like to engage in license ideology debates. I like GPL, BSD, and all the zillions of other i do use GPL programs too without any problems - because there is no BSD licenced equivalent (most often), or BSD licenced equivalent is much weaker (rare cases). but it doesn't change what i said. GPL licence is unacceptable if you want to make any commercial product based on code licenced that way. FREEDOM CAN NOT BE ENFORCED. open source variants. In my pre-coffee mental haze this morning, I didn't phrase it in such a way to denote that it was mostly a toungue-in-cheek comment about the motivation to replace the venerable gcc from the base system (which, for technical reasons, I personally feel to be a worthy goal). -- Geoff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Cooking LLVM in FreeBSD 8
I'm a big supporter of small, efficient binaries. In fact, I'll often put -Os in my /etc/make.conf CFLAGS setting. This only rarely improves raw speed over more agressive optimization flags, however. I use it primarily it do improves speed on DSP-like code that do repetitively the same on large data set, and the code is small. every case, even the stock gcc beat ccc. To be honest, I didn't pay too much attention to the binary size, though I'm pretty sure both gcc variants beat ccc in that benchmark. how much the difference was? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
