5 ms·

According to the Unladen Swallow's team [1], LLVM's "just-in-time infrastructure was relatively untested and buggy" when they started working with it. So, I thi

by alxv 17y ago

According to the Unladen Swallow's team [1], LLVM's "just-in-time infrastructure was relatively untested and buggy" when they started working with it. So, I think not using LLVM was a pragmatic decision. In addition, debugging C++ code is much easier than dealing with intricacies of dynamically generated machine code. [1]: http://www.python.org/dev/peps/pep-3146/#performance-retrospective http://www.python.org/dev/peps/pep-3146/#performance-retrosp...

kingkilr 17y ago
Yes, but it's not now. Unladen Swallow isn't exactly alone in blazing this trail, Rubinius is using LLVM as well.
- sjs 17y ago
  Also MacRuby.
- ighost 17y ago
  Also Lua: http://code.google.com/p/llvm-lua/ http://code.google.com/p/llvm-lua/
wmf 17y ago
HipHop is a static compiler, though. That part of LLVM seems to have been heavily exercised by GCC and Clang.
malkia 17y ago
Well maybe The Facebook guys were not only after speed optimization, but memory too. No matter how great the LLVM JIT is it probably uses some memory to compile the code, and this way wasting some amount. Static compilation would not waste this amount. I'm actually proponent of JIT, over static compilation, but only for my little pet projects. I don't know much about WEB, but for games development, static compilation is sometimes the only way to go (or script interpretation). Sometimes there is just not enough memory, and sometimes it's restricted (hell, it so much resticted that you can't change the VTABLE at runtime in C++ class even if you want to)