Slashdot Mirror

If you'd like an actual C/C++ compiler that uses LLVM, try either llvm-gcc or Clang, which is probably going to be a serious competitor to gcc in a year or two.

Intel's icc is a collection of special cases. If your code does not fit into this grid of special cases, it will be slow.
Your actual answer is called LLVM.

"C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it"

The 'const' function attribute does that and works fine: http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

And, C compilers have performed such optimization automatically on a much finer scale than functions for ages (common subexpression elimination), and there really is no reason why future versions won't do it just as much, and on all the same scales as java compilers/vm's eventually will.

"The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster without touching the compiled system."

Sure, a future version will beat something that exists today, future versions of java vm's will be faster than current versions (thank $DEITY)... But so will C compilers... C compilers beat java vm's today, and there is nothing about the java language that can't be done with C, see for example http://llvm.org/

Quite possibly the future of executables (for certain types of executables) is more towards the VM/jit approach, but that is language independent.

While many languages are much easier to use than C (in their application areas), saving development time, and can be for all intents and purposes as fast as it needs to be, saying they will be faster than C will be, is falsely assuming that C compilers have stopped developing further... Perhaps faster than C is today, but not faster than it will be.

imho, the bucket of gold at the end of the rainbow is there where you can choose your programming language freely, interface across language barriers with ease, and build a final program from such a mixture of languages if needed.

• a language extended from C99,
• a platform (hardware + OpenCL-aware device driver), and
• a compiler and runtime (which may decide where to send a compute task at run time).

If you're writing an OpenCL-aware device device driver for a GPU, you'll probably need to wait a bit for some open source examples. It's reasonably likely that there will be some included in Darwin (once updated for Snow Leopard).

