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.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part