This looks pretty good to me. So basically if a __NOFRAME__ local variable is found inside a method then JRuby will make its enhancements?
Have you talked with the Rubinius or IronRuby guys about these ideas at all? I'm not really sure if these optimizations are implementation specific or not, but maybe clues could be added that more than just JRuby would understand. I think it may be more logical to allow users to define their own compiler > plugins, so that for example you could define your own __NOFRAME__ handler > that gets called at compile time. Could you explain this a little more? A compile plugin sounds a little scary to me. Joe On Mon, Apr 13, 2009 at 9:27 PM, Charles Oliver Nutter < [email protected]> wrote: > Joseph Athman wrote: > >> Maybe the annotations was a bad idea since I'm sure you wouldn't want to >> have to parse every comment in a system to look for some performance hints. >> I read your blog post about the different optimizations that can be done >> with Ruby and it looks like there are certain things that can be done with >> JRuby, but are not normally safe. I'm thinking as an developer I just want >> ways of marking a method (class?) as obeying some kind of a more strict Ruby >> code structure and then tell JRuby that it can make assumptions about my >> code that normally wouldn't be allowed. Could we do something like this? >> > ... > >> I'm thinking the allow_unsafe_optimizations method would be defined by >> JRuby's core and allow it to optimize it in normally unsafe ways. However >> this would also mean that if I wanted to run on MRI I would need to add some >> kind of no-op code to get this to work, but I think that would be easy >> enough. Just add: >> > ... > >> What I would be looking to do is just to find hot spots in my codebase >> that I could optimize for JRuby in a way that would not break its use in >> MRI. I'm just a little leary of anything special that would lock my code in >> to a particular implementation of Ruby. I know we complain pretty regularly >> about C based extensions, I'd rather not replicate the same issue by using a >> Java extension to get speed improvements unless absolutely necessary. I >> hope this is making sense. >> > > Ahh, ok, I understand what you mean. Yes, I have thought through a couple > ways, and one simple, compatible, low-impact way to add such pragmas might > be using local variables. Here's an example of one such pragma that actually > works right now in JRuby: > > __NOFRAME__ = true > > If this is encountered in a method body we will not allocate a call frame > for the method. Here's an example using fib(30): > > Normal: > ~/projects/jruby ➔ jruby bench_fib_recursive.rb > 0.377000 0.000000 0.377000 ( 0.331000) > 0.192000 0.000000 0.192000 ( 0.192000) > 0.206000 0.000000 0.206000 ( 0.206000) > 0.197000 0.000000 0.197000 ( 0.197000) > 0.203000 0.000000 0.203000 ( 0.203000) > > With __NOFRAME__ = true: > ~/projects/jruby ➔ jruby bench_fib_recursive.rb > 0.339000 0.000000 0.339000 ( 0.297000) > 0.149000 0.000000 0.149000 ( 0.149000) > 0.150000 0.000000 0.150000 ( 0.150000) > 0.150000 0.000000 0.150000 ( 0.150000) > 0.153000 0.000000 0.153000 ( 0.153000) > > The assertion you are making here is that you won't be using > backref/lastline methods, method visibility (def or public/private/etc), and > a few other things. In exchange, you get better performance > > Some optimizations like this we hope to bring to all users via static > inspection, but you get the general idea. > > In general I'm in favor of allowing pragmas that are noninvasive, but I'm > not sure all such cases can be done this way. I think it may be more logical > to allow users to define their own compiler plugins, so that for example you > could define your own __NOFRAME__ handler that gets called at compile time. > > - Charlie > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
