Bill Kelly wrote:
> But yes, it's harder to make a language like Ruby, which is highly
> dynamic at runtime, fast like C++ and Java, which are primarily
> statically compiled. The Smalltalk folks have reportedly done pretty
> well though, so there exists the possiblilty that Ruby may get
> substantially faster in the future. YARV is already making some
> headway.

My question is what does 1.9 exactly do with its "Inline (Method)
cache"[1]? Is there room for more improvement with a better JIT
compiler? How much would this scripts?
Thanks!
-R
[1] http://www.atdot.net/yarv/rc2006_sas...v_on_rails.pdf
--
Posted via http://www.ruby-forum.com/.

On May 12, 7:54am, Roger Pack <rogerpack2...@gmail.com> wrote:
> Bill Kelly wrote:
> > But yes, it's harder to make a language like Ruby, which is highly
> > dynamic at runtime, fast like C++ and Java, which are primarily
> > statically compiled. The Smalltalk folks have reportedly done pretty
> > well though, so there exists the possiblilty that Ruby may get
> > substantially faster in the future. YARV is already making some
> > headway.
>
> My question is what does 1.9 exactly do with its "Inline (Method)
> cache"[1]? Is there room for more improvement with a better JIT
> compiler? How much would this scripts?

There's a huge amount of room for improvement in the still. I haven't
seen any of the Ruby implementations even try to apply more
sophisticated
VM/JIT techniques such as tracing and polymorphic inline caches
properly.

There's nothing inherently in Ruby preventing "near C" performance (at
least within the same magnitude, but probably a lot closer), though
there
are lots of things that make it a lot of work to get there (the level
of dynamism, certainly).

Even thought Ruby programs in theory are extremely dynamic, most paths
through a program will be heavily dominated by the same types over and
over, and that can be exploited to massively reduce overhead, with
some
pretty cheap checks to shunt execution over to a fallback if certain
assumptions don't hold etc.

It's a question of when, not if, we see far faster Ruby
implementations
than the current range of VMs.

Vidar

Vidar Hokstad wrote:
> On May 12, 7:54 am, Roger Pack <rogerpack2...@gmail.com> wrote:
>> Bill Kelly wrote:
>>> But yes, it's harder to make a language like Ruby, which is highly
>>> dynamic at runtime, fast like C++ and Java, which are primarily
>>> statically compiled. The Smalltalk folks have reportedly done pretty
>>> well though, so there exists the possiblilty that Ruby may get
>>> substantially faster in the future. YARV is already making some
>>> headway.
>> My question is what does 1.9 exactly do with its "Inline (Method)
>> cache"[1]? Is there room for more improvement with a better JIT
>> compiler? How much would this scripts?
>
> There's a huge amount of room for improvement in the still. I haven't
> seen any of the Ruby implementations even try to apply more
> sophisticated
> VM/JIT techniques such as tracing and polymorphic inline caches
> properly.

I've experimented with PICs in JRuby, and for most tests I ran they did
not very much. Granted, there's an unfortunate lack of nontrivial
polymorphic benchmarks in the wild, so it's possible a good PIC would
more on real apps.

What does make a huge difference for JRuby is eliminating some of the
extra overhead related to rarely-used Ruby features. For example, the
difference between a normal run and a run that eliminates an unnecessary
frame object, uses fast dispatch for math operations, and eliminates
some thread checkpointing:

~/NetBeansProjects/jruby âž” jruby -J-server
test/bench/bench_fib_recursive.rb
0.746000 0.000000 0.746000 ( 0.746000)
0.371000 0.000000 0.371000 ( 0.370000)
0.357000 0.000000 0.357000 ( 0.357000)
0.357000 0.000000 0.357000 ( 0.357000)
0.358000 0.000000 0.358000 ( 0.357000)
~/NetBeansProjects/jruby âž” jruby -J-server
-J-Djruby.compile.fastest=true test/bench/bench_fib_recursive.rb
0.960000 0.000000 0.960000 ( 0.959000)
0.243000 0.000000 0.243000 ( 0.243000)
0.238000 0.000000 0.238000 ( 0.238000)
0.237000 0.000000 0.237000 ( 0.237000)
0.235000 0.000000 0.235000 ( 0.235000)

And Ruby 1.9:

