[ruby-core:80491] Re: [Ruby trunk Feature#12589] VM performance improvement proposal

Hi Vladimir,

First and foremost, let me join in with others in thanking you for
opening up your experimentation. I suspect that you'd be one of the
'secret' Ruby JITs Chris Seaton was talking about [1]. One more secret
JIT to go :)

> I believe that implementing JIT in MRI should be more evolutional to be successful.
 >
 > [...]
 >
> Another thing is to avoid a work duplication.

So far, evolutionary approaches have heavily dominated the work we've
done with Ruby+OMR as well. I also recently wrote an article about what
needs to happen with Ruby+OMR [2]. One thing in that article I want to
call out is my belief that those of us working on JIT compilers for MRI
have many opportunities to share ideas, implementation and features. My 
hope is that we can all keep each other in mind when working on things.

I haven't had a huge amount of time to go through your patches, though,
I have gone through some of it. One comment I would make is that it 
seems you've got two very separate projects here: One is a re-design of
YARV as an RTL machine, and the other is MJIT, your JIT that takes
advantage of the structure of the RTL instructions. In my opinion, it is
worth considering these two projects separately. My (offhand) guess
would be that I could adapt Ruby+OMR to consume the RTL instructions in
a couple of weeks, and other (secret) JITs may be in a similar place.

Your approach to MJIT certainly seems interesting. I was quite impressed 
with the compile times you mentioned -- when I was first thinking about 
your approach I had thought they would be quite a bit higher.

One question I have (and this is largely for the Ruby community to
answer) is about how to measure impacts from JITs on non-performance
metrics. In this case for example, should MJIT's dynamic memory
footprint be computed as the total of the Ruby process and GCC, or
can we maybe ignore the GCC costs -- at a cost to compilation time you
could do the compiles elsewhere, and you have a clear path to
Ahead-of-Time compilation in your mind.

My recollection is that one of the reasons rujit was abandoned was
because its memory footprint was considered unacceptable, but, I don't
don't know how that conclusion was drawn.

 > At least my investigation of Oracle Graal and IBM OMR was very helpful.

Glad we could help. One small note: The project is called Eclipse OMR, 
not IBM OMR. While IBM is the largest contributor right now, we're
trying to build a community around the project, and it is run through 
the Eclipse foundation.



[1]: https://twitter.com/ChrisGSeaton/status/811303853488488448
[2]: 
https://developer.ibm.com/open/2017/03/01/ruby-omr-jit-compiler-whats-next/


Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>