[Python-Dev] Reworking the GIL

[Baptiste Lepilleur]

2009/11/7 Antoine Pitrou <solipsis at pitrou.net>

>
> Hello again,
>
> > It shows that, on my platform for this specific benchmark:
> >       *  newgil manage to leverage a significant amount of parallelism
> >         (1.7) where python 3.1 does not (3.1 is 80% slower)
>
> I think you are mistaken:
>
> -j0 (main thread only)
> newgil: 47.483s, 47.605s, 47.512s
> -j4 (4 consumer threads, main thread producing/waiting)
> newgil: 48.428s, 49.217s
>
> The runtimes are actually the same, so newgil doesn't leverage anything.
> However, it doesn't degrade performance like 2.x/3.1 does :-)
>

Ooops, I was comparing to 3.1 -j4 times which make no sense. One would think
I wanted to see that result since I though the GIL was released :/. This
greatly reduce the interest of this benchmark...


> >       * 3.1 is more than 2 times slower than python 2.6 on this
> >         benchmark
>
> That's the most worrying outcome I'd say. Are you sure the benchmark
> really does the same thing? Under 2.6, you should add re.UNICODE to the
> regular expression flags so as to match the 3.x semantics.
>

I've tried, but there is no change in result (the regexp does not use \w &
co but specify a lot unicode ranges). All strings are already of unicode
type in 2.6.


>  > [if I understood correctly in 3.x regex release the GIL].
>
> Unless I've missed something it doesn't, no.
>
Hmmm, I was confusing with other modules (bzip2 & hashlib?). Looking back at
the result of your benchmark it's obvious. Is there a place where the list
of functions releasing the GIL is available? I did not see anything in
bz2.compress documentation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091108/2c3ea338/attachment.htm>