JVMLS 2015 – Multi-Language Runtime [video]
youtube.com
JVMLS 2015 – Multi-Language Runtime [video]
1–10 of 11 posts
Re: JVMLS 2015 – Multi-Language Runtime [video]
#2magaudet and I are from IBM and are happy to answer any questions.
tl;dr: IBM is breaking apart its JVM runtime technology to allow easy reuse and integration of its GC, JIT and Tooling into other languages. This has been proven with a JIT + GC + Diagnostics enabled version of Ruby (MRI) and Python (CPython)
Re: JVMLS 2015 – Multi-Language Runtime [video]
#3magaudet and I are from IBM and are happy to answer any questions. tl;dr: IBM is breaking apart its JVM runtime technology to allow easy reuse and integration of its GC, JIT and Tooling into other languages. This has been proven with a JIT + GC + Diagnostics enabled version of Ruby (MRI) and Python (CPython)
(And working on the Ruby JIT)
Re: JVMLS 2015 – Multi-Language Runtime [video]
#4magaudet and I are from IBM and are happy to answer any questions. tl;dr: IBM is breaking apart its JVM runtime technology to allow easy reuse and integration of its GC, JIT and Tooling into other languages. This has been proven with a JIT + GC + Diagnostics enabled version of Ruby (MRI) and Python (CPython)
I'm excited to see it, just waiting for some public code.
Re: JVMLS 2015 – Multi-Language Runtime [video]
#5magaudet and I are from IBM and are happy to answer any questions. tl;dr: IBM is breaking apart its JVM runtime technology to allow easy reuse and integration of its GC, JIT and Tooling into other languages. This has been proven with a JIT + GC + Diagnostics enabled version of Ruby (MRI) and Python (CPython)
How does your approach for factoring out compiler components compares with the PyPy meta-tracing approach?
Re: JVMLS 2015 – Multi-Language Runtime [video]
#6magaudet and I are from IBM and are happy to answer any questions. tl;dr: IBM is breaking apart its JVM runtime technology to allow easy reuse and integration of its GC, JIT and Tooling into other languages. This has been proven with a JIT + GC + Diagnostics enabled version of Ruby (MRI) and Python (CPython)
How does your approach for factoring out compiler components compares with the PyPy meta-tracing approach?
Our approach allows us to integrate with the existing runtimes, enhancing them, rather than having a new implementation. The PyPy approach is capable of much bigger gains, but we can integrate directly into the existing language community, along with all extensions.
Re: JVMLS 2015 – Multi-Language Runtime [video]
#7magaudet and I are from IBM and are happy to answer any questions. tl;dr: IBM is breaking apart its JVM runtime technology to allow easy reuse and integration of its GC, JIT and Tooling into other languages. This has been proven with a JIT + GC + Diagnostics enabled version of Ruby (MRI) and Python (CPython)
(And working on the Ruby JIT)
This looks like great work! Will there be a paper?
Why did you decide to show results from the synthetic benchmarks in bench9000, when there are 43 kernels from real compute-intensive libraries that are in-use in production (the PSD.rb and Chunky PNG benchmarks)?
Working on JRuby+Truffle I found that I could actually better optimise those benchmarks compared to the synthetic ones. The more complex code provides more opportunities to make big gains in performance compared to the simple code in the synthetic benchmarks.
Re: JVMLS 2015 – Multi-Language Runtime [video]
#8Earlier quoted context omitted.
(And working on the Ruby JIT)
This looks like great work! Will there be a paper? Why did you decide to show results from the synthetic benchmarks in bench9000, when there are 43 kernels from real compute-intensive libraries that are in-use in production (the PSD.rb and Chunky PNG benchmarks)? Working on JRuby+Truffle I found that I could actually better optimise those benchmarks compared to the synthetic ones. The more complex code provides more…
We presented early perf numbers from the classic subset which we felt had well known benchmarks. We wanted to present an good overall view of what we can do right now as opposed to biasing towards only the best running benchmarks. There was also the matter of presentation, its a bit easier to present a chart of 9 versus 43.
The team is interested in working on a paper, once the hard work is closer to being done.
Re: JVMLS 2015 – Multi-Language Runtime [video]
#9Earlier quoted context omitted.
(And working on the Ruby JIT)
This looks like great work! Will there be a paper? Why did you decide to show results from the synthetic benchmarks in bench9000, when there are 43 kernels from real compute-intensive libraries that are in-use in production (the PSD.rb and Chunky PNG benchmarks)? Working on JRuby+Truffle I found that I could actually better optimise those benchmarks compared to the synthetic ones. The more complex code provides more…
(BTW: Count me as a very happy user of Bench9k. It's been a very appreciated tool here. I'm hoping to contribute some of our harness customizations back when I have the time to clean up the commits a little).
Re: JVMLS 2015 – Multi-Language Runtime [video]
#10magaudet and I are from IBM and are happy to answer any questions. tl;dr: IBM is breaking apart its JVM runtime technology to allow easy reuse and integration of its GC, JIT and Tooling into other languages. This has been proven with a JIT + GC + Diagnostics enabled version of Ruby (MRI) and Python (CPython)
Congrats on the public announce of your 'secret' project! When do you release the code publicly? It would be great to be able to hack on it again.