GIL, threads and scheduling - performance cost

[Pierre Barbier de Reuille]

adsheehan at eircom.net a écrit :
> Hi all,
> 
> Wondering if a GIL lock/unlock causes a re-schedule/contect swap when
> embedding Python in a multi-threaded C/C++ app on Unix ?
> 
> If so, do I have any control or influence on this re-scheduling ?
> 
> The app suffers from serious performance degradation (compared to pure
> c/C++) and high context switches that I suspect the GIL unlocking may
> be aggravating ?

Well, where do you observe this degradation ? When replacing part of the
C++ code by Python's code ? Or on C++ code running parallel to your
Python code ?

Because in the first case, well, this is just something natural ! Python
runtime overhead is much greater than C++ because of its dynamic nature
(it has to resolve all the symbols at runtime ...). And given the policy
for locking/releasing the GIL, I doubt it has serious performance issues
compared to the Python interpreter itself. If current performance is an
issue, consider implementing more in C/C++ ! This will be mainly true if
you currently have some heavy looping in Python. Python is very neat to
put together processor-intensive functions written in other languages,
but not to implement them. (as an exemple looh at that:
http://www.python.org/doc/essays/list2str.html )

> 
> Thanks for any help.
> 
> Alan
> 

Pierre