FYI: Second transpiler to Julia(?), from Ruby, and benchmarks

[Páll Haraldsson]

I have no relation to this..

https://github.com/remore/julializer

[may not work to transpile Ruby on Rails to Julia - yet, there is an old package RoR that allows it to work with Julia though.]


Interesting benchmarks here ("virtual_module" is transpiled, but "Julia 0.4.6 not, only to compare, and [can be] a little slower than Python..):

https://github.com/remore/virtual_module


Saw at:

https://www.reddit.com/r/Julia/comments/5049pq/a_fresh_approach_to_numerical_computing_with_ruby/

[not really about to discuss here much. Fortran to Julia was first, though.]

--
Palli.

[Chris Rackauckas]

That's a good showing for Julia for the larger matrices? However, for smaller matrices it's a large constant time. Is it including startup/compilation time? Did they not "run it twice"?

[Páll Haraldsson]

On Monday, August 29, 2016 at 6:42:08 PM UTC, Chris Rackauckas wrote:

That's a good showing for Julia for the larger matrices? However, for smaller matrices it's a large constant time. Is it including startup/compilation time? Did they not "run it twice"?

1. I guess they must include startup time (and for JRuby..), not always unfair.., 2. So no.. they could for the benchmarks, while I'm not sure about it ideal for the transpiler (didn't look into it much).
 

On Monday, August 29, 2016 at 8:57:32 AM UTC-7, Páll Haraldsson wrote:

I have no relation to this..

https://github.com/remore/julializer

"But there are very many differences between Ruby and Julia which I have no idea how to fix as of now. For example:

• Julia supports only dec, bin and hex format but in Ruby the decimal system is much powerful.(#to_s(num) and #to_i(num) are supported)
• Julia doesn't have Class concept(there is workaround though) but Ruby does
• Julia does not have a "null" value but Ruby does
  • For example in Ruby [1,2,3].slice!(4) will return null but in julia there is no nil therefore this raises causes error.
  • Current workaround for this is, do not write this way, instead you need to check boundary by yourself.
• And many more gaps to be solved
  • e.g.) In Julia typemax() and typemin() returns Inf but in Ruby Float::MAX, Float::MIN have specific value"

A. I like you Julia doesn't have "null" (not strictly true, at least for C API..) to not have Hoare's self-admitted billion dollar mistake. Not sure thought, how best to help that project..

B. About Classes and

https://en.wikipedia.org/wiki/Composition_over_inheritance

that is I guess best, but maybe not to helpful for that project.. Should that be enough, to compile to that, or any other ideas?

C. I'm sure Julia has as good decimal support as possible already, with two different packages. I'm not sure what's in Ruby (so can't comment on that code), I guess the maker of the project is not aware, only of what is in Base.

 

[may not work to transpile Ruby on Rails to Julia - yet, there is an old package RoR that allows it to work with Julia though.]

That is https://github.com/Ken-B/RoR_julia_eg

that uses ZMQ.jl (better for IPC)?

[Steven G. Johnson]

On Monday, August 29, 2016 at 11:57:32 AM UTC-4, Páll Haraldsson wrote:

Interesting benchmarks here ("virtual_module" is transpiled, but "Julia 0.4.6 not, only to compare, and [can be] a little slower than Python..):

An accurate transpiler from Ruby or Python to Julia is pretty much guaranteed not to give any performance improvements, because it will be limited by the semantics of the source language.    (If it were possible to take advantage of Julia's performance in a transpiler, it would be possible to just write a direct-to-machine compiler for the original language.)   And in practice it will probably be slower than the source language because Julia is not as heavily optimized for interpreting those semantics.

[k...@swd.cc]

The creator of virtual_module and ruby2julia transpiler here, just dropped in to see what's going on now. Thank you for your interest.

> Is it including startup/compilation time? Did they not "run it twice"?

Yes, it includes startup/compilation time.(I'm not sure if I understand "runt it twice" meaning properly though)

> B. About Classes and
> https://en.wikipedia.org/wiki/Composition_over_inheritance
> that is I guess best, but maybe not to helpful for that project.. Should that be enough, to compile to that, or any other ideas?

This idea will work as well. Still thinking what's the best, but it's possible anyway.

> C. I'm sure Julia has as good decimal support as possible already, with two different packages. I'm not sure what's in Ruby (so can't comment on that code), I guess the maker of the project is not aware, only of what is in Base.

Thanks to your comment, I have found the solution. Just use base(x, y) then any conversion could be done. Thank you.

> That is https://github.com/Ken-B/RoR_julia_eg
> that uses ZMQ.jl (better for IPC)?

ZMQ sounds promising in order to add more concurrency to virtual_module.

> And in practice it will probably be slower than the source language because Julia is not as heavily optimized for interpreting those semantics.

True. And my experiment is to gain performance improvements in exchange for giving up completeness of accuracy of Ruby syntax. The project goal is something like "gain BIG performance improvement with more than 90% Ruby Syntax coverage", though not sure yet if I can make this happen. Anyways thank you for your comment.

[Páll Haraldsson]

On Thursday, September 1, 2016 at 3:24:21 PM UTC, k...@swd.cc wrote:

The creator of virtual_module and ruby2julia transpiler here, just dropped in to see what's going on now. Thank you for your interest.

> Is it including startup/compilation time? Did they not "run it twice"?

Yes, it includes startup/compilation time.(I'm not sure if I understand "runt it twice" meaning properly though)

The first time you run Julia code, it's slower as then you include compile time. See: http://docs.julialang.org/en/latest/manual/performance-tips/

> That is https://github.com/Ken-B/RoR_julia_eg
> that uses ZMQ.jl (better for IPC)?

ZMQ sounds promising in order to add more concurrency to virtual_module.

>> And in practice it will probably be slower than the source language because Julia is not as heavily optimized for interpreting those semantics.

>True. And my experiment is to gain performance improvements in exchange for giving up completeness of accuracy of Ruby syntax. The project goal is something like "gain BIG performance improvement with more than 90% Ruby Syntax coverage", though not sure yet if I can make this happen. Anyways thank you for your comment.

Julia interop (not transpiling), e.g. RoR_julia_eg helps to get speed. Transpiling would help to migrate code and/or if you are willing to modify the transpiled code, to get more speed than Ruby. As explained by Steven (that makes PyCall.jl, with tighter integration than already done for Ruby or any other dynamic language), you shouldn't get speedup, but that depends on how slow the implementation of Ruby is.. It seems you are not gaining from Julia, the *language* per se, only the BLAS functions that are actually written in Fortran (could have been fast though in Julia), so you're gaining from a library that could (in theory) be used directly from Ruby.

--
Palli.

[Yichao Yu]

This might be doable. Although be aware that 90% of syntax could mean <10% of non-toy code, which might be good enough as a starting point is the goal is to port code to julia but won't if the intent is to run the code in the original language.