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

Discussion in 'Ruby' started by Erwin Moller, May 6, 2008.

  1. Erwin Moller

    Erwin Moller Guest

    Why doesn't the inventor design a better approach to avoid this
    problem?
    Erwin Moller, May 6, 2008
    #1
    1. Advertising

  2. Erwin Moller

    ara.t.howard Guest

    Re: Ruby has to be interpreted line by line in runtime, does this affect Ruby's execution efficiency badly?

    On May 5, 2008, at 10:35 PM, Erwin Moller wrote:
    > Why doesn't the inventor design a better approach to avoid this
    > problem?



    cat a.rb | ssh remote ruby



    a @ http://codeforpeople.com/
    --
    we can deny everything, except that we have the possibility of being
    better. simply reflect on that.
    h.h. the 14th dalai lama
    ara.t.howard, May 6, 2008
    #2
    1. Advertising

  3. Re: Ruby has to be interpreted line by line in runtime, does this affect Ruby's execution efficiency badly?

    > Ruby has to be interpreted line by line in runtime

    This is not true.

    robert
    Robert Klemme, May 6, 2008
    #3
  4. Re: Ruby has to be interpreted line by line in runtime, does this affect Ruby's execution efficiency badly?

    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".)
    Paul Stickney, May 6, 2008
    #4
  5. Erwin Moller

    Ron Fox Guest

    Re: Ruby has to be interpreted line by line in runtime, does thisaffect Ruby's execution efficiency badly?

    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

    Erwin Moller wrote:
    > Why doesn't the inventor design a better approach to avoid this
    > problem?
    Ron Fox, May 8, 2008
    #5
  6. Re: Ruby has to be interpreted line by line in runtime, does thisaffect Ruby's execution efficiency badly?

    On May 8, 1:27 pm, Ron Fox <> wrote:
    > 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
    Vidar Hokstad, May 8, 2008
    #6
  7. Erwin Moller

    Robert Dober Guest

    Re: Ruby has to be interpreted line by line in runtime, does this affect Ruby's execution efficiency badly?

    On Thu, May 8, 2008 at 2:55 PM, Vidar Hokstad <> wrote:
    > On May 8, 1:27 pm, Ron Fox <> 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
    --
    http://ruby-smalltalk.blogspot.com/

    ---
    Whereof one cannot speak, thereof one must be silent.
    Ludwig Wittgenstein
    Robert Dober, May 8, 2008
    #7
  8. Re: Ruby has to be interpreted line by line in runtime, does this affect Ruby's execution efficiency badly?

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

    Robert Dober wrote:
    | On Thu, May 8, 2008 at 2:55 PM, Vidar Hokstad
    <> wrote:
    |> On May 8, 1:27 pm, Ron Fox <> 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...

    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-----
    Phillip Gawlowski, May 8, 2008
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Rudolf
    Replies:
    6
    Views:
    1,248
    Mark Thornton
    Jan 14, 2004
  2. Minkoo Seo
    Replies:
    1
    Views:
    123
    Yukihiro Matsumoto
    Mar 11, 2006
  3. Kaldrenon
    Replies:
    7
    Views:
    102
    Jano Svitok
    Jul 26, 2007
  4. Erwin Moller
    Replies:
    11
    Views:
    186
    Eleanor McHugh
    May 2, 2008
  5. Erwin Moller
    Replies:
    9
    Views:
    117
    Clifford Heath
    May 8, 2008
Loading...

Share This Page