Overly Hyped [LWN.net]

Overly Hyped

Posted Nov 13, 2008 16:53 UTC (Thu) by clugstj (subscriber, #4020)
Parent article: Things that go Clang in the night: LLVM 2.4 released (ars technica)

This reminds me of an article from some months ago where someone was writing a replacement for the "ld" command. People were gushing about it being faster, smaller, other "compelling advantages". The actual facts of the matter were that what it did was a very narrow subset of the actual capabilities of GNU "ld" (only supported the x86 ISA, only supported the ELF file format). This seems to be much the same. All this talk about speed of compilation, compiler memory usage, but nothing about how the generated code runs.

I have no problem with anyone writing replacements for tools, but lets lay off the hype unless the new tool can actually replace the old one in some real-world situations.

Overly Hyped

Posted Nov 13, 2008 17:51 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (1 responses)

Ian Taylor's "gold" linker currently only supports ELF/x86 and ELF/x86_64. Adding back ends for more ISAs should not be difficult, but supporting object file formats other than ELF would be much harder; to quote Ian's announcement, "There is no expectation that gold will ever support anything other than ELF targets."

Overly Hyped

Posted Nov 13, 2008 22:24 UTC (Thu) by andikleen (guest, #39006) [Link]

It supports sparc64 too now.

Overly Hyped

Posted Nov 13, 2008 18:40 UTC (Thu) by darthscsi (guest, #8111) [Link] (6 responses)

Interprocedural optimization of an entire linux kernel not enough for you (SOSP2007, though actually that was just a side effect of making the kernel memory safe (e.g. no buffer overflows, etc))? JITing of per-application OpenGL stacks (MacOS)? Compiling iPhone Apps? JITing image processing routines optimized for the specific image and combination of transformations (adobe). C to flash translation so you can run C programs (including bash, python, and nintendo enumlators) in a browser (adobe)? These are not real enough workloads for you? Most of those are shipping.

Overly Hyped

Posted Nov 13, 2008 19:51 UTC (Thu) by clugstj (subscriber, #4020) [Link] (5 responses)

Sorry, I've got to call Bullshit on this. If there were a compiler for the linux kernel that was as wonderful as you say, all the kernel developers would be using it.

Overly Hyped

Posted Nov 13, 2008 23:58 UTC (Thu) by darthscsi (guest, #8111) [Link] (4 responses)

Go ahead and call bullshit. Let me refer you to:
http://portal.acm.org/citation.cfm?id=1294295
for the linux kernel, and other users:
http://www.tungstengraphics.com/wiki/index.php/Gallium3D#...
http://www.osnews.com/story/15530/LLVM-at-Apple-the-OpenG...
http://www.ipodobserver.com/story/30184
http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/11
http://www.ffconsultancy.com/products/ocaml_journal/?llvm
http://ajaxian.com/archives/llvm-and-running-c-as-well-as...

Oh and back to the kernel...

llvm-gcc -Wp,-MD,arch/x86/kernel/.ioport.o.d -nostdinc -isystem ~~/cfe/install/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -I~~/Applications/linux-2.6.27.5/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O0 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium2 -mtune=generic -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-generic -Iinclude/asm-x86/mach-default -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ioport)" -D"KBUILD_MODNAME=KBUILD_STR(ioport)" -c -o arch/x86/kernel/ioport.o arch/x86/kernel/ioport.c

llvm-gcc -Wp,-MD,arch/x86/kernel/.ldt.o.d -nostdinc -isystem ~~/cfe/install/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -I~~/Applications/linux-2.6.27.5/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O0 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium2 -mtune=generic -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-generic -Iinclude/asm-x86/mach-default -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ldt)" -D"KBUILD_MODNAME=KBUILD_STR(ldt)" -c -o arch/x86/kernel/ldt.o arch/x86/kernel/ldt.c

llvm-gcc -Wp,-MD,arch/x86/kernel/.setup.o.d -nostdinc -isystem ~~/cfe/install/bin/../lib/gcc/i686-pc-linux-gnu/4.2.1/include -D__KERNEL__ -Iinclude -I~~/Applications/linux-2.6.27.5/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O0 -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium2 -mtune=generic -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-generic -Iinclude/asm-x86/mach-default -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(setup)" -D"KBUILD_MODNAME=KBUILD_STR(setup)" -c -o arch/x86/kernel/setup.o arch/x86/kernel/setup.c

just to pick out something scrolling by my screen right now (Paths slightly mangled for privacy). (The llvm knowledgeable will recognize that this build is not doing IPO, but see the SOSP07 paper where complex interprocedural analysis and transformations were performed on the entire kernel).

Overly Hyped

Posted Nov 14, 2008 2:41 UTC (Fri) by clugstj (subscriber, #4020) [Link] (2 responses)

Please read the comment to which you are replying. The article is about something called "Clang" that is to replace the GCC-based front end to LLVM. You are apparently not using "Clang" because your command line begins with "llvm-gcc". So what you are hyping is not actually what the article was about.

Overly Hyped

Posted Nov 14, 2008 3:41 UTC (Fri) by darthscsi (guest, #8111) [Link] (1 responses)

Please read the article, the article is about the llvm 2.4 release. Clang is an in development sub-project of that. I am quite aware that I am using llvm-gcc and not clang. But neither the complaint about the hype (and implication that it is thus not worth looking at) nor the original article are about Clang, they are about llvm. The ability to do IPO on large projects with llvm is not dependent on the C frontent (clang or llvm-gcc) you are using.

Overly Hyped

Posted Nov 14, 2008 18:54 UTC (Fri) by clugstj (subscriber, #4020) [Link]

Funny, "Clang" is the 4th word in the title of said article.

Overly Hyped

Posted Nov 20, 2008 14:24 UTC (Thu) by Nelson (subscriber, #21712) [Link]

Is that actually compiling the kernel code with LLVM? The man pages are a bit confusing, aren't the -S and -emit-llvm options required? It's not clear to me if that's just normal GCC or LLVM without the link time options.

Overly Hyped

Posted Nov 13, 2008 22:01 UTC (Thu) by wmf (guest, #33791) [Link] (1 responses)

> People were gushing about it being faster, smaller, other "compelling advantages". The actual facts of the matter were that what it did was a very narrow subset of the actual capabilities of GNU "ld"...

Another way to look at it is that many open source projects are being held back by support for obscure platforms with few users. Concentrating on Linux/x86 could speed development of these projects for the majority of mainstream users.

Overly Hyped

Posted Nov 14, 2008 0:32 UTC (Fri) by SLi (subscriber, #53131) [Link]

Yet another view that I've seen in practice: While support for multiple
architectures and obscure devices sometimes are a pain, often they also
increase the quality of the code by forcing people to think about
abstractions. Good examples would be Linux and NetBSD.

Overly Hyped

Posted Nov 14, 2008 0:38 UTC (Fri) by jwb (guest, #15467) [Link] (1 responses)

Well there are actually lots of papers about how well llvm's generated code performs. I read one regarding the llvm php project that was only about 100x slower than the regular php interpreter ...

Overly Hyped

Posted Nov 14, 2008 6:11 UTC (Fri) by nhippi (subscriber, #34640) [Link]

The point of the php project was to test how fast it takes to write a LLVM based php JIT compiler. It took two days.

Ofcourse something written in two days isn't going to be optimized at all, or be any kind of competition PHP's zend engine which has been tuned for 10 years...

Overly Hyped

Posted Nov 20, 2008 18:15 UTC (Thu) by jzbiciak (guest, #5246) [Link]

In the comparison between GCC's C and C++ frontends and Clang, Clang is smaller and faster and more reusable. Is that what you're complaining about? That it doesn't support non-C-like languages?

g77, gfortran, GNAT, etc. are all different front ends. Nothing stops LLVM from getting front ends for those languages at some point.

Overly Hyped

Posted Nov 21, 2008 19:39 UTC (Fri) by lysse (guest, #3190) [Link]

> I have no problem with anyone writing replacements for tools, but lets lay off the hype unless the new tool can actually replace the old one in some real-world situations.

Like, for example, linking ELF-format x86* binaries? Or are you using "some" as a synonym for "all" in this instance?