I wonder if it would be possible to run other languages such as rust, d, or ante, that use llvm, on this? Specifically interested in how languages with gc like d or nim will fare.
Rust runs. Look at the PR queue.
Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
11–18 of 18 posts
Re: Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
#12A few potential use cases: - Compile once, run anywhere for low-level languages like C++. With limitations, of course. - More debugging capabilities. Maybe it could be used for dynamic analysis. Theoretically it should be possible to change code at runtime. - Something like Valgrind? Valgrind is really complex and doesn't run on Windows at all. It seems like you could make a portable substitute with this. - Maybe Gra…
I believe that one compelling use case is to avoid the overhead of cross language boundaries (ie JNI) when the native code is compiled to bitcode and run with Sulong.
Previous Graal show offs had Ruby running C extensions by implementing a Graal JIT for x86. I imagine LLVM a nicer level of abstraction to intercept at
This seems to imply only implementing a C JIT, so my memory may be wrong: http://chrisseaton.com/rubytruffle/cext
Truffleruby seems to be using Sulong now: https://github.com/oracle/truffleruby/commit/f16a52934437a96...
Re: Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
#13A few potential use cases: - Compile once, run anywhere for low-level languages like C++. With limitations, of course. - More debugging capabilities. Maybe it could be used for dynamic analysis. Theoretically it should be possible to change code at runtime. - Something like Valgrind? Valgrind is really complex and doesn't run on Windows at all. It seems like you could make a portable substitute with this. - Maybe Gra…
LLVM IR usually is platform dependant. Especially so when generated by clang etc..
Re: Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
#14How much faster/slower is it than aot code? I'm disapointed to see no benchmarks.
It's in the papers. About 20% slower. The main use case seems to be speed up dynamic languages (ruby, python, javascript, R), and Sulong is used to handle the C extensions, so that the optimizations can be performed across the language boundaries. Unboxing and inlining mostly in the hot paths. Makes sense. Plus more memory safety than C/C++/Fortran.
Sorry I couldn't find the paper in github page. Can you give a link?
Re: Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
#15Earlier quoted context omitted.
It's in the papers. About 20% slower. The main use case seems to be speed up dynamic languages (ruby, python, javascript, R), and Sulong is used to handle the C extensions, so that the optimizations can be performed across the language boundaries. Unboxing and inlining mostly in the hot paths. Makes sense. Plus more memory safety than C/C++/Fortran.
Sorry I couldn't find the paper in github page. Can you give a link?
There's a docs dir. https://github.com/graalvm/sulong/blob/master/docs/PUBLICATI...
Re: Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
#16A few potential use cases: - Compile once, run anywhere for low-level languages like C++. With limitations, of course. - More debugging capabilities. Maybe it could be used for dynamic analysis. Theoretically it should be possible to change code at runtime. - Something like Valgrind? Valgrind is really complex and doesn't run on Windows at all. It seems like you could make a portable substitute with this. - Maybe Gra…
LLVM IR usually is platform dependant. Especially so when generated by clang etc..
Obviously, you can't just run it through vanilla Clang and call it a day. However, you can do something like PNaCl where you treat the runtime environment as its own platform separate from the rest of the world with its own ABI. I'm sure some languages are more or less impacted as well, for C and C++ the problem is obvious because platforms vary so widely.
Re: Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
#17> Compiling without optimizations is not recommended with Sulong. In particular, cross-language interoperability with Java or another Truffle language will not work when the bitcode is compiled without optimizations.
This is very weird. How can (lack of) optimizations possibly interfere with things like calling conventions? Whatever they're doing, it smells of fragile.
Re: Sulong – A high-performance LLVM bitcode interpreter built on the GraalVM
#18On a related note, Sulong is what makes Nokogiri and OpenSSL possible on TruffleRuby. This only happened two weeks ago, may be it is the reason why Sulong is posted again to HN.
I am trying hard not to get overly excited, let see some real world benchmarks once Truffle is ready to run Real World Rails.