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” [email protected] 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 N. wrote:
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 …
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
On 8/8/06, M. Edward (Ed) Borasky [email protected] 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 S. wrote:
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 .
On Tue, 8 Aug 2006, Jan S. 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
On Wed, 9 Aug 2006, M. Edward (Ed) Borasky wrote:
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
On 8/8/06, M. Edward (Ed) Borasky [email protected] 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 Wed, 9 Aug 2006, Jan S. wrote:
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
On 8/8/06, [email protected] [email protected] wrote:
On Tue, 8 Aug 2006, Jan S. 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.