Hi all
The ruby currently deals with only ints with one bit to differentiate it
with object pointers. I am not sure how much improvements can be made in
terms of speed if we deal all the primitives but I think that can be
substantial for mathematical programs.
Not holding minds on implementation problems in Ruby, does any one has ideas
on possible ways to deal with all the primitives like floats etc in a
dynamic language?
rolo
rolo wrote:
Hi all
Moin!
The ruby currently deals with only ints with one bit to differentiate it
with object pointers. I am not sure how much improvements can be made in
terms of speed if we deal all the primitives but I think that can be
substantial for mathematical programs.
What you’re basically proposing is compile-time method dispatch.
It means that one would no longer be able to redefine methods of
built-in classes or add singleton-methods to Objects which is quite a
limitation.
It could however make sense to implement this as an optional optimization.
Regards,
Florian Gross
“rolo” rohitlodha@hotwireindia.com wrote in message news:ACEPLIKLBKEMDDIELPKICEBNCFAA.rohitlodha@hotwireindia.com…
Hi all
The ruby currently deals with only ints with one bit to differentiate it
with object pointers. I am not sure how much improvements can be made in
terms of speed if we deal all the primitives but I think that can be
substantial for mathematical programs.Not holding minds on implementation problems in Ruby, does any one has ideas
on possible ways to deal with all the primitives like floats etc in a
dynamic language?
In general, compile-time type knowledge is mutually exclusive with the
kind of dynamic typing ruby provides. But we can write critical
functions via:
(1) RubyInline rubyinline | software projects | by ryan davis
(2) a C extension.
(3) a shared library (using ruby/dl to call lib functions from ruby)
Look at it this way: if you are doing serious number crunching, for
example, do you really want to be using a dynamic language for that
task in the first place?
The good news is that (1), (2), and (3) are all rather simple to do.
C extensions in ruby are surprisingly easy due to the gc and uniform
treatment of types (e.g. compare with python’s C API or perl XS).
So to finally answer your question – adding compile-time type
optimizations and/or other immediate values to ruby seems unnecessary
to me, given the ease of (1)-(3). You may get significant speedup,
but native code is much faster. And if you were really looking for
speedup, you would probably do one of (1)-(3) anyway.
“Florian Gross” flgr@ccan.de schrieb im Newsbeitrag
news:2h4b3nF8qcjnU1@uni-berlin.de…
rolo wrote:
Hi all
Moin!
The ruby currently deals with only ints with one bit to differentiate it
with object pointers. I am not sure how much improvements can be made in
terms of speed if we deal all the primitives but I think that can be
substantial for mathematical programs.What you’re basically proposing is compile-time method dispatch.
It means that one would no longer be able to redefine methods of
built-in classes or add singleton-methods to Objects which is quite a
limitation.It could however make sense to implement this as an optional optimization.
I vote against this: doing Java for quite some time every once in a while I
curse the language designers for including primitives. It doesn’t look like
a big deal on first sight, but there’s a lot of places where this makes
things more complicated than necessary. Ruby intends to be simple and
concise and having two types of things (aka “primitives” and “objects”)
would make it overly complicated.
For those interested in mathematical programming, there are far better tools
to use - I mean all those math packages that are optimized for number
crunching, symbolic math and nice plots. I think Ruby should not optimize
for this too much.
Maybe integrating some math lib as extension would be a good idea.
Kind regards
robert