GCC 4.6

Russel Winder russel at russel.org.uk
Tue Mar 29 00:00:01 PDT 2011


On Mon, 2011-03-28 at 17:31 -0400, bearophile wrote:
> Walter:
> 
> >There's a lot of money and manpower behind Python. If this were true,
> why hasn't this technology been done for Python?<

It has been and is being.  The problem is complicated by the GIL, so it
is not a simple situation.

> It was done, more than one time. One good JIT was Psyco. And more
> recently PyPy is about to surpass Psyco in performance:
> http://codespeak.net/pypy/dist/pypy/doc/

And there was Unladen Swallow which was a Google funded project to add a
JIT to CPython 2.6.  It failed to meet it's goals.  However the results
will nonetheless filter into CPython 3.2 or 3.3.

> But the Lua JIT is quite better than Psyco, its programmer is very
> intelligent (Psyco author too is an intelligent programmer, Armin
> Rigo).

The Lua JIT can hardly be compared to something for Python since the
underlying VMs are totally different -- as you point out below..  What
can be said is that the Lua JIT works very well for Lua, whilst there is
no production quality equivalent for Python as yet. 

> And more importantly, this whole discussion can't be reduced to just a
> static Vs dynamic typing. Lua and Python are different languages,
> Python is probably more dynamic than Lua, it is quite more powerful
> than Lua, and it's different. So creating a really efficient JIT for
> Python is much harder than doing it for Lua, and you can't compare
> them much.

Indeed.

> The result is that currently PyPy is generally about 8/10 times slower
> than D code, while Lua-Jit is about 2-3 times slower than D compiled
> well, and JavaScript running on the V8-CrankShaft JIT is about 3-4
> times slower than D. And Mozilla hopes to someday beat V8, though a
> local static inferencer (probably to be seen in Firefox 5? See the
> "(TypeInference)" here, it's in development still:
> http://arewefastyet.com/?a=b&view=regress ).

Sadly PyPy is still only implementing CPython 2.5 which is a
significantly worse barrier than any speed issues.

> Lua is a quite simple language, there are some things you can't do
> well with it, so you need other languages. And even with a JIT Lua is
> often not as fast as good C code. I have never said that Lua+JIT is
> better than D, I am not much interested in Lua.

Which leads to the real point as to why Python is becoming the leading
language for scientific computing, it is a dynamic language for
coordinating C/C++/Fortran computations and providing GUI front ends.
Performance of Python is thus a side issue since grunt computation is
done in languages which are closer to the machine -- with all the crap
that entails.

I know, Python, and indeed Lua, are used for plugins to big C/C++
systems as well.  Here is is to provide the dynamic partner to a static
system.  This exactly how Groovy works with Java.  The nature of the
modern world is a symbiosis of languages not trying to do everything
with one.

<...stuff on floating point representations elided...>

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110329/ca526e14/attachment.pgp>


More information about the Digitalmars-d mailing list