
LLVM 3.0 Released - wisesage5001
http://llvm.org/releases/3.0/docs/ReleaseNotes.html
======
stephth
As an avid reader of HN I'm surprised it's the first time I hear of many of
these many (LLVM backed) projects. Some that stood out to me:

\- The VMKit project is an implementation of a Java Virtual Machine (Java VM
or JVM) that uses LLVM for static and just-in-time compilation.

Am I reading this right? A faster Java that doesn't require a virtual machine?
Does this mean faster Java, Scala, Clojure, or even Ruby, and deployed
anywhere that LLVM can build for (which means pretty much _everywhere_ )?
Sounds too good to be true.

\- LanguageKit is a framework for implementing dynamic languages sharing an
object model with Objective-C.

\- Eero is a fully header-and-binary-compatible dialect of Objective-C 2.0

Has anyone tried Eero? It looks interesting (and seems to be compatible with
Objective-C code): <http://eerolanguage.org/from-objective-c-to-eero>. One
thing I didn't get from the documentation is does Eero still require header
files?

~~~
wmf
Don't assume that VMKit is faster than OpenJDK; LLVM is powerful but it's not
magic awesome sauce (see Unladen Swallow). Also see GCJ.

~~~
stephth
_Precompilation: by compiling ahead of time a small subset of Java's core
library, the startup performance have been highly optimized to the point that
running a 'Hello World' program takes less than 30 milliseconds._

Sounds faster than the Java I know.

~~~
mikedouglas
... on startup. That doesn't mean it outcompetes Hotspot over the lifetime of
the application.

~~~
Hemospectrum
That startup time is probably the biggest turnoff for people seeking to write
lightweight scripts in JVM languages. If your script's runtime is 100ms after
a 5 second startup, it doesn't particularly matter if the machine code version
runs at half speed.

~~~
lemming
Of course, precompilation is usually a big turnoff for those same people.

~~~
lukesandberg
but it is precompilation of the core library, not the whole app, so presumably
it could be done only once for the system and cached somewhere. (maybe like
.Nets global assembly cache, which caches jitted dlls)

------
sixtofour
Off topic suggestion: When you have a home page for a project, if the name is
an acronym, you should _spell out the acronym_ in the first paragraph, if not
the first sentence or the title.

From <http://llvm.org/> I looked at Overview, Features, Documentation and FAQ,
and did not find the definition of LLVM. I ultimately had to go to Wikipedia.

~~~
exDM69
edit: LLVM once stood for "Low level virtual machine", but that is no longer
the meaning. The early name comes from Chris Lattner's research paper
describing an "ideal machine language", an intermediate language for compilers
which is a little like an Assembly -type language for a virtual machine with
infinite registers.

The first sentence on the front page of llvm.org pretty much sums it up: "The
LLVM Project is a collection of modular and reusable compiler and toolchain
technologies."

It may not be the clearest LLVM description out there, but that's pretty much
what it is. If the description had more detail, it would not fit in one
sentence.

The hard thing about describing LLVM is that it's a huge complicated project
in a domain that's outside even many professional programmers' domain.

I tend to say that LLVM is (to me) a "compiler infrastructure", because I use
it to build compiler back ends. However, LLVM is so much more than that, as
the project includes loosely coupled tools ranging from complete compilers
(clang) to debuggers (lldb) to byte code and binary format introspection
utilities (llvm's binutils counterparts). So a "compiler infrastructure" or
any other dumbed down explanation wouldn't do it justice. That's why the first
sentence on the front page is actually pretty good.

~~~
eliben
LLVM actually still is a virtual machine, since it contains mechanisms for
executing code written in LLVM IR. There are two execution paths - an
interpreter and a JIT compiler. I guess this makes it a VM after all, although
the acronym is no longer descriptive because the VM part is a tiny fraction of
what LLVM includes and can do. As you said, its super-tool for creating
compilers, especially compiler back-ends.

~~~
barrkel
The LLVM interpreter is less than ideal as an actual interpreter rather than
something for doing constant folding and that kind of thing; the instructions
are too low-level for it to be really fast. For example, bit widths of
integers are represented in the abstraction; that adds overhead to even the
simplest of arithmetic operations.

~~~
eliben
I don't think the interpreter was intended to be really fast. It's pretty good
for debugging and platform-independent execution. For speed there's the JIT.

