Using Python for programming algorithms

Henrique Dante de Almeida hdante at gmail.com
Mon May 19 21:13:52 EDT 2008


On May 19, 5:25 pm, "bruno.desthuilli... at gmail.com"
<bruno.desthuilli... at gmail.com> wrote:
> There's at least one (possibly incomplete) C interpreter. FWIW, it
> would not be harder (and possibly simpler) to write a byte-code+VM
> based C implementation than it is to write CPython, Jython or

 You may (right now, readily, without experimental software) compile C
to, for example, llvm bytecode, interpret it in the VM, JIT-compile
it, native-compile it, etc. There's also experimental support for
compiling C to the JVM.

 Notice that you usually want to optimize C code, so it will be harder
than writing a python interpreter.

> IronPython. The point is that it's just useless - C is a (very) low-

 It's not useless. Consider that you may distribute your C application
in byte-code instead of native code and during the installation
process, it is native compiled and optimized exactly to your
architecture (like a better "Gentoo", with the compilation split
between you and the user).

> point is that, given Python's (as a language) extrem dynamism,
> compiling it to native code wouldn't buy you much in terms of raw
> performances. The problem is not with writing a native-code
> compiler[1}, but with writing an *optimising* native-code compiler.

 That's the job of pypy folks. And they are getting there. They use a
python subset, called RPython:

 http://morepypy.blogspot.com/2008/01/rpython-can-be-faster-than-c.html
 (note: the test in the site compares garbage collection speed)

 BTW, here's how to compile RPython to (optimized) native code:
 http://codespeak.net/pypy/dist/pypy/doc/standalone-howto.html

 And here is the document that talks about all that:
 http://codespeak.net/pypy/dist/pypy/doc/dynamic-language-translation.html

> I'm not trying to "trivialize" anything. I'm just getting fed up with
> this "Python is an interpreted and therefore slow language" non-
> sense.  Python is a language, and as such is neither slow nor fast nor

 I'm sorry for creating all those offtopic posts. I feel so ashamed :-
(. Well, not really. :-P

 My suggestion was to use code suitable for optimization (not
considering things that you'd need to worry about the way you write
code, like RPython, or psyco). That's all. :-)



More information about the Python-list mailing list