471,325 Members | 1,702 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,325 software developers and data experts.

Possible suggestion for removing the GIL

Hi,

Recently there was some talk on removing the GIL and even the BDFL has
written a blog post on it.
I was trying to come up with a scalable and backwards compatible
approach for how to do it.

I've put my thoughts up in a blog post - and I'd really like to hear
what the community thinks of it.
Mainly it revolves around dedicating one core for executing
synchronized code and doing context switches instead of acquiring/
releasing locks.

http://www.brainwavelive.com/blog/in...eter-Lock.html

Thanks,
Prateek Sureka

Sep 13 '07 #1
4 908
Prateek wrote:
Hi,

Recently there was some talk on removing the GIL and even the BDFL has
written a blog post on it.
I was trying to come up with a scalable and backwards compatible
approach for how to do it.

I've put my thoughts up in a blog post - and I'd really like to hear
what the community thinks of it.
Mainly it revolves around dedicating one core for executing
synchronized code and doing context switches instead of acquiring/
releasing locks.
Where is the gain? Having just one core doesn't give you true parallelism -
which is the main reason behind the cries for a GIL-less Python.

Diez
Sep 13 '07 #2
On Sep 13, 1:36 pm, "Diez B. Roggisch" <de...@nospam.web.dewrote:
Prateek wrote:
Hi,
Recently there was some talk on removing the GIL and even the BDFL has
written a blog post on it.
I was trying to come up with a scalable and backwards compatible
approach for how to do it.
I've put my thoughts up in a blog post - and I'd really like to hear
what the community thinks of it.
Mainly it revolves around dedicating one core for executing
synchronized code and doing context switches instead of acquiring/
releasing locks.

Where is the gain? Having just one core doesn't give you true parallelism -
which is the main reason behind the cries for a GIL-less Python.

Diez
Diez,

I was talking of dedicating one core for synchronized code. In the
case of a threaded app on two cores, one core would be dedicated to
synchronized code and the other would run non-sync code (effectively
behaving like a single threaded machine). However, on machines with n
cores where n 2 cores, we would have n-1 cores available to run code
in parallel.

Prateek

Sep 13 '07 #3
On 9/13/07, Prateek <su*****@gmail.comwrote:
On Sep 13, 1:36 pm, "Diez B. Roggisch" <de...@nospam.web.dewrote:
Prateek wrote:
Hi,
Recently there was some talk on removing the GIL and even the BDFL has
written a blog post on it.
I was trying to come up with a scalable and backwards compatible
approach for how to do it.
I've put my thoughts up in a blog post - and I'd really like to hear
what the community thinks of it.
Mainly it revolves around dedicating one core for executing
synchronized code and doing context switches instead of acquiring/
releasing locks.
Where is the gain? Having just one core doesn't give you true parallelism -
which is the main reason behind the cries for a GIL-less Python.

Diez

Diez,

I was talking of dedicating one core for synchronized code. In the
case of a threaded app on two cores, one core would be dedicated to
synchronized code and the other would run non-sync code (effectively
behaving like a single threaded machine). However, on machines with n
cores where n 2 cores, we would have n-1 cores available to run code
in parallel.
What you're describing would have the same characteristics as the
current code - code that is able to execute without the GIL held
already will run in parallel on a multi-core machine.
Sep 13 '07 #4
Prateek wrote:
[...]
Mainly it revolves around dedicating one core for executing
synchronized code and doing context switches instead of acquiring/
releasing locks.

http://www.brainwavelive.com/blog/in...eter-Lock.html
Context switches are generally more expensive than acquiring
and release locks. Most systems' run-queues are protected by
locks. The context switches at issue all involve the
dedicated core, so I do not see any parallelism advantage.
--
--Bryan
Sep 15 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Jeff Lanfield | last post: by
3 posts views Thread by Gunnar | last post: by
40 posts views Thread by Ron Adam | last post: by
15 posts views Thread by Jon Skeet | last post: by
4 posts views Thread by CJ Taylor | last post: by
2 posts views Thread by =?iso-8859-1?B?QW5kcuk=?= | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.