Profiling Ruby Matrix operations

Discussion in 'Ruby' started by M. Edward (Ed) Borasky, Aug 6, 2006.

  1. A while back, I wondered if anyone had ever profiled the Ruby
    interpreter itself with "gprof". I don't recall if anyone ever answered,
    so I ran a short test to see what would happen. I'll spare you the
    details, since I put everything up on my CVS repository on RubyForge.

    http://rubyforge.org/cgi-bin/viewvc.cgi/MatrixBenchmark/?root=cougar

    The benchmark code itself is "MatrixBenchmark.rb" ... this is where my
    desire for "m[i, j] = -1" came from. :) I ran this using stock Ruby
    1.8.4 source recompiled with the "-g -pg" options and did the standard
    "gprof" call graph, plus an annotated source. The call graph/profile is
    "profile.txt" and the annotated *Ruby* source is "source.txt". That last
    one is a bit large, so don't download it unless you're intensely curious. :)

    This is the sort of code I'd *like* to write in pure Ruby, rather than
    having to call a C library for efficiency. The matrix I generated is
    quite ill-conditioned. It's quite possible that a "standard" floating
    point numerical determinant or matrix inversion routine would choke on
    it, while the combination of "matrix", "mathn" and "rational" I used had
    no problem with it. In short, I'm willing to pay for rational arithmetic
    and correct results, but not for an inefficient interpreter. :) So if
    someone is going to rewrite Matrix in C, they need to do the underlying
    arithmetic too.

    If I get a chance, I'm going to try this out with YARV (assuming YARV
    will run it). Also, bear in mind that the "-g" compile turns off all
    optimization and the profiling introduces some overhead itself. A
    regular Ruby interpreter would run the actual benchmark faster.
    M. Edward (Ed) Borasky, Aug 6, 2006
    #1
    1. Advertising

  2. Christian Neukirchen wrote:
    > "M. Edward (Ed) Borasky" <> writes:
    >
    >
    >> This is the sort of code I'd *like* to write in pure Ruby, rather than
    >> having to call a C library for efficiency. The matrix I generated is
    >> quite ill-conditioned. It's quite possible that a "standard" floating
    >> point numerical determinant or matrix inversion routine would choke on
    >> it, while the combination of "matrix", "mathn" and "rational" I used
    >> had no problem with it. In short, I'm willing to pay for rational
    >> arithmetic and correct results, but not for an inefficient
    >> interpreter. :) So if someone is going to rewrite Matrix in C, they
    >> need to do the underlying arithmetic too.
    >>

    >
    > Tried NArray?
    >
    >

    Not yet ... right now I'm chasing something I think is much better.
    Apparently there is a SWIG wrapper for GiNaC that generates Python
    bindings for it. It can't be very difficult to port that to Ruby, and
    GiNaC will do everything I want to do and is pretty efficient C++ code.
    So that's the rabbit I'm currently chasing ... I definitely need mixed
    symbolic and numeric computation capabilities and high-precision
    arithmetic. GiNaC does that with "CLN". Stay tuned ... :)
    M. Edward (Ed) Borasky, Aug 8, 2006
    #2
    1. Advertising

  3. M. Edward (Ed) Borasky

    Guest

    On Tue, 8 Aug 2006, M. Edward (Ed) Borasky wrote:

    > Not yet ... right now I'm chasing something I think is much better.
    > Apparently there is a SWIG wrapper for GiNaC that generates Python bindings
    > for it. It can't be very difficult to port that to Ruby, and GiNaC will do
    > everything I want to do and is pretty efficient C++ code. So that's the
    > rabbit I'm currently chasing ... I definitely need mixed symbolic and numeric
    > computation capabilities and high-precision arithmetic. GiNaC does that with
    > "CLN". Stay tuned ... :)


    fyi - narray can go back and forth between gsl::matrix - combined with ruby's
    dsl capabilities this can be a powerful combination.

    cheers.

    -a
    --
    to foster inner awareness, introspection, and reasoning is more efficient than
    meditation and prayer.
    - h.h. the 14th dali lama
    , Aug 8, 2006
    #3
  4. M. Edward (Ed) Borasky

    Jan Svitok Guest

    On 8/8/06, M. Edward (Ed) Borasky <> wrote:
    > Apparently there is a SWIG wrapper for GiNaC that generates Python
    > bindings for it. It can't be very difficult to port that to Ruby,


    Ruby support in SWIG is not as complete as Python's, mainly regarding
    stl and wide strings. So the ease of porting will depend on whether
    you encounter any deficiency or not. Anyway, chances are that you
    won't. In that case porting should mean just changing swig command
    line...

    J.
    Jan Svitok, Aug 8, 2006
    #4
  5. Jan Svitok wrote:
    > On 8/8/06, M. Edward (Ed) Borasky <> wrote:
    >> Apparently there is a SWIG wrapper for GiNaC that generates Python
    >> bindings for it. It can't be very difficult to port that to Ruby,

    >
    > Ruby support in SWIG is not as complete as Python's, mainly regarding
    > stl and wide strings. So the ease of porting will depend on whether
    > you encounter any deficiency or not. Anyway, chances are that you
    > won't. In that case porting should mean just changing swig command
    > line...
    >
    > J.
    >
    >

    I've downloaded their code and I'm looking at it now. I'm rather
    hampered by not knowing any Python. Meanwhile, are you talking about the
    *latest* SWIG? I've got 1.3.29, which includes support for "pike",
    "mono", "lua" and "ocaml" in addition to the more common languages. When
    I was looking through the SWIG documents, it looked like they had a
    fairly complete section on the Ruby interface. ANd it doesn't have to
    work on Windows . :)

    <ducking>
    M. Edward (Ed) Borasky, Aug 8, 2006
    #5
  6. M. Edward (Ed) Borasky

    Jan Svitok Guest

    On 8/8/06, M. Edward (Ed) Borasky <> wrote:
    > Jan Svitok wrote:
    > > On 8/8/06, M. Edward (Ed) Borasky <> wrote:
    > >> Apparently there is a SWIG wrapper for GiNaC that generates Python
    > >> bindings for it. It can't be very difficult to port that to Ruby,

    > >
    > > Ruby support in SWIG is not as complete as Python's, mainly regarding
    > > stl and wide strings. So the ease of porting will depend on whether
    > > you encounter any deficiency or not. Anyway, chances are that you
    > > won't. In that case porting should mean just changing swig command
    > > line...
    > >
    > > J.
    > >
    > >

    > I've downloaded their code and I'm looking at it now. I'm rather
    > hampered by not knowing any Python. Meanwhile, are you talking about the
    > *latest* SWIG? I've got 1.3.29, which includes support for "pike",
    > "mono", "lua" and "ocaml" in addition to the more common languages. When
    > I was looking through the SWIG documents, it looked like they had a
    > fairly complete section on the Ruby interface. ANd it doesn't have to
    > work on Windows . :)
    >
    > <ducking>
    >


    what I meant is (SWIG 1.3.29):

    in ruby there are following std_*:

    std_common.i
    std_deque.i
    std_except.i
    std_map.i
    std_pair.i
    std_string.i
    std_vector.i

    in python there are these additional files:

    std_alloc.i
    std_basic_string.i
    std_carray.i
    std_char_traits.i
    std_complex.i
    std_container.i
    std_ios.i
    std_iostream.i
    std_list.i
    std_multimap.i
    std_multiset.i
    std_set.i
    std_sstream.i
    std_streambuf.i
    std_vectora.i
    std_wios.i
    std_wiostream.i
    std_wsstream.i
    std_wstreambuf.i
    std_wstring.i

    So if you need e. g. std::list or std::set, you have to experiment. (I
    somehow managed to get list working, and my colleague got working
    wstring)

    It has to be noted though, that python's support seems to be the most
    complete, and fortunately for us, ruby is supported pretty good as
    well. It saved me a lot of work... the swig generated .cpp file has 5
    MB!

    J.
    Jan Svitok, Aug 8, 2006
    #6
  7. M. Edward (Ed) Borasky

    Guest

    On Tue, 8 Aug 2006, Jan Svitok wrote:

    > It has to be noted though, that python's support seems to be the most
    > complete, and fortunately for us, ruby is supported pretty good as well. It
    > saved me a lot of work... the swig generated .cpp file has 5 MB!


    the problem with that being that math and science should repeatable and
    verifiable - neither of which are likely to be true when a 5mb auto-generated
    file is in the mix...

    2 cts.

    -a
    --
    to foster inner awareness, introspection, and reasoning is more efficient than
    meditation and prayer.
    - h.h. the 14th dali lama
    , Aug 8, 2006
    #7
  8. wrote:
    > On Tue, 8 Aug 2006, Jan Svitok wrote:
    >
    >> It has to be noted though, that python's support seems to be the most
    >> complete, and fortunately for us, ruby is supported pretty good as
    >> well. It
    >> saved me a lot of work... the swig generated .cpp file has 5 MB!

    >
    > the problem with that being that math and science should repeatable and
    > verifiable - neither of which are likely to be true when a 5mb
    > auto-generated
    > file is in the mix...
    >
    > 2 cts.
    >
    > -a

    I'm actually of the opinion that SWIG may not be necessary to interface
    GiNaC with Ruby ... it might be easier to do it directly.
    M. Edward (Ed) Borasky, Aug 8, 2006
    #8
  9. M. Edward (Ed) Borasky

    Guest

    On Wed, 9 Aug 2006, M. Edward (Ed) Borasky wrote:

    > wrote:
    >> On Tue, 8 Aug 2006, Jan Svitok wrote:
    >>
    >>> It has to be noted though, that python's support seems to be the most
    >>> complete, and fortunately for us, ruby is supported pretty good as well.
    >>> It
    >>> saved me a lot of work... the swig generated .cpp file has 5 MB!

    >>
    >> the problem with that being that math and science should repeatable and
    >> verifiable - neither of which are likely to be true when a 5mb
    >> auto-generated
    >> file is in the mix...
    >>
    >> 2 cts.
    >>
    >> -a


    > I'm actually of the opinion that SWIG may not be necessary to interface
    > GiNaC with Ruby ... it might be easier to do it directly.


    you directly in GiNaC - or directly as in using ruby/dl sans glue code?

    regards.

    -a
    --
    to foster inner awareness, introspection, and reasoning is more efficient than
    meditation and prayer.
    - h.h. the 14th dali lama
    , Aug 8, 2006
    #9
  10. M. Edward (Ed) Borasky

    Jan Svitok Guest

    On 8/8/06, <> wrote:
    > On Tue, 8 Aug 2006, Jan Svitok wrote:
    >
    > > It has to be noted though, that python's support seems to be the most
    > > complete, and fortunately for us, ruby is supported pretty good as well. It
    > > saved me a lot of work... the swig generated .cpp file has 5 MB!

    >
    > the problem with that being that math and science should repeatable and
    > verifiable - neither of which are likely to be true when a 5mb auto-generated
    > file is in the mix...


    I'm not telling there's any math or science involved *in my case*. In
    fact, it's a lot of small classes/structs, that's why the file gets so
    large. What I'm saying is that using SWIG saved me a lot of work, and
    helped me to make the extension quite quickly, without dipping into
    ruby's source. And much of the code is repeating so the verification
    wouldn't be so hard, I suppose.

    J.
    Jan Svitok, Aug 8, 2006
    #10
  11. M. Edward (Ed) Borasky

    Guest

    On Wed, 9 Aug 2006, Jan Svitok wrote:

    > On 8/8/06, <> wrote:
    >> On Tue, 8 Aug 2006, Jan Svitok wrote:
    >>
    >> > It has to be noted though, that python's support seems to be the most
    >> > complete, and fortunately for us, ruby is supported pretty good as well.

    >> It
    >> > saved me a lot of work... the swig generated .cpp file has 5 MB!

    >>
    >> the problem with that being that math and science should repeatable and
    >> verifiable - neither of which are likely to be true when a 5mb
    >> auto-generated
    >> file is in the mix...

    >
    > I'm not telling there's any math or science involved *in my case*. In
    > fact, it's a lot of small classes/structs, that's why the file gets so
    > large. What I'm saying is that using SWIG saved me a lot of work, and
    > helped me to make the extension quite quickly, without dipping into
    > ruby's source. And much of the code is repeating so the verification
    > wouldn't be so hard, I suppose.


    don't get me wrong - i love swig. i'm just pointing out that, to really
    verify, one (another programmer) would have to code two or more impls and test
    them against each other (assume we're lacking ground truth) and auto-generated
    code is a hindrence in the respect. just pointing that out - i've rushed into
    things like this before with complex image processing algorithms and, due to
    the internal complexity, not been able to verify correctness which, in the
    end, caused me to simply drop them on the floor even though they 'looked' good
    - it's an important consideration when coding math and/or science.

    kind regards.

    -a
    --
    to foster inner awareness, introspection, and reasoning is more efficient than
    meditation and prayer.
    - h.h. the 14th dali lama
    , Aug 8, 2006
    #11
    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. Jesus M. Salvo Jr.
    Replies:
    2
    Views:
    4,020
    robert
    Feb 11, 2006
  2. M. Fernandez

    Java Matrix Operations

    M. Fernandez, Mar 2, 2006, in forum: Java
    Replies:
    5
    Views:
    1,041
    ~Glynne
    Mar 17, 2006
  3. friends

    Sparse Matrix operations

    friends, Sep 17, 2005, in forum: C Programming
    Replies:
    0
    Views:
    488
    friends
    Sep 17, 2005
  4. Terry Reedy
    Replies:
    0
    Views:
    542
    Terry Reedy
    Apr 2, 2009
  5. Robert Kern
    Replies:
    0
    Views:
    581
    Robert Kern
    Apr 2, 2009
Loading...

Share This Page