Ruby has to be interpreted line by line in runtime, does this affectRuby's execution efficiency badl

R

Robert Klemme

Ruby has to be interpreted line by line in runtime

This is not true.

robert
 
P

Paul Stickney

Most advanced "scripted" languages (Ruby included) are parsed into
ASTs and then excuted.
This is unlike say, MIRC-Script or BASH, which *are* executed line-by-line.
Now, I'm not arguing that Ruby is fast, by any means, just that it
isn't run in a simplistic line-by-line parse-execute style.
(Of course I'm talking about .rb files, not IRB, which is, well,
rather "interactive".)
 
R

Ron Fox

Interpreters have advantages and disadvantages.
Interpreted languages can implement dynamic features that can be
very difficult to implement in compiled languages. Interpreted
languages tend to be slower than compiled languages however.

I think that what you may see in the future for Ruby, if it does
not exist yet, is some sort of internal byte code representation of
the parsed lines and a one-time just-in-time parser that will
remove a lot of the line by line parse overhead.

This seems to be the standard evolution of scripted languages.

RF
 
V

Vidar Hokstad

Interpreters have advantages and disadvantages.
Interpreted languages can implement dynamic features that can be
very difficult to implement in compiled languages.  Interpreted
languages tend to be slower than compiled languages however.

Ruby _is_ particularly bad in this respect though. Unfortunately a lot
of this
is tied to what makes Ruby pleasant to use.

For example, a native compiler for Ruby can't sanely generate all the
classes
at compile time and reason about them, which is the normal approach
for more
static languages.

One thing is that new classes can be made available by loading more
code at
runtime, that's not hard. What is hard is dealing with the fact that
there
is no clearly delineated execution stages for Ruby - code can execute
from the
very first line of the script has been parsed conceptually, including
_inside_
class definitions, and that code can mutate the classes being defined
or that
already has been defined, and can have side effects.

A lot of efficiency of compilers for native languages comes from that.
In C++,
for example, a compiler can safely inline methods if the method isn't
declared
virtual, or if it's declared virtual but the compiler can decisively
find the right
method, which it often can.

It can also do things like hoist vtable lookups out of loops, because
the class won't change at runtime, whereas in Ruby, every iteration
through a
loop could potentially change the entire class hierarchy.

These things aren't impossible to overcome, and I'm confident that
near C
level performance is _possible_ for Ruby (at the worst case cost of
almost
completely re-generating code for large parts of the app if you do
something nasty,
like evaling code that re-opens core classes), but it's not easy.

Even something "trivial" like compactly packing an object into the
smallest
amount of memory is not easy in Ruby, since you have no definitive way
of
knowing the number of instance variables at "compile time" for all
legal
programs, as new instance variables can be set at runtime. Worst case
here
to get memory efficiency is to modify all live objects in the system.

And a lot of it could have been made easier without sacrificing much.
Some small
restrictions on what is allowed at "compile time" for example, and a
clear
delineation of what would be executed at "compile time" vs. "runtime"
would make
a lot of optimizations far easier.

A cleanup of introspection so that a compiler could reasonably decide
not to support
the textual versions of eval (which effectively requires linking with
a full
interpreter or compiler) without breaking almost every Ruby script in
existence
(yes, I'm exaggerating) would also do wonders.

There are many things like that, which comes out of designing Ruby
without even
thinking about the implications for compilation.

That's ok, but it does mean that Ruby is one of the least suitable
languages for
compilation I've used, and achieving good performance will take a lot
of extra
effort, and achieving great performance will be damn hard. That said,
I use Ruby
for almost everything I do these days - only very rarely does the
performance of
the interpreter make much difference for me.

Vidar
 
R

Robert Dober

On May 8, 1:27 pm, Ron Fox <[email protected]> wrote:
Ruby _is_ particularly bad in this respect though. Unfortunately a lot
of this
is tied to what makes Ruby pleasant to use.

I am not that sure about this, maybe we might call Ruby challenging
rather than bad and we will see Ruby implementations being quite fast
in the next of couple of years, I am quite confident that YARV and
JRuby will be quite fast but I do not count out the other
implementations as Rubinus or Iron Ruby...

Only time will tell however ;)
Robert
 
P

Phillip Gawlowski

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Dober wrote:
| On Thu, May 8, 2008 at 2:55 PM, Vidar Hokstad
|
|> Ruby _is_ particularly bad in this respect though. Unfortunately a lot
|> of this
|> is tied to what makes Ruby pleasant to use.
|
| I am not that sure about this, maybe we might call Ruby challenging
| rather than bad and we will see Ruby implementations being quite fast
| in the next of couple of years, I am quite confident that YARV and
| JRuby will be quite fast but I do not count out the other
| implementations as Rubinus or Iron Ruby...

JRuby already beats MRI in a lot of cases, and it isn't even fully
optimized yet. And it offers JIT compilation, so after a warm up phase,
Ruby should be snappy (for large values of 'snappy').

I expect that we see similar results with IronRuby and, eventually, YARV.

Dunno about Rubinius, though. That might go through some extra effort,
as they implement the core lib in Ruby (the VM's in C, AFAIK).

- --
Phillip Gawlowski
Twitter: twitter.com/cynicalryan
Blog: http://justarubyist.blogspot.com

Youth is a period of missed opportunities without the glory of knowing what
~ was missed.
~ -- Cyril Connolly, "Journal and Memoir" 1983
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgjF50ACgkQbtAgaoJTgL9P0wCfQZkGGCm8sjBbvPvcAnp8taEc
Y/sAniqYcyoeiH0U5/y8fc6YAh8AxF0z
=LdEU
-----END PGP SIGNATURE-----
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top