Python is slow

Isaac Gouy igouy2 at yahoo.com
Sat Dec 13 16:17:00 CET 2008


On Dec 12, 6:58 am, bearophileH... at lycos.com wrote:
> sturlamolden:
>
> > On a recent benchmark Java 6 -server beats C compiled by GCC 4.2.3 And
> > most of that magic comes from an implementation of a dynamically typed
> > language (Smalltalk). [...]
> >http://shootout.alioth.debian.org/u32q/benchmark.php?test=all〈=all
>
> That is indeed a nice result, JavaVM has come a long way from the
> first one used for applets. That result comes mostly from the fact
> that this is a test on a 4-core CPU, that is less easy to manage from
> C. You can see that in the single 64-bit core tests:http://shootout.alioth.debian.org/u64/benchmark.php?test=all〈=all


Whether or not it's less easy to manage from C is unclear, but you are
correct to point out few of those C programs have been updated to
exploit quadcore - so the reasonable comparison is with C++.


And the benchmarks game also provides x86 measurements with programs
forced onto a single core which shows GCC ahead

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all



> And take a look at the memory used too, up to 34 times higher for the
> JVM on the 4-core CPU.
>
> In the next years people that use low-level languages like C may need
> to invent a new language fitter for multi-core CPUs, able to be used
> on GPUs too (see the OpenCL), less error-prone than C, able to use the
> CPU vector instructions efficiently. (The D language is probably unfit
> for this purpose, because even if it's meant to be a system language,
> I don't think it can be used much to replace C everywhere it's used
> now.) A C+ maybe? :-)
>
> I agree that CPython may quite enjoy having something built-in like
> Psyco, but it's a lot of work for an open source project. Probably
> with 1/3 or 1/2 of the work poured on PyPy you may create that
> improvement for CPython. Maybe PyPy will someday produce some fruit,
> but I think they have used the wrong strategy: instead of trying to
> create something very new that someday will work, it's often better to
> try to improve something that today everybody uses, AND try to be
> useful from almost the very beginning.
>
> Bye,
> bearophile




More information about the Python-list mailing list