Re: Using Python for programming algorithms

On May 19, 5:25 pm, "bruno.desthuilli...@xxxxxxxxx"
<bruno.desthuilli...@xxxxxxxxx> 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. :-)
.

Relevant Pages

  • Re: converting some autogenerated ruby code to C
    ... faster than the pure Ruby version. ... I'm wondering how much optimization has been done there. ... def test ... You would either have to generate and compile and load a C extension for _each_ call of *eval or somehow collect all the code to eval and do it all at once. ...
    (comp.lang.ruby)
  • Re: Micro Focus COBOL runtime, /clr:pure, etc.
    ... compiling to native code and INCLUDING all vendor-supplied subroutines in a ... And, of course, all of this is slightly different from whether Micro Focus ... MicroFocus COBOL in its earliest incarnations ... DID compile to native code. ...
    (comp.lang.cobol)
  • Re: Cannot optimize 64bit Linux code
    ... It is a floating point intensive code and when I compile ... It seems like something is inhibiting the optimization. ... let's base everything on a variant of the "register" calling convention, and use SSE for all the floating point math rather than crufty old x87. ... my guess is that the calling convention was designed according to some misguided sense of "optimization wisdom", ...
    (comp.lang.c)
  • Tricking pl1s production_table
    ... you're using debug and break statements to create a trace log. ... testprog: procedure options; ... I can't just go compile everything with -table ... which doesn't happen below optimization level 2. ...
    (comp.sys.stratus)
  • Re: Compiling Delphi .NET to native/asm ?
    ... Yes, it does compile to the native code of platform you are running it at, ... There are specialised programs for decompiling delphi application like DeDe, ...
    (alt.comp.lang.borland-delphi)