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