The new great computer language shootout

ruby-talk
21

Hi,

What's fair for performance comparisons? Well, a
thorough language benchmark
would measure Psyco, standard cPython, and Jython
times for x86, plus
cPython and Jython for other popular processors.

These are all Open Source, so don't let anybody stop
you from porting them
to Ruby... :slight_smile:

That's a lot of pythons. :slight_smile:

I'll keep my precious Ruby, and worry about
performance later, when my programs and libraries are
written. :slight_smile:

Perhaps one of the main reasons to use a script
language, is to use it as a glue language, and I'm
fine with that.

Cheers,
Joao

···

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

22

> Psyco does some great things for the performance of certain
> algorithms, but it's not part of the core Python distribution for any
> number of reasons: only works on x86, breaks several standard
> introspection and debugging libraries, and perhaps most importantly,
> prevents redefinition of methods at runtime on optimized objects.

Hmm, if we'd had namespace selectors in Ruby, such optimizations (e.g.
optimizing integer/floating point operations) would become possible, at
least theoretically, without breaking code or loosing introspection at

They are actually possible with the current language; you'd "only"
need a code specializer + careful code cache invalidation (take a look
at the Self papers).

···

On Fri, Jun 18, 2004 at 05:38:20PM +0900, Michael Neumann wrote:

the overall level. I might be wrong, of course :slight_smile:

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Q: What's the big deal about rm, I have been deleting stuff for years? And
   never lost anything.. oops!
A: ...
  -- From the Frequently Unasked Questions

23

In article <10d50t0qrc0sl93@corp.supernews.com>,

Phil Tomson wrote:

Isn't psycho kind of a special varient of Python? Is it fair
to compare psycho Python in the language shootout (they
should probalby use the more widely used PythonC).

You may be thinking of Pyrex, a Python dialect that compiles to C and lets
you mix C and Python data types:

Pyrex

Pyrex is really quite nifty, especially for writing C extensions to Python
and for wrapping existing C libraries. You can still code in Python or close
to it, and let Pyrex write all the boilerplate C code for you. For
performance critical algorithms, if you're using C types the generated code
should be as fast as any other C code.

Kind of like Rubyinline rubyinline | software projects | by ryan davis

Or C-Generator CGenerator

Psyco, OTOH, works with standard Python code. It's essentially a Just In
Time compiler for Python:

Psyco - Introduction

Psyco isn't part of the standard Python distribution--you need to install
the Psyco module and add this to the top of your source file:

import psyco; psyco.full()

But that's all there is to it. There's nothing special about the
language--it's standard Python.

From what I've heard, though, it doesn't let you do certian things that
would be allowable in standard Python.

Psyco is only for x86 at the moment, but it can really pep up Python code on
the x86.

What's fair for performance comparisons? Well, a thorough language benchmark
would measure Psyco, standard cPython, and Jython times for x86, plus
cPython and Jython for other popular processors.

Would it be fair to use Rubyinline? ( I wouldn't think so, but opinions my
vary.)

These are all Open Source, so don't let anybody stop you from porting them
to Ruby... :slight_smile:

Some of these ideas are being worked on. And some projects exist already
(see above links).

Phil

···

Michael Geary <Mike@DeleteThis.Geary.com> wrote:

24

Hm, but isn't that much harder to implement? And you need all these
tests at runtime (well, should be no performance penalty).

For example:

  a = 1
  a += 2

This piece of code would become invalid, when the Integer#+ method is
redefined.

Hm, indeed, doesn't look imposible for me. What are the advantages (of
both)?

Regards,

  Michael

···

On Fri, Jun 18, 2004 at 05:56:30PM +0900, Mauricio Fernndez wrote:

On Fri, Jun 18, 2004 at 05:38:20PM +0900, Michael Neumann wrote:
> > Psyco does some great things for the performance of certain
> > algorithms, but it's not part of the core Python distribution for any
> > number of reasons: only works on x86, breaks several standard
> > introspection and debugging libraries, and perhaps most importantly,
> > prevents redefinition of methods at runtime on optimized objects.
>
> Hmm, if we'd had namespace selectors in Ruby, such optimizations (e.g.
> optimizing integer/floating point operations) would become possible, at
> least theoretically, without breaking code or loosing introspection at

They are actually possible with the current language; you'd "only"
need a code specializer + careful code cache invalidation (take a look
at the Self papers).

25

Michael Geary wrote:
> You may be thinking of Pyrex, a Python dialect that compiles to C
> and lets you mix C and Python data types:
>
>Pyrex
>
> Pyrex is really quite nifty, especially for writing C extensions to
> Python and for wrapping existing C libraries. You can still code
> in Python or close to it, and let Pyrex write all the boilerplate C
> code for you. For performance critical algorithms, if you're using
> C types the generated code should be as fast as any other C code.

Phil Tomson wrote:

Kind of like Rubyinline
rubyinline | software projects | by ryan davis

Not really. RubyInline more closely resembles (surprise!) PyInline:

http://pyinline.sourceforge.net/

These are both ports of the Perl Inline module:

http://inline.perl.org/

Each of these lets you write C code inline in a quoted string, with
automatic hookups so you can call a C method from Python/Ruby/Perl.

Or C-Generator CGenerator

That one is interesting, and seems to be more ambitious: a mix of Ruby and
C.

Pyrex is different from any of those: you don't write any C code at all, but
do everything in Python (or near-Python) code which Pyrex compiles into C.
The Python code can use native C types, in which case it compiles into very
efficient C code.

> Psyco, OTOH, works with standard Python code. It's essentially
> a Just In Time compiler for Python:
>
>Psyco - Introduction

From what I've heard, though, it doesn't let you do certian things
that would be allowable in standard Python.

Yes, they have a few things listed on their bug page:

http://psyco.sourceforge.net/psycoguide/bugs.html#bugs

But the restrictions are pretty minor.

The nice thing about Psyco is that it doesn't require a C compiler at all,
unlike all the other solutions mentioned above.

Don't get me wrong, I like Ruby a lot. It seems to fit the way I think and
my taste in computer languages better than Python. So I'm glad to see that
Ruby is picking up these kinds of modules too.

-Mike

26

> They are actually possible with the current language; you'd "only"
> need a code specializer + careful code cache invalidation (take a look
> at the Self papers).

Hm, but isn't that much harder to implement? And you need all these

···

On Fri, Jun 18, 2004 at 06:29:32PM +0900, Michael Neumann wrote:
                     ========================

Indeed. The Self team needed many man-years and they knew what they were
doing. It took Sun quite a long time to create an acceptable VM/JIT
for a much less dynamic language like Java, and they had most of the
original Self crew working for them :stuck_out_tongue:

tests at runtime (well, should be no performance penalty).

For example:

  a = 1
  a += 2

This piece of code would become invalid, when the Integer#+ method is
redefined.

That's what I referred to with 'code cache invalidation'; on
redefinition of Integer#+, all specialized code segments that used the
old one would be flushed out. This is performed on method redefinition,
which should be quite rare.

Hm, indeed, doesn't look imposible for me. What are the advantages (of
both)?

"Both"? If you're referring to selector namespaces, they don't simplify
the runtime needs that much, unless you forbid method redefinitions.
There could be some small speed increase, since code invalidation would
be a bit less frequent (would of course depend on the performance of
the code specializer).

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Linux: Where Don't We Want To Go Today?
  -- Submitted by Pancrazio De Mauro, paraphrasing some well-known sales talk