Just a silly thought but now with the interlanguage backend, can you run Gambit on the JVM?
As in, make the JS/Python/PHP/Ruby/etc. backend compile to JIT code or Java code, and then run a full Gambit environment within the JVM, at least enough for having "eval" and the typical runtime with IO?
This would be the only way to run Gambit code "natively" in Java as in using Java's heap and garbage collection for object representation etc. right?
Would there be any constraints with respect to multithreading?
Thanks
Afficher les réponses par date
Alternatively, given the Ruby backend, you might try http://jruby.org/.
Evan
Right.
Also I would guess implementing a Java sourcecode backend would be very easy now, as a compliment to the others.
I wonder what about a JIT backend through the same Gambit backend facility.
2015-11-21 7:47 GMT+08:00 Evan Hanson evhan@foldling.org:
Alternatively, given the Ruby backend, you might try http://jruby.org/.
Evan
It is already there!
gsc -c -target java foo.scm
Performance however is atrocious… something like two or three orders of magnitude slower than with the C backend. We’re currently looking into the issue and our current guess is that the Java JIT compiler is misbehaving.
The supported target languages are c, js, python, ruby and java. Currently the ruby target is experiencing problems, but probably an easy fix when I look into it (it was working fine before some recent refactoring).
Marc
On Nov 21, 2015, at 12:15 AM, Adam adam.mlmb@gmail.com wrote:
Right.
Also I would guess implementing a Java sourcecode backend would be very easy now, as a compliment to the others.
I wonder what about a JIT backend through the same Gambit backend facility.
2015-11-21 7:47 GMT+08:00 Evan Hanson evhan@foldling.org: Alternatively, given the Ruby backend, you might try http://jruby.org/.
Evan
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
2015-11-21 21:46 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca:
It is already there!
gsc -c -target java foo.scm
Fantastic!!
Performance however is atrocious… something like two or three orders of magnitude slower than with the C backend. We’re currently looking into the issue and our current guess is that the Java JIT compiler is misbehaving.
Interesting - so basically the output JS is running like 5x slower than the C backend, and the output Java runs 10-100x slower, how can that ever be??
The code output is pretty straightforward isn't it, and the fact that it works atop the Java objects *should* mean that performance should be on the *higher end* of the scale as Java-internal optimizations can be applied all over, no??
The supported target languages are c, js, python, ruby and java. Currently
the ruby target is experiencing problems, but probably an easy fix when I look into it (it was working fine before some recent refactoring).
Marc