On Thursday, September 1, 2016 at 3:24:21 PM UTC, [email protected] 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 <https://github.com/Ken-B/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.
