Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #2478

Re: a basic bytecode to machine code compiler

From Robert Kern <robert.kern@gmail.com>
Subject Re: a basic bytecode to machine code compiler
Date 2011-04-02 19:12 -0500
Organization The Church of Last Thursday
References (1 earlier) <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>
Newsgroups comp.lang.python
Message-ID <mailman.142.1301789559.2990.python-list@python.org> (permalink)

Show all headers | View raw


On 4/2/11 2:05 PM, John Nagle wrote:

> 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.
> 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 is not the reason the GIL exists, and being able to "freeze" the code will 
not let you get rid of the GIL alone. CPython's GIL exists to protect the data 
structures internal to its implementation and provide implicit protection to C 
extension modules (making them relatively easy to write threadsafe). Reference 
counts are the primary data structures being protected. IronPython and Jython 
allow just as much dynamism as CPython, and they have no mechanism for 
"freezing" the code, but they do not have a GIL. I believe this has been pointed 
out to you before, but I don't think I've seen you acknowledge it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

Back to comp.lang.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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