the new great computer language shootout

[Phil Tomson]

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

http://www.cosc.canterbury.ac.nz/~greg/python/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 http://www.zenspider.com/ZSS/Products/RubyInline/

Or C-Generator http://redshift.sourceforge.net/cgen/

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

http://psyco.sourceforge.net/introduction.html

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

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

Phil

 

[Mark Hubbart]

It is not so surprising += is always faster in Ruby (from my
experience).This change would place us between mzscheme and mawk.
Note that many other languages (perl, icon lua...) uses += so it
should be allowed.

hmmm... actually, 12% speed increase (actually a 12.7% time decrease,
to be specific) would just kick us up one notch, putting us ahead of
gawk (on my box, anyway, YMMV). But at least we wouldn't be last

cheers,
Mark

 

[Eric Hodel]

--I4g3zIzscEHdx6fd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

=20
Huh? In what way is it flawed?

See ruby-talk:103992

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--I4g3zIzscEHdx6fd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFA00sJMypVHHlsnwQRAnyXAJ9rTdYAdUufQj32MqK9q/ChsPjUiQCfWiUx
85MU2D83SiR1rI5xsO0CoXo=
=1LpF
-----END PGP SIGNATURE-----

--I4g3zIzscEHdx6fd--

 

[Michael Geary]

Kind of like Rubyinline
http://www.zenspider.com/ZSS/Products/RubyInline/

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 http://redshift.sourceforge.net/cgen/

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.

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

 

[gabriele renzi]

hmmm... actually, 12% speed increase (actually a 12.7% time decrease,
to be specific) would just kick us up one notch, putting us ahead of
gawk (on my box, anyway, YMMV). But at least we wouldn't be last

did you submitted the proposed change to the authors ?
while you're at it you could ask for the removal of all thst ugly
'then' in conditionals, and looking at except.ruby there are useless
'return self' in the initialize method, then
def some_function(num)
begin
hi_function(num)
rescue
print "We shouldn't get here, exception is: #{$!.type}\n"
end
end

should be rewritten as:

def func
other_func
rescue
print..
end

no need of explicit begin end.

I'd do this myself but I can't test fixed implementations ATM (no ruby
here). And about the hashes test: why we have to use string
conversion? we can safely use any object as an hash key..

 

[Gawnsoft]

..

hmmm... actually, 12% speed increase (actually a 12.7% time decrease,
to be specific) would just kick us up one notch, putting us ahead of
gawk (on my box, anyway, YMMV). But at least we wouldn't be last

Is there a new definition of speed that's not as a linear function of
time?


--
Cheers,
Euan
Gawnsoft: http://www.gawnsoft.co.sr
Symbian/Epoc wiki: http://html.dnsalias.net:1122
Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk