For a fast implementation of Python

[.]

What is the fast way for a fast implementation of Python?

 

[Bruno Desthuilliers]

What is the fast way for a fast implementation of Python?

Please define "fast".

 

[cmdrrickhunter]

Psyco does some JIT compiling of Python, supposedly making it faster.
You do need to think a bit, however, beforehand.
If you really thing that the "speed" of execution is important for your
application, a scripting language such as python may be the wrong tool.
A language such as C++ or Java which is designed to be a compiled
language can be optimized much faster than python because they impose
more rules.

Some more information about what you intend to do with python may help
us guide you better. If its hardcore matrix multiplication, Numpy and
its derivates may help speed your code up.

 

[Alex Martelli]

Psyco does some JIT compiling of Python, supposedly making it faster.
You do need to think a bit, however, beforehand.
If you really thing that the "speed" of execution is important for your
application, a scripting language such as python may be the wrong tool.
A language such as C++ or Java which is designed to be a compiled
language can be optimized much faster than python because they impose
more rules.

Java generally produces bytecode that is then run by a virtual machine,
just like Python does; yes, Java has many more rules, but in general
they're not ones particularly conducive to optimization -- in fact,
optimization in Java generally hinges on just-in-time code generation
just like psyco performs, and if such JIT VMs optimize better it's
chiefly due to the huge number of person-years that have been devoted to
perfecting them (as opposed to maybe 1 person-year spent on psyco).

C and C++ do usually generate machine language directly, and their tools
(optimizing compilers first and foremost) have enjoyed investments of a
magnitude comparable to Java's (though, by now, Java's getting a lot
more investment); moreover, C++'s rules _are_ heavily optimization
oriented (e.g., no garbage collection -- being responsible for every bit
of memory is a huge chore during application development, and a cause of
many application bugs, but it DOES allow absolute maximal speed).


Alex

 

[John Roth]

Java generally produces bytecode that is then run by a virtual machine,
just like Python does; yes, Java has many more rules, but in general
they're not ones particularly conducive to optimization -- in fact,
optimization in Java generally hinges on just-in-time code generation
just like psyco performs, and if such JIT VMs optimize better it's
chiefly due to the huge number of person-years that have been devoted to
perfecting them (as opposed to maybe 1 person-year spent on psyco).

C and C++ do usually generate machine language directly, and their tools
(optimizing compilers first and foremost) have enjoyed investments of a
magnitude comparable to Java's (though, by now, Java's getting a lot
more investment); moreover, C++'s rules _are_ heavily optimization
oriented (e.g., no garbage collection -- being responsible for every bit
of memory is a huge chore during application development, and a cause of
many application bugs, but it DOES allow absolute maximal speed).

That's one of those "yes and no" answers. I remember a Java vs C++
performance comparison a few months ago that gave some really
surprising results: for programs that create a lot of 'by reference"
objects
Java is substantially faster than C++!

The reason is that Java's garbage collector is substantially faster
than
malloc. Sure, you can speed up C++ in that scenario by writing your
own allocator, but as you point out that's a substantial effort that
simply
isn't worth it unless you really, really need super performance.

When C++ was designed the latest garbage collector designs weren't
even on the drawing boards; committing to garbage collection would
have been a fairly controversial decision.

The same is true of Python: it spends a lot of time in reference
counting. My suspicion is that getting rid of reference counting in
the 3.x series might lead to a substantial speedup, simplify C and
C++ extension coding and eliminat reference counting bugs.
Interestingly, it doesn't seem to be in PEP 3099, so I suppose the
issue is still open.

If there was a simple way of using a compiler or language switch
in C++ that said: "use garbage collector", then the inherent speed
advantage of compiled over interpreted would come through. As it is,
C++
simply isn't in the speed race for _real_ object oriented programs.
I'm not interested enough to follow the current round of the C++
standardization effort. It might be coming, it might not.

John Roth

 

[=?iso-8859-1?q?Luis_M._Gonz=E1lez?=]

What is the fast way for a fast implementation of Python?

Check this out:
http://codespeak.net/pypy/dist/pypy/doc/news.html

 

[Terry Hancock]

What is the fast way for a fast implementation of Python?

-- JavaScript implementation of Python
http://groups.google.it/group/JSython/

Follow the PyPy link. The other replies were about increasing
execution speed, not ease of implementation.

Implement the "RPython" part in Javascript, then use
the PyPy project to fill in the rest? That way, you don't
even have to maintain most of it.

http://codespeak.net/pypy/dist/pypy/doc/news.html

Cheers,
Terry

 

[.]

Hi Terry.

I see:
http://codespeak.net/pypy/dist/pypy/doc/news.html
"...by translating RPython to Javascript..."

It isn't an implementation.

--
JavaScript implementation of Python
http://groups.google.it/group/JSython/


Terry Hancock ha scritto:

 

[=?iso-8859-1?q?Luis_M._Gonz=E1lez?=]

Pypy aims to become (probably sometime next year) a strong candidate to
replace cpython as the main python implementation.
Its goals are very ambicious and one of them is making it fast.
Some of its developers even think it can get as fast as C, although I
think that if it can get as fast as java, it would be great.

Its other goal is making it flexible and easier to develop and mantain.

Note that the project already produced a tool for writing extensions in
rpython that are, in theory, as fast a C extensions. So we can say that
in some way, the speed goal is already achieved.

Luis