Sorry, Matthew.  I can not find your message on 
https://bugs.ruby-lang.org/issues/12589.  So I am sending this message 
through email.

On 03/29/2017 04:36 PM, Matthew Gaudet wrote:
> 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 :)
>
Thank you.  I would not call it a secret. I wrote about it couple times 
publicly. But it was a quite development.  This is my first major update 
about the project.
>> 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 read your article.  It was helpful.  And I am agree with you about 
sharing the ideas.
> 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.
>

Yes, may be you are right about separating the project.  For me it is 
just one project.  I don't see MJIT development without RTL. I'll need a 
program analysis and RTL is more adequate approach for this than stack 
insns.

> 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.
>
Yes we should measure memory footprint too to compare different JITs.

MJIT code itself is currently very small about 40KB.   GCC code is 
pretty big about 20MB (LLVM library is even bigger) but code of multiple 
running instances of GCC (even hundred of them) will have the same 20MB 
in memory at least on Linux.

The data created in GCC is more important.  GCC is not monstrous. As any 
optimizing compiler, it works by passes (in GCC there are more 300 of 
them): a pass gets IR, allocates the pass data, transforms IR, and frees 
the data.  So the peak consumption is not big.  I'd say the peak 
consumption for typical ISEQ with the compiled environment would be 
about couple megabytes.

GCC developers really care about data consumption and compiler speed.    
There are some passes (GCSE and RA) which consume a lot of data 
(sometimes the data consumption is quadratic of IR size). Still GCC is 
every tunable and such behaviour can be avoided with particular options 
and parameters.  I suspect, other JIT implementations will have 
analogous memory footprint for the data if they do inlining.

> 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.
>
It would be interesting to know all reasons why rujit was abandoned.  I 
suspect it was more than just the data consumption.

You can not implement JIT without consuming additional memory.  May be 
for some MRI environments like Heroku the additional memory consumption 
can be critical. And for such environment it might be better not to use 
JIT at all.  Still there are other Ruby environments where people can 
spare memory consumption for faster code.
> > 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.
>
Thanks for the clarification.

I can also share my finding about Ruby OMR.  I found that Ruby OMR is 
one thread program.  So MRI waits for OMR to get a machine code and it 
hurts the performance.   I think the compilation should be done in 
parallel with code execution in the interpreter as for Graal or JVM.
>
>
> [1]: https://twitter.com/ChrisGSeaton/status/811303853488488448
> [2]: 
> https://developer.ibm.com/open/2017/03/01/ruby-omr-jit-compiler-whats-next/
>
>
> Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>


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