Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.dougwise.org!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!news.glorb.com!news-out.octanews.net!indigo.octanews.net!auth.beige.octanews.com.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.python
Subject: Re: a basic bytecode to machine code compiler
References: <4j7lp.5204$sS4.1784@newsfe11.iad> <4d95cba6$0$29992$c3e8da3$5496439d@news.astraweb.com> <mailman.80.1301672757.2990.python-list@python.org> <4d96f49b$0$29992$c3e8da3$5496439d@news.astraweb.com> <mailman.124.1301740231.2990.python-list@python.org> <4d977362$0$10551$742ec2ed@news.sonic.net>
Date: Sat, 02 Apr 2011 14:32:00 -0700
Message-ID: <7x4o6ge3vz.fsf@ruckus.brouhaha.com>
Organization: Nightsong/Fort GNOX
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:HeNQlNyA799kHuiezXlsT74WmII=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 18
NNTP-Posting-Date: 02 Apr 2011 16:32:00 CDT
X-Complaints-To: abuse@octanews.net
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:2471

John Nagle <nagle@animats.com> writes:
>     There's no easy way to speed up Python; that's been tried.
> It needs either a very, very elaborate JIT system, more complex
> than the ones for Java or Self, or some language restrictions.

Is it worse than Javascript?  Tracemonkey and its descendants produce
pretty fast code, I think.

> The main restriction I would impose is to provide a call that says:
> "OK, we're done with loading, initialization, and configuration.
> Now freeze the code."  At that moment, all the global
> analysis and compiling takes place.  This allows getting rid
> of the GIL and getting real performance out of multithread CPUs.

That's quite an interesting idea.  I do think a lot of production Python
code implicitly depends on the GIL and would need rework for multicore.
For example, code that expects "n += 1" to be atomic, because the
CPython bytecode interpreter won't switch threads in the middle of it.