Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #2471
| 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> (permalink) |
| 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 |
Show key headers only | View raw
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.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
a basic bytecode to machine code compiler Rouslan Korneychuk <rouslank@msn.com> - 2011-03-31 18:33 -0400
Re: a basic bytecode to machine code compiler Stefan Behnel <stefan_ml@behnel.de> - 2011-04-01 02:05 +0200
Re: a basic bytecode to machine code compiler Terry Reedy <tjreedy@udel.edu> - 2011-03-31 20:52 -0400
Re: a basic bytecode to machine code compiler Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-01 12:57 +0000
Re: a basic bytecode to machine code compiler Stefan Behnel <stefan_ml@behnel.de> - 2011-04-01 17:45 +0200
Re: a basic bytecode to machine code compiler Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-04-02 10:04 +0000
Re: a basic bytecode to machine code compiler Stefan Behnel <stefan_ml@behnel.de> - 2011-04-02 12:30 +0200
Re: a basic bytecode to machine code compiler John Nagle <nagle@animats.com> - 2011-04-02 12:05 -0700
Re: a basic bytecode to machine code compiler Paul Rubin <no.email@nospam.invalid> - 2011-04-02 14:32 -0700
Re: a basic bytecode to machine code compiler Robert Kern <robert.kern@gmail.com> - 2011-04-02 19:12 -0500
Re: a basic bytecode to machine code compiler Rouslan Korneychuk <rouslank@msn.com> - 2011-04-01 15:31 -0400
csiph-web