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" <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://chneukirchen.org
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 ...
fyi - narray can go back and forth between gsl::matrix - combined with ruby's
dsl capabilities this can be a powerful combination.
cheers.
-a
路路路
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 ...
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama
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.
路路路
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,
Jan Svitok 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>
路路路
On 8/8/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
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.
路路路
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>
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
路路路
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!
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama
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@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 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.
路路路
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...
you directly in GiNaC - or directly as in using ruby/dl sans glue code?
regards.
-a
路路路
On Wed, 9 Aug 2006, M. Edward (Ed) Borasky wrote:
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.
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama
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
路路路
On Wed, 9 Aug 2006, Jan Svitok wrote:
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.
--
to foster inner awareness, introspection, and reasoning is more efficient than
meditation and prayer.
- h.h. the 14th dali lama