

The Python GIL Visualized - gthank
http://www.dabeaz.com/blog/2010/01/python-gil-visualized.html

======
jcl
For readers in the future, here's a link to the article instead of the whole
blog:

[http://www.dabeaz.com/blog/2010/01/python-gil-
visualized.htm...](http://www.dabeaz.com/blog/2010/01/python-gil-
visualized.html)

~~~
rbanffy
I found the post about block towers fascinating.

~~~
ash
Yes!

[http://www.dabeaz.com/blog/2009/11/fun-with-block-
towers.htm...](http://www.dabeaz.com/blog/2009/11/fun-with-block-towers.html)

------
tel
Though this has nothing to do with GIL or Python, the presentation reminds me
of threadscope:

<http://raintown.org/?page_id=132>

Take a look at it in action

<http://www.youtube.com/watch?v=qZXq8fxebKU>

------
diN0bot
anyone know of a tool that will generate charts like that when i run my
program? perhaps by instrumenting my code?

i'd be very curious about this, but i wouldn't want to invest a lot of time
into it. right now i use python for my web site serving (django).

------
dmaclay
Just don't use threads in python, use multiprocessing!

~~~
thorax
Sure, except when that doesn't make any sense.

I embed Python in my application. My highly graphical application requires
XY,000 KB of memory. It's probably not wise to re-invoke my entire app Z times
simply so that Python can properly take advantage of the user's multi-core OS
while scripting inside my application.

Any time you embed Python (e.g. a game, a browser, etc), the multiprocessing
support isn't going to work very well as it is today. Ideally we get to the
point where threading works great in the core interpreter.

I asked Guido about this in front of his keynote audience a few Pycons ago,
and his answer was a sad shrug and saying to use Jython or IronPython instead.

I'd love to see the GIL improved/removed because CPython-embedding apps don't
have the same options as everyday pure scripting.

~~~
malkia
In case with Lua - I can simply create new context, and voila a whole new lua
vm is there. Not sure whether that could be done with embeddable python.

~~~
codexon
Does Lua also have a GIL?

~~~
silentbicycle
No, it doesn't. The whole interpreter was designed from the beginning to be
embedded in another (typically C or C++) project, and they didn't want to have
any concurrency infrastructure in the core language that would clash with the
surrounding project's design. (It has excellent support for coroutines,
though.)

Rather than having static variables and a GIL, the interpreter keeps all its
state behind an opaque pointer to a VM context. The VM is quite lightweight (a
few hundred K), and running in each thread or process is not a big deal. With
forking, you even share the standard libraries. In practice, this just means
that every call to the Lua C API starts with ("lua_State *L"). Not a big deal.

Lua also has real tail-calls, closures, and lambdas. It's a great language.
Rather like a smaller, cleaner, less opinionated Python.

~~~
malkia
Also lua right now has the one of the best JIT's out there (luajit). The guy
behind the project is simply genius. Really good stuff. And also kept small.
It's x2-x3 faster than V8 on specific benchmarks that I've did (mainly dealing
with 3d model meshes and modifying them).

It's only for x86 right now, but he's working on x64 port.

~~~
silentbicycle
LuaJIT is really impressive, but honestly, the stock interpreter is fast
enough for me in general, and I'm fine with just moving hotspots to C as
needed.

I'm more impressed with how _concise_ Lua is. I've got the Lua 5.1 Reference
Manual sitting in front of me. It's 103 pages for the whole language (roughly
half of which is the C API), the entire syntax fits on page 95, etc. I can
keep it all in my mental L1 cache, so to speak. Yet, it's expressive enough to
have displaced Python as my go-to language. It's not perfect, but I'm very
happy with the trade-offs it makes.

I'll be psyched once it's ported to a couple more hardware platforms, though.