Look to the LLVM project (sponsored heavily by Apple and others) for an open source compiler which will (if it doesn't already) know about OpenCL.

It sounds like you might be looking for a higher level API which allows you to more easily use the OpenCL, or possibly for language bindings to Java or Python perhaps? I suspect you'll see those coming along, once Apple ships Snow Leopard, and people have a chance to kick the tires, and then integrate LLMV into their tool chains, extend various higher level API, bridge to Java and whatnot.

The earliest high level API to take easy and broad advantage of OpenCL will probably be from Apple, of course. They'll likely provide some nicely automatic ways to take advantage of OpenCL without programming the OpenCL C API directly. As a Cocoa programmer, you'll be using various high level objects, maybe an indexer for example, which have been taught new OpenCL tricks. You'll just recompile your program and it will tap the GPU as appropriate and if available. The Cocoa implementation is closed source, but people will see what's possible and emulate it in various open source libraries, on other platforms, for Java and other languages.

Here's a good place to start: OpenCL - Parallel Computing on the GPU and CPU. Follow up with a google search.

Like, there's only one Linux kernel, only one C compiler, only one bash shell.. only one Perl, only one Java...

You are correct that there are only one Linux kernel, but there are other free UNIX kernels you could use instead. When it comes to compilers both LLVM and GCC are widely used. (LLVM is used in Gallum3D, the new acceleration architecture for X, and in Shark, a CPU agnostic JIT for OpenJDK. A C frontend not based on GCC is in development) There are many shells. Ubuntu, a quite popular Linux distro, actually uses dash as default /bin/sh. While it's true that only OpenJDK (if I recall correctly) passes the TCK for Java you also have competing implementations like Harmony, what Google uses on Android. You have more competition on the parts of the Java stack that takes less time to implement.

Like, there's only one Linux kernel, only one C compiler, only one bash shell.. only one Perl, only one Java...

You are correct that there are only one Linux kernel, but there are other free UNIX kernels you could use instead. When it comes to compilers both LLVM and GCC are widely used. (LLVM is used in Gallum3D, the new acceleration architecture for X, and in Shark, a CPU agnostic JIT for OpenJDK. A C frontend not based on GCC is in development) There are many shells. Ubuntu, a quite popular Linux distro, actually uses dash as default /bin/sh. While it's true that only OpenJDK (if I recall correctly) passes the TCK for Java you also have competing implementations like Harmony, what Google uses on Android. You have more competition on the parts of the Java stack that takes less time to implement.

Yes, exactly. Interesting historical anecdote from the 70s, I wasn't aware of that. I first encountered the idea from this paper, which makes it seem a close possible reality. In their case, they used the compact "bc" representation of the LLVM IR.

If we didn't use the x86 instruction set we'd have to invent something quite similar to it.

I agree that there would still need to be a set of primitive hardware operations. I also agree that there would need to be a way that binaries are persistently represented. But must the same thing perform both functions? Can't we decouple that with something somewhat like Transmeta's code-morphing layer? (link)

This is great news. The work that Apple's doing on LLVM is a renaissance in compilers.

-jcr

It's static-single-assignment, which is an entirely different architecture to RISC.

Odd, then, that LLVM's very own documentation refers to LLVM's instruction as "an abstract RISC-like instruction set". Remember, RISC-like only describes the nature of the actual instructions (basic arithmetic, flow control, etc), not the style of the register set. LLVM's IR just happens to model a RISC-like instruction set with an infinite set of write-only registers. That, combined with the ability to specifiy "key higher-level information for effective analysis, including type information, explicit control flow graphs, and an explicit dataflow representation" yields an IR which makes it very easy to analyze data flow in the program, facilitating certain classes of optimizations.

The Python object files are just a more convenient way to store the program compared to text files. No information is lost or glue is added in that first step.

LLVM is, like its name suggests, really low level. You should think of it as a kind of portable assembly. It's much closer to actual hardware architectures than for example Java byte code. I don't expect much overhead from the LLVM to native step. A while ago I ran some tests with C++ compiled by GCC directly to native and compiled by GCC to LLVM byte code and then by LLVM to native; sometimes one approach was faster and sometimes the other, but they were pretty close.

So that leaves the glue added in the Python object to LLVM step. I expect this to have a significant overhead, but I don't see it becoming a smaller overhead by going directly to native. The advantage of using LLVM is that you only have to write this step once, instead of once for each architecture.

With LLVM it is possible to compile parts of the interpreter to LLVM byte code in advance and then inline that into the program being JIT-compiled. That way, you can be sure that the JIT and the interpreter actually do the same thing. Apple did this for their OpenGL driver, there is a nice presentation (PDF) about it.

Quite to the contrary, the FreeBSD guys have been building with clang+llvm for a while now, and they seem to like it. The kernel boots, init inits, filesystems mount, the shell runs.

What other platforms, Darwin? Apple employs the largest number of LLVM developers. Windows? Both MinGW and Visual Studio based builds are tested for each release.

It's still not as portable as the python interpreter, but that will come if and when developers who are interested in working on it start to contribute.

Quite to the contrary, the FreeBSD guys have been building with clang+llvm for a while now, and they seem to like it. The kernel boots, init inits, filesystems mount, the shell runs.

What other platforms, Darwin? Apple employs the largest number of LLVM developers. Windows? Both MinGW and Visual Studio based builds are tested for each release.

It's still not as portable as the python interpreter, but that will come if and when developers who are interested in working on it start to contribute.

The cool kids are working on LLVM and L4.

Actually, it's not the virtual machine that enables SIPs (software isolated processes), but the compiler. By being able to prove, through static analysis, that the code of a process is isolated, one can safely run the programs in the same address space. In the case of Singularity, the name of this research compiler is "Bartok", and its power comes from having a strong intermediate-representation: CIL.

Now here's where most people don't make a connection: note how similar this is to Apple's efforts with LLVM: a modern compiler capable of amazing static-provability. I wonder what sort of magic could be enabled by that...hmm...how about something very much like SIPs? Really, the pubs directory over at llvm.org is good reading, especially when you keep what Microsoft is trying to accomplish with Midori/Singularity in mind.

An interesting question, to me: which of these efforts is more likely to result in a shipping product first? Moreover, which one is likely to be the least disruptive for users to adopt? In theory, one should be able to slip an LLVM-based SVA under the existing operating system, with the only caveat being that app vendors might have to recompile their apps. (Imagine adding LLVM BC to the fat binary bundle alongside x86 and PPC). It's harder for me to imagine a smooth transition in the Windows world.

Apple provide significant funding for two important academic projects, LLVM and clang. (I wouldn't be surprised to see clang+llvm supplant gcc on some architectures by 2010.)

Apple provide significant funding for two important academic projects, LLVM and clang. (I wouldn't be surprised to see clang+llvm supplant gcc on some architectures by 2010.)

That doesn't mean that the technology doesn't exist to make the compilers better, but if it does, nobody's bothering because it isn't making a difference (on most x86, at least).

The LLVM + Clang project would probably disagree with you.

That doesn't mean that the technology doesn't exist to make the compilers better, but if it does, nobody's bothering because it isn't making a difference (on most x86, at least).

The LLVM + Clang project would probably disagree with you.

Not all of that code is usable. Most is using the restrictive APSL that is not BSD compatible.

Apple do release some stuff using the BSD licence however. launchd is an example of a good piece of code other OS vendors should consider (though it could use one more turn of refactoring). They've also contributed a lot to llvm, which I think is likely to replace gcc in many systems sometime in the future.

Also there is that "new" BSD licensed compiler, I don't remember the name, I have no idea if it's complete enough to be able to compile said benchmarks and compete with GCC but it would had been interesting with that one to.

You're probably thinking of LLVM. It does have a gcc front-end, so can be used to compile most things gcc can.

There's another one or two, but LLVM's probably the only serious contender against gcc.

More details here: http://www.llvm.org/devmtg/2008-08/ (Look for the topic - Flash C Compiler: Compiling C code to the Adobe Flash Virtual Machine)

While scrolling down looking for the Adobe talk, I found this:

Designflow: using LLVM to compile to Hardware - This project uses LLVM to compile code to a mixed hardware and software implementation. This detects pieces of programs that may be efficiently compiled to VHDL and synthesized them onto an FPGA. The rest of the program is compiled to PowerPC code and uses to drive the FPGA. The system automatically handles data migration and other handshaking between the two systems.

Waaaayyyy more interesting than LLVM for flash. This is cool!!!

More details here: http://www.llvm.org/devmtg/2008-08/ (Look for the topic - Flash C Compiler: Compiling C code to the Adobe Flash Virtual Machine)
You post your ideas for Adobe here: http://www.adobe.com/cfusion/webforums/forum/categories.cfm?forumid=72&catid=755&entercat=y These forums are closely watched by the flash player team.

The GNU toolchain is old, has seen little innovation, and has not kept up pace with Microsoft and Apple facilities

You realise that Apple currently uses the GNU compiler?

You realize Apple is slowly getting rid of it? The current XCode (3.1) has LLVM as an optional code-generation backend using GCC as a frontend, and Apple is one of the primary developers of the LLVM Clang project, which will replace the GCC frontend.

article didn't include it, but this open source project seems to have similar goals

http://llvm.org/

You think that's bad? Take a look at the LLVM bugs sometime.

"...debugger integration is not really their strongest point."

You should really take a sideways look at the iPhone SDK. The debugger integration is solid and almost up there with Visual Studio for memory and thread debugging.

While xcode is technically just a wrapper on top of GCC, Apple has done an enormous amount of work to integrate all elements of the toolchain into the environment in a way that enhances developer productivity.

I used xcode when it first came out and was underwhelmed - it was really just a simple gcc wrapper back then. But, it's evolved significantly and makes the GNU tools it's built on actually efficient to use (think using the CLI version of gdb for debugging compiled, multi-threaded code on remote devices... sure, you can do it, but it's a time sink).

-Chris

Don't forget to add that XCode's evolutionary path will be focused around LLVM, Clang, and much more.

Clearly, from the 2008 August LLVM Meeting Minutes it's clear the Industry is working to get this option mature and ready.

2008 LLVM Developers' Meeting

" (or the 21st century version: "compilers can perform better optimizations that JIT translators").

Actually, JITters can do some optimizations that compilers can't--by splitting the compilation into a frontend and a backend. The front end is essentially just a parser, and the later the back-end compile happens, the more opportunities for optimizations actually open up (including such things as utilizing specific instruction sets for given architectures and fine tuning the compile based on run time statistics).

See the LLVM for more info: http://llvm.org/

(or .NET for that matter--but we're anti-MS around here. :-)

Given JIT compiler frameworks such as LLVM (http://llvm.org/), there's no reason that an interpreter environment can't be as fast (asymptotically) as "real" compiled code any more. The real divide is between static and dynamic typing now. The latter gives more flexibility (unrestricted polymorphism), but defers type checks until runtime which of course incurs a runtime cost.

I really hope the future is dynamically-compiled languages, because they can optimize for a particular machine on a particular boot; many more things become compile-time constants. Apple's use of LLVM is promising.

As it happens, Apple are not that keen on gcc, for (I gather) both technical and licensing reasons. That's why they are funding the clang project. It's a new compiler for C, C++ and Objective C, with lots of great technical features. It's original aims include licensing designed to allow it to "be used for commercial projects". I would not be suprised to see clang and llvm supplant gcc one day.

As it happens, Apple are not that keen on gcc, for (I gather) both technical and licensing reasons. That's why they are funding the clang project. It's a new compiler for C, C++ and Objective C, with lots of great technical features. It's original aims include licensing designed to allow it to "be used for commercial projects". I would not be suprised to see clang and llvm supplant gcc one day.

> It's written for Windows, you're running OSX? No problem, it'll rewrite itself as an OSX program. Though, that's probably still decades off. But AI seems to me to be the way to ultimate compatibility.

It exists today. It is called LLVM. If you use llvmc to target the LLVM assembly, then you'll get exactly what you say.

I think that it will, one day, replace gcc. Apple already uses it for the iPhone toolchain and the OpenGL stack.

Take a look at llvm: the potential is really amazing.

Compiler performance is important for development teams that have mountains of code and wish to implement continuous integration and automated builds (OS vendors for example). Apple's interest in LLVM appears to be based in part on a desire for improved compiler performance. (Obviously they're interested in LLVM for several other reasons, too.) See these starting points:
experimenting with LLVM
LLVM 2.0 (Google Tech Talk)
LLVM Project

There are hints here and there, that Apple has been working on the technologies which will sum up to "Grand Central" for quite a while.

Take a look at NSOperation class reference which appeared with Leopard.

Also, consider the thread farming rumors which briefly flurried a while back. (The smart money is on implicit parallelization).

Finally, the more you learn about LLVM, the easier it will be to read the tea leaves for Mac OS X. Look for stuff on Clang and OpenCL. Speculation on vmkit and SVA is less solidly grounded, but probably even more fun.

Is the universal binary on it's way out?

My gut feeling is that something even better than the current fat binaries is on the way in. Perhaps not in Snow Leopard, but surely in the release after. The essential piece, LLVM, is already under Leopard's OpenGL stack, and is almost certainly under OpenCL (and perhaps Grand Central Dispatch). LLVM is the real star of the show, and I'm surprised that it hasn't gotten one mention in this thread. The long-term implications are mind-boggling.

Expect to see "BC 0xC0DE" magic numbers in a future release. I'll bet my first born.

One little detail you overlooked is important to understanding what Apple might possibly do with this stuff.

Apple doesn't have much in the way of ARM code at all, to the extent that nearly all of their ARM code is generated by a compiler. Apple has C and Objective C code, and has LLVM sitting between the hardware and the Apple application source code. Apple can run on any hardware platform they like. They can support more than one hardware platform at almost negligible marginal cost. While the rest of the industry flails about, with their obsolete notions of "platform wars", Apple can simultaneously participate on the industry standards platform (or platforms as the case happens to be) and also invent a better platform, for one or many other product categories. Those can also overlap.

Apple is essentially platform agnostic, with respect to hardware.

what should be banned are those useless coders who think that a language should do everything for you, thus making you lazy and bloated like your code.

While I can sympathize, that's just uncalled for. There are good reasons for introducing higher-level constructs which handle the aspects of programming that humans are bad at (memory management for instance), thus freeing them to handle the aspects of programming that they're actually good at (algorithm design).

Anyone who thinks otherwise is honestly deluded. C/C++ have their place in some low-level systems, though I would argue that Ada is probably a better choice in almost every case, but its prevalence in so much high-level application software is just negligent IMO. Software written in C/C++ will always have vulnerabilities unless it's subject to costly security audits, which almost no one will do, or the C/C++ compiler itself injects code to prevent such attacks (as many research projects are currently attempting to do).

Even GCC, the only GNU project of consequence, is really not that important. If it went away tomorrow, LLVM and clang could take its place. It probably will anyway, eventually, since GCC is a maintenance nightmare from everything I've read and heard. In the end, the GPLv3 won't be what killed GCC, though it was definitely the straw that broke the camel's back and drove a bunch of people over to LLVM, thus increasing development on that project.

Even GCC, the only GNU project of consequence, is really not that important. If it went away tomorrow, LLVM and clang could take its place. It probably will anyway, eventually, since GCC is a maintenance nightmare from everything I've read and heard. In the end, the GPLv3 won't be what killed GCC, though it was definitely the straw that broke the camel's back and drove a bunch of people over to LLVM, thus increasing development on that project.

Also forgotten is http://llvm.org/ , the fastest target of the platforms supported by PyPy. It also supports native code on x86, x86_64, PPC, and PPC64. Static compiling is available on all of those and several others besides.

http://llvm.org/ProjectsWithLLVM/#adobe-hydra

Hydra is a new programming language based on LLVM: a BSD-like licensed open-source compiler framework for many platforms.

No, his system 'cheats'. Basically he created a large char array to act as the whole system RAM. Then, malloc just returns indices into that array.

However, you can achieve what you want in a much simpler way that doesn't involve relying on Java or JavaScript safety. Write an LLVM transformation pass that takes every MallocInst and replaces it with one that either a) returns the pointer + a size (called the fat pointer technique) or b) registers the pointer and size in a list on the side elsewhere then does the malloc. Then, the pass also modifies every LoadInst and StoreInst (and free?) to check the validity of the pointers before using them.

What's neat about this is that you can then statically compile the resulting program. There's no need for a VM to sit in between. If you're really lucky, LLVM will even be successful at optimizing away the safety checks on your load and store instructions.

No, his system 'cheats'. Basically he created a large char array to act as the whole system RAM. Then, malloc just returns indices into that array.

However, you can achieve what you want in a much simpler way that doesn't involve relying on Java or JavaScript safety. Write an LLVM transformation pass that takes every MallocInst and replaces it with one that either a) returns the pointer + a size (called the fat pointer technique) or b) registers the pointer and size in a list on the side elsewhere then does the malloc. Then, the pass also modifies every LoadInst and StoreInst (and free?) to check the validity of the pointers before using them.

What's neat about this is that you can then statically compile the resulting program. There's no need for a VM to sit in between. If you're really lucky, LLVM will even be successful at optimizing away the safety checks on your load and store instructions.

No, his system 'cheats'. Basically he created a large char array to act as the whole system RAM. Then, malloc just returns indices into that array.

However, you can achieve what you want in a much simpler way that doesn't involve relying on Java or JavaScript safety. Write an LLVM transformation pass that takes every MallocInst and replaces it with one that either a) returns the pointer + a size (called the fat pointer technique) or b) registers the pointer and size in a list on the side elsewhere then does the malloc. Then, the pass also modifies every LoadInst and StoreInst (and free?) to check the validity of the pointers before using them.

What's neat about this is that you can then statically compile the resulting program. There's no need for a VM to sit in between. If you're really lucky, LLVM will even be successful at optimizing away the safety checks on your load and store instructions.

No, his system 'cheats'. Basically he created a large char array to act as the whole system RAM. Then, malloc just returns indices into that array.

However, you can achieve what you want in a much simpler way that doesn't involve relying on Java or JavaScript safety. Write an LLVM transformation pass that takes every MallocInst and replaces it with one that either a) returns the pointer + a size (called the fat pointer technique) or b) registers the pointer and size in a list on the side elsewhere then does the malloc. Then, the pass also modifies every LoadInst and StoreInst (and free?) to check the validity of the pointers before using them.

What's neat about this is that you can then statically compile the resulting program. There's no need for a VM to sit in between. If you're really lucky, LLVM will even be successful at optimizing away the safety checks on your load and store instructions.

My understanding is that Apple would like to have tighter integration between their development tools, specifically XCode, the compiler and linker. They can avoid having separate parsing and tokenization in their text editor, have much improved contextual error information, and improve performance. GCC poses both architectural and legal obstacles to this kind of development for Apple right now.

There's a Google Tech Talk from Chris Lattner that talks about Clang features and benefits:
http://clang.llvm.org/clang_video-07-25-2007.html

LLVM has supported inline asm since release 1.7, and the support has steadily been getting better at each release, with major improvements in 1.8 and 1.9.

http://llvm.org/releases/1.7/docs/ReleaseNotes.html
http://llvm.org/releases/

The only problem with the x86 inline asm support in 2.2 is the lack of support for the x87 floating point stack in the inline asm register constraints. See "Known Problems" in the 2.2 release notes.

LLVM has supported inline asm since release 1.7, and the support has steadily been getting better at each release, with major improvements in 1.8 and 1.9.

http://llvm.org/releases/1.7/docs/ReleaseNotes.html
http://llvm.org/releases/

The only problem with the x86 inline asm support in 2.2 is the lack of support for the x87 floating point stack in the inline asm register constraints. See "Known Problems" in the 2.2 release notes.