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


 

Forums >

comp.lang.ruby

ruby -> python

Roger Pack

12/27/2008 12:22:00 AM

I was thinking the other day...wouldn't it be nice to be able to take
advantage of some python capabilities from within Ruby, like psyco, for
example?

i.e.
any "bottleneck" inner loops can be converted to Python, run by an
optimized psyco compiled Python, and come back out to a familiar Ruby
environment.

Does anyone know if such a project exists? Any feedback on the idea
itself?
I'd imagine that most Ruby constructs have their Python equivalent.

Thanks!
-=r
--
Posted via http://www.ruby-....
6 Answers

M. Edward (Ed) Borasky

12/27/2008 12:52:00 AM

0

Roger Pack wrote:
> I was thinking the other day...wouldn't it be nice to be able to take
> advantage of some python capabilities from within Ruby, like psyco, for
> example?
>
> i.e.
> any "bottleneck" inner loops can be converted to Python, run by an
> optimized psyco compiled Python, and come back out to a familiar Ruby
> environment.
>
> Does anyone know if such a project exists? Any feedback on the idea
> itself?
> I'd imagine that most Ruby constructs have their Python equivalent.

Why introduce Python, when on many platforms, you have the ability to
use inline C, C++ or assembler? IIRC it works on Cygwin, all *Nix
platforms and probably MacOS X as well.
>
> Thanks!
> -=r


--
M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P), WOM

I've never met a happy clam. In fact, most of them were pretty steamed.

Roger Pack

12/27/2008 1:12:00 AM

0

>> I'd imagine that most Ruby constructs have their Python equivalent.
>
> Why introduce Python, when on many platforms, you have the ability to
> use inline C, C++ or assembler? IIRC it works on Cygwin, all *Nix
> platforms and probably MacOS X as well.

Because I don't want to rewrite my bottlenecks to C--I want to leave
them as ruby and have them "automagically translated"

Main advantage: Python and Ruby are pretty similar, so a translator
shouldn't be as hard to write as, say, a ruby to c JIT translator [psyco
is a Python->bytecode JIT translator, so the work has been done there].

Obviously a translator to C would be the best, I just think it would be
pretty hard, and if one could translate to Python, a lot of the
optimization exists. A fit of python envy, you could call it.
Thoughts?
-=r
--
Posted via http://www.ruby-....

Luis Lavena

12/27/2008 3:09:00 AM

0

On Dec 26, 11:11 pm, Roger Pack <rogerpack2...@gmail.com> wrote:
> >> I'd imagine that most Ruby constructs have their Python equivalent.
>
> > Why introduce Python, when on many platforms, you have the ability to
> > use inline C, C++ or assembler? IIRC it works on Cygwin, all *Nix
> > platforms and probably MacOS X as well.
>
> Because I don't want to rewrite my bottlenecks to C--I want to leave
> them as ruby and have them "automagically translated"
>
> Main advantage: Python and Ruby are pretty similar, so a translator
> shouldn't be as hard to write as, say, a ruby to c JIT translator [psyco
> is a Python->bytecode JIT translator, so the work has been done there].
>
> Obviously a translator to C would be the best, I just think it would be
> pretty  hard, and if one could translate to Python, a lot of the
> optimization exists. A fit of python envy, you could call it.
> Thoughts?
> -=r

What about _why experiments on Ruby to Python front (only YARV):

http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppE...

I know, is silly, but is bytecode translated ;-)

Another option is look at ParseTree for the AST and generate C code
from it (ruby2c)

--
Luis Lavena

Roger Pack

12/27/2008 6:00:00 AM

0

Luis Lavena wrote:
> On Dec 26, 11:11�pm, Roger Pack <rogerpack2...@gmail.com> wrote:
>> shouldn't be as hard to write as, say, a ruby to c JIT translator [psyco
>> is a Python->bytecode JIT translator, so the work has been done there].
>>
>> Obviously a translator to C would be the best, I just think it would be
>> pretty �hard, and if one could translate to Python, a lot of the
>> optimization exists. A fit of python envy, you could call it.
>> Thoughts?
>> -=r
>
> What about _why experiments on Ruby to Python front (only YARV):
>
> http://hackety.org/2008/05/05/sneakingRubyThroughGoogleAppE...
>
> I know, is silly, but is bytecode translated ;-)

Unholy is definitely fascinating. I'm unsure of it's ability to
transfer say a whole class directly into Python :) [
Here's a funny quote from _why:

"Instead of asking â??can unholy run Rails?â? try asking â??can unholy run 4
plus 7?â? And my answer to that is: no, no, no, no, it probably canâ??t!!"

> Another option is look at ParseTree for the AST and generate C code
> from it (ruby2c)

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?

-=r
--
Posted via http://www.ruby-....

Robert Dober

12/30/2008 11:50:00 AM

0

On Tue, Dec 30, 2008 at 7:39 AM, Chad Perrin <perrin@apotheon.com> wrote:

> 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.
What amazes me most however is that it picked your name correctly ;)
Was this one of the Ruby Quiz solutions ?
Cheers
R.
>
> --
> Chad Perrin [ content licensed OWL: http://owl.ap... ]
> 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.
>



--=20
Il computer non =E8 una macchina intelligente che aiuta le persone
stupide, anzi, =E8 una macchina stupida che funziona solo nelle mani
delle persone intelligenti.
Computers are not smart to help stupid people, rather they are stupid
and will work only if taken care of by smart people.

Umberto Eco

Roger Pack

1/2/2009 10:44:00 PM

0

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

Yeah--I'm looking for the easiest path here--like from the outside it
seems like a "ruco" project is two-fold: one get a working JIT
compilation working [arguably non-trivial] and then get it to work with
different parameters. Whereas "rupy" seems like one step.

Psyco itself has a large download from what appears to be "lots of lines
of code"[1], which made me think that "ruco" is hard and "rupy" might be
simpler. At least I can write rupy in Ruby theoretically, which seems
faster and easier than C.

> 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.
What would the benefits be?

I suppose that being able to convert to Python might help with the
google app engine or what not.

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

By compiler you mean it translates a .rb file to a .py one? [or like
unholy bytecode -> bytecode]?


> 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

No joke. Just the thought of having to use len(instance) instead of
string_instance.length makes me cringe LOL.

My hope was that Python and Ruby would be similar enough to make it
easy. In which I'm probably sadly mistaken but...it might still be an
interesting project. I think I may well end up just living with 1.9's
[slightly improved] speed :)

Thoughts?

-=r
[1] http://codespeak.net/svn/psy...

Psyco v. 1.9 speeds:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=psyco&...
--
Posted via http://www.ruby-....