~/NetBeansProjects/jruby âž” ../ruby1.9/ruby -I ../ruby1.9/lib
test/bench/bench_fib_recursive.rb
0.400000 0.010000 0.410000 ( 0.412421)
0.400000 0.000000 0.400000 ( 0.407236)
0.400000 0.000000 0.400000 ( 0.415222)
0.400000 0.010000 0.410000 ( 0.417042)
0.400000 0.000000 0.400000 ( 0.452934)

So yes, there's definitely room to improve all the implementations...

- Charlie

Charles Oliver Nutter wrote:
> What does make a huge difference for JRuby is eliminating some of the
> extra overhead related to rarely-used Ruby features. For example, the
> difference between a normal run and a run that eliminates an unnecessary
> frame object, uses fast dispatch for math operations, and eliminates
> some thread checkpointing:

Maybe something is possible along the lines of

vm_optimized :no_frame_pointer, :fast_math, :no_thread_checkpointing do
# some code that should run very fast
end


Thanks for your work
-R
--
Posted via http://www.ruby-forum.com/.

Roger Pack wrote:
> Maybe something is possible along the lines of
>
> vm_optimized :no_frame_pointer, :fast_math, :no_thread_checkpointing do
> # some code that should run very fast
> end
>
>
> Thanks for your work
> -R

Yeah, I'm looking into those possibilities, trying to find a
nonintrusive way to introduce compiler pragmas that we could use for
implementing parts of JRuby in Ruby code (or that others could use). For
example, something like this (a bogus name...I don't want to reveal any
pragmas yet):

def foo
____NO_FRAMING = true
end

- Charlie

> Yeah, I'm looking into those possibilities, trying to find a
> nonintrusive way to introduce compiler pragmas that we could use for
> implementing parts of JRuby in Ruby code (or that others could use). For
> example, something like this (a bogus name...I don't want to reveal any
> pragmas yet):
>
> def foo
> ____NO_FRAMING = true
> end

One option that YARV could use is compiler definitions.
Programatically would seem easier on the user.
-R
--
Posted via http://www.ruby-forum.com/.

On 01.06.2008 03:14, Charles Oliver Nutter wrote:
> Roger Pack wrote:
>> Maybe something is possible along the lines of
>>
>> vm_optimized :no_frame_pointer, :fast_math, :no_thread_checkpointing do
>> # some code that should run very fast
>> end
>>
>>
>> Thanks for your work
>> -R
>
> Yeah, I'm looking into those possibilities, trying to find a
> nonintrusive way to introduce compiler pragmas that we could use for
> implementing parts of JRuby in Ruby code (or that others could use). For
> example, something like this (a bogus name...I don't want to reveal any
> pragmas yet):
>
> def foo
> ____NO_FRAMING = true
> end

That's an interesting idea, but I'd rather separate Ruby code from
platform specific options. So I'd prefer command line arguments to the
engine (as you presented before) or a smart mechanism to store switches
externally (e.g. .rc file). Ideally there would even be a mechanism
that finds optimal switches automatically, but I guess that would be
really hard. :-)

Kind regards

robert

Roger Pack wrote:
> Charles Oliver Nutter wrote:
>> What does make a huge difference for JRuby is eliminating some of the
>> extra overhead related to rarely-used Ruby features. For example, the
>> difference between a normal run and a run that eliminates an unnecessary
>> frame object, uses fast dispatch for math operations, and eliminates
>> some thread checkpointing:
>
> Maybe something is possible along the lines of
>
> vm_optimized :no_frame_pointer, :fast_math, :no_thread_checkpointing do
> # some code that should run very fast
> end

A flag is problematic for a couple reasons:

- Most of the optimizations I'm trying to specify are not compatible
with everything in Ruby; when enabled they'll limit available features
to a subset that doesn't incur as much runtime overhead (and this is
overhead both JRuby and MRI contend with).
- For the cases where there are optimizations that can be applied
globally...we just spin a new release and apply them globally. There's
not really a need to hold back on such things if they don't break Ruby.

Ideally, we'd be able to apply these optimizations everywhere they'll be
safe automatically, but that's a very hard problem with Ruby's dynamic
nature. So I see these as more a "programmer promise" that they won't
use certain higher-overhead features in exchange for better performance.
It's not something I'd see a lot of people using for general apps, but
it might be useful when building JRuby internal or core framework code.

I'm open to all thoughts on this though. There's lots and lots of things
we can optimize by incrementally shutting down particular features. And
I think it's a reasonable choice to offer people...if you want something
faster and are willing to give up a little, it should be your choice.
And yes, I fully appreciate the compatibility aspect of this...so it's
definitely not intended for the uninitiated and probably not for general
use.

- Charlie