[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Profiling Ruby Matrix operations

M. Edward (Ed) Borasky

8/6/2006 10:17:00 PM

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/?r...

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.
11 Answers

Christian Neukirchen

8/7/2006 8:49:00 PM

0

"M. Edward (Ed) Borasky" <znmeb@cesmail.net> 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?

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneuk...

M. Edward (Ed) Borasky

8/8/2006 4:48:00 AM

0

Christian Neukirchen wrote:
> "M. Edward (Ed) Borasky" <znmeb@cesmail.net> 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 ... :)

Ara.T.Howard

8/8/2006 5:01:00 AM

0

Jano Svitok

8/8/2006 8:34:00 AM

0

On 8/8/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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.

M. Edward (Ed) Borasky

8/8/2006 1:43:00 PM

0

Jan Svitok wrote:
> On 8/8/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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>

Jano Svitok

8/8/2006 2:33:00 PM

0

On 8/8/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> Jan Svitok wrote:
> > On 8/8/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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.

Ara.T.Howard

8/8/2006 2:48:00 PM

0

M. Edward (Ed) Borasky

8/8/2006 3:02:00 PM

0

ara.t.howard@noaa.gov 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.

Ara.T.Howard

8/8/2006 3:16:00 PM

0

Jano Svitok

8/8/2006 3:24:00 PM

0

On 8/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> 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.