I think that, in the long run, it would be nice to have ruco (or whatever
the Ruby equivalent of psyco would be called) anyway -- so, if you're
going to go to the effort of writing code intended to lead to runtime
optimization, you might want to consider just doing it "right" in the
first place.
On the other hand, I can see potential benefits of having a (preferably
two-way) translator between Ruby and Python for a lot of common-case
code, regardless of whether it ever gets used for Ruby psyco support. As
such, again, if you're intent on doing it that way I'd say get involved
in a Ruby-Python/Python-Ruby "compiler" and do *that* right, then
eventually use it as the basis for psyco runtime optimization of Ruby
code if nobody has gotten around to writing ruco-or-whatever by then.
Of course, I'm not really sold on the idea that automating translation
between Ruby and Python (especially the Ruby->Python part) would be
notably easier than compiling Ruby to C. Ruby has capabilities that the
Python core developers deliberately eschew, after all, because of the
whole "the way we do it is the *right* way" design aesthetic in Python
circles. If you start opening core classes, metaprogramming, or working
with complex callbacks (or, God forbid, actual lexical closures) in your
Ruby, I think your Ruby->Python translator is going to start puking blood
all over your ultra-high thread count sheets and simultaneously soil its
britches.
I suppose I could be mistaken, though. I don't actually know much about
Ruby and Python internals.
Note: My signature block is selected randomly by a script I wrote (in
Ruby, natch) many moons ago. I did not select it specifically to
illustrate any points about the subject at hand. My "random" signature
script, on the other hand, very well might have selected it to make a
point, for all I know.
···
On Sat, Dec 27, 2008 at 02:59:50PM +0900, Roger Pack wrote:
Yeah I would totally prefer a straight ruby2c conversion but unless you
create a run-time class analyzer and rewrite each method depending on
the parameters' classes, it will end up being about the same speed as
ludicrous [which is fast, but not significantly faster than 1.9,
so...not screaming improvement]. So what you really need is a run-time
optimizer, and it seems to me that translating to Python and using psyco
is easier than (re)creating a psyco for Ruby. That sounds hard.
Thoughts?
--
Chad Perrin [ content licensed OWL: http://owl.apotheon.org ]
Common Reformulation of Greenspun's Tenth Rule: Any sufficiently
complicated non-Lisp program contains an ad hoc informally-specified
bug-ridden slow implementation of half of Common Lisp.
[