From: Vladimir Makarov Date: 2017-03-29T23:08:18-04:00 Subject: [ruby-core:80495] Re: [Ruby trunk Feature#12589] VM performance improvement proposal 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: > Unsubscribe: