LLVM Compile (llvm-gcc, llvm-g++)
-----------------------
real 2m22.703s
user 2m6.522s
sys 0m13.459s
GCC Compile (gcc, g++)
------------------------
real 3m52.327s
user 3m32.908s
sys 0m17.426s
I have a 2 GHz C2D, 4GB Macbook running 10.6.4. The versions of LLVM
and GCC are 2.6 and 4.2 respectively. For those who have not already
tried, and have the developer tools installed, you just need to
execute "export CC=llvm-gcc CXX=llvm-g++" in the shell before running
configure and make.
A minute and a half is a pretty decent improvement. The 2.6 version of
the LLVM compiler still uses gcc in the front end for parsing and LLVM
in the back end. As of version 2.7 the front end can handle C++ so you
can drop the gcc front end as well. When it comes in the next release
of Apple's dev tools you can substitute "clang" for both "llvm-gcc"
and "llvm-g++". I expect further reduction in compilation time with
version 2.7.
For those compiling on Linux/BSD/etc you can at least download the
latest version from llvm.org. I am not sure if they publish pre-built
debian packages, rpms or what have you.
I have not yet compared the performance of builds of node using the
two different compilers. I would expect very little difference in most
node applications as they are most likely IO-bound. Perhaps if you
have a CPU-bound application you might see some gains with an
LLVM-built node. Two layers of JIT are better than one :)
Have fun.
-MT
--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
Speed is not its only advantage: I've used clang++ for development of
node-expat because g++ error messages kept me riddled. That may
unfortunately not be the case with llvm-g++.
> For those compiling on Linux/BSD/etc you can at least download the
> latest version from llvm.org. I am not sure if they publish pre-built
> debian packages, rpms or what have you.
http://packages.debian.org/lenny/llvm-gcc-4.2
> [...] Two layers of JIT are better than one :)
LLVM is not a JIT compiler, or did I miss anything?
How true. The static analysis capabilities and the error messages
produced by clang are far superior to those of gcc. Now that version
2.7 of clang/llvm supports C++ I am betting that you can expect to
have similar benefits when compiling C++.
>> For those compiling on Linux/BSD/etc you can at least download the
>> latest version from llvm.org. I am not sure if they publish pre-built
>> debian packages, rpms or what have you.
>
> http://packages.debian.org/lenny/llvm-gcc-4.2
>
>> [...] Two layers of JIT are better than one :)
>
> LLVM is not a JIT compiler, or did I miss anything?
>
LLVM definitely has JIT capabilities. By default llvm compiles your
code all the way to a native executable but you can instruct it to
stop at the intermediate/bytecode level. You can then let llvm JIT
this output at runtime using the llvm runtime libraries. A good basic
example of this can be found here:
http://llvm.org/docs/GettingStarted.html#tutorial4
I guess I was just poking fun at the idea of using JIT on top of JIT
(js/v8) more than anything else. I am not sure a project like Node
would even benefit from runtime optimization of its native parts but
it might be interesting to see. It seems like the LLVM runtime
optimization library would actually be something one could use to
implement the JIT in V8.
-MT