3 ms·

LLVM is "proper" back-end for code generation that produce native executable optimized for any platform. JVM execute bytecode in Java Virtual Machine. JVM abst

by Chyzwar 10y ago

LLVM is "proper" back-end for code generation that produce native executable optimized for any platform. JVM execute bytecode in Java Virtual Machine. JVM abstract your hardware and have specific runtime that needs to be present. LLVM is superior model because its avoid additional compilation and can in theory provide much better performance.

grzm 10y ago
You express very strong opinions about Clojure and the JVM in particular, in comparison to the LLVM. Would you mind sharing some particulars of your experience with the two and what domain you work in?
pron 10y ago
Actually, the JVM can in theory provide much better performance, because code is specialized as it runs. Statically compiled code must be produced to handle the worst-case usage. As for the runtime being present, it's more of a packaging issue. A language like Go has a runtime that's similar to Java's (except it doesn't JIT-compile), but it is statically linked with your binary. This can be done in Java, too. I must say that it doesn't seem like you're very knowledgeable when it comes to compilation techniques. LLVM and the JVM do make different tradeoffs, but they're not at all the ones you describe.
- paulddraper 10y ago
  > JVM can in theory provide much better performance, because code is specialized as it runs. Only better if you don't include the runtime compiling (start-up time).
  - pron 10y ago
    The JVM is usually used for long-running applications so the warmup (not start-up, which is 60ms) time doesn't matter. It's not a great choice for short-lived command-line apps.
    - paulddraper 10y ago
      The JVM is usually used for long-running application because the warmup is so slow. Were it not so slow, it would be used for things other than servers.
      - pron 10y ago
        Maybe, but most large, "serious" software is long-running anyway. There is interesting work on reducing warmup (because some banks doing HFT are willing to pay Oracle to do that), but there's not much interest. Not all niches of the software world are equally interesting, and besides, there are some incumbents that are hard to unseat in those smaller niches so it's questionable how much effort should be put into competing in niches that are either small, have well-entrenched incumbents, or both.

by Chyzwar 10y ago

grzm 10y ago

You express very strong opinions about Clojure and the JVM in particular, in comparison to the LLVM. Would you mind sharing some particulars of your experience with the two and what domain you work in?

pron 10y ago

Actually, the JVM can in theory provide much better performance, because code is specialized as it runs. Statically compiled code must be produced to handle the worst-case usage. As for the runtime being present, it's more of a packaging issue. A language like Go has a runtime that's similar to Java's (except it doesn't JIT-compile), but it is statically linked with your binary. This can be done in Java, too. I must say that it doesn't seem like you're very knowledgeable when it comes to compilation techniques. LLVM and the JVM do make different tradeoffs, but they're not at all the ones you describe.

paulddraper 10y ago
> JVM can in theory provide much better performance, because code is specialized as it runs. Only better if you don't include the runtime compiling (start-up time).
- pron 10y ago
  The JVM is usually used for long-running applications so the warmup (not start-up, which is 60ms) time doesn't matter. It's not a great choice for short-lived command-line apps.
  - paulddraper 10y ago
    The JVM is usually used for long-running application because the warmup is so slow. Were it not so slow, it would be used for things other than servers.
    - pron 10y ago
      Maybe, but most large, "serious" software is long-running anyway. There is interesting work on reducing warmup (because some banks doing HFT are willing to pay Oracle to do that), but there's not much interest. Not all niches of the software world are equally interesting, and besides, there are some incumbents that are hard to unseat in those smaller niches so it's questionable how much effort should be put into competing in niches that are either small, have well-entrenched incumbents, or both.