3 ms·
It wasn't a failure because they couldn't do it, they simply ran out of time as they only had a one year mandate and spent the majority of that time fixing bugs
by brettcannon 10y ago
It wasn't a failure because they couldn't do it, they simply ran out of time as they only had a one year mandate and spent the majority of that time fixing bugs in LLVM's JIT.
- gsnedders 10y agoIt's worthwhile to note that LLVM's JIT is now far more mature, and there's been substantial work on GC support. Back when Unladen Swallow was being worked on, I'm unaware of anything except OS X's OpenGL implementation using LLVM's JIT support—and that ultimately was very different code being JIT'd (they essentially just inline a sequence of interpreter states, so their source IR comes from Clang). Nowadays… I'm not even going to try listing even dynamically typed language VMs that use LLVM for JITing.
- sanxiyn 10y agoLLVM JIT is a lot better now, but it is also quite suboptimal. Even LLVM's fastest code generator is slow compared to other JITs. That's why Apple's JavaScript engine abandoned LLVM JIT: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler...
- gsnedders 10y agoIts compile-time performance is unquestionably its biggest problem for JITs nowadays. But there's a big difference between being so buggy it's virtually unusable and its performance being suboptimal. It's also worth pointing out that even "long-running" in JS terms is often considered "short-running" in more general JIT terms, so compile-time performance is even more critical in the JS case than elsewhere.