4 ms·

If they could pull off easy integration with the C and C++ world that would be an absolute killer feature. They are basically trying to make my new dream langu

If they could pull off easy integration with the C and C++ world that would be an absolute killer feature. They are basically trying to make my new dream language. The only thing I am worried about is compile time. It seems many projects using LLVM have trouble with that. See Julia with its LLVM JIT, though they did manage to improve it somewhat. I guess it is simply to early to tell, lets hope for the best.

stingraycharles 4y ago
I’d say it can’t possibly be much worse than with GraalVM, but maybe my expectations are too high. I’m very interested in runtime performance as well, though, and how it compares to vanilla JVM-based Clojure.
Jeaye 4y ago
Compile times will be slower than Clojure's, for sure. That also means run-time speed will be affected, due to JIT compilation time. This will not affect AOT compiled run-time speed, though. I don't have numbers yet, but you're right that compiling C++ with LLVM could be much faster. :)
eigenspace 4y ago
LLVM is not a particularly slow compiler (though it is progressively getting slower). There are faster compilers out there, but it’s fine. The reason julia has so much compiler latency is not that we have a slow compiler, it’s that we compile a LOT of code. Julia is very very (runtime) performance oriented, and so we do everything we can to speed up execution time. This means that we have very aggressive code specialization, inlining, and unrolling heuristics, and people take heavy advantage of them. It’s a very normal thing in julia to try and write very high level generic code that performs like low level optimized code by taking advantage of versions code generation techniques. In addition to all of that, we end up recompiling a lot of code that was already compiled before because we have very strict heuristics to make sure that when a method body is altered, all downstream dependants of that method get invalidated and must be recompiled, and sometimes the heuristics overeager. Julia compile times have been dropping rapidly over the past couple years mostly because people have put a lot of work into avoiding invalidations, and being smarter about how compile-time code generation is approached. Almost none of that improvement has to do with LLVM, it all happens well before we hand things off to LLVM.

stingraycharles 4y ago

I’d say it can’t possibly be much worse than with GraalVM, but maybe my expectations are too high. I’m very interested in runtime performance as well, though, and how it compares to vanilla JVM-based Clojure.

Jeaye 4y ago

Compile times will be slower than Clojure's, for sure. That also means run-time speed will be affected, due to JIT compilation time. This will not affect AOT compiled run-time speed, though. I don't have numbers yet, but you're right that compiling C++ with LLVM could be much faster. :)

eigenspace 4y ago

LLVM is not a particularly slow compiler (though it is progressively getting slower). There are faster compilers out there, but it’s fine. The reason julia has so much compiler latency is not that we have a slow compiler, it’s that we compile a LOT of code. Julia is very very (runtime) performance oriented, and so we do everything we can to speed up execution time. This means that we have very aggressive code specialization, inlining, and unrolling heuristics, and people take heavy advantage of them. It’s a very normal thing in julia to try and write very high level generic code that performs like low level optimized code by taking advantage of versions code generation techniques. In addition to all of that, we end up recompiling a lot of code that was already compiled before because we have very strict heuristics to make sure that when a method body is altered, all downstream dependants of that method get invalidated and must be recompiled, and sometimes the heuristics overeager. Julia compile times have been dropping rapidly over the past couple years mostly because people have put a lot of work into avoiding invalidations, and being smarter about how compile-time code generation is approached. Almost none of that improvement has to do with LLVM, it all happens well before we hand things off to LLVM.