Given GCC's announcement that Intel's STM will be an extension for C and C++ in GCC 4.7, what does this mean for Python, and the GIL? I've seen efforts made to make STM available as a context, and for use in user code. I've also read about the "old attempts way back" that attempted to use finer grain locking. The understandably failed due to the heavy costs involved in both the locking mechanisms used, and the overhead of a reference counting garbage collection system. However given advances in locking and garbage collection in the last decade, what attempts have been made recently to try these new ideas out? In particular, how unlikely is it that all the thread safe primitives, global contexts, and reference counting functions be made __transaction_atomic, and magical parallelism performance boosts ensue? I'm aware that C89, platforms without STM/GCC, and single threaded performance are concerns. Please ignore these for the sake of discussion about possibilities. http://gcc.gnu.org/wiki/TransactionalMemory http://linux.die.net/man/4/futex
2011/11/30 Matt Joiner <anacrolix@gmail.com>:
Given GCC's announcement that Intel's STM will be an extension for C and C++ in GCC 4.7, what does this mean for Python, and the GIL?
I've seen efforts made to make STM available as a context, and for use in user code. I've also read about the "old attempts way back" that attempted to use finer grain locking. The understandably failed due to the heavy costs involved in both the locking mechanisms used, and the overhead of a reference counting garbage collection system.
However given advances in locking and garbage collection in the last decade, what attempts have been made recently to try these new ideas out? In particular, how unlikely is it that all the thread safe primitives, global contexts, and reference counting functions be made __transaction_atomic, and magical parallelism performance boosts ensue?
Have you seen http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.h... ? -- Regards, Benjamin
I did see this, I'm not convinced it's only relevant to PyPy. On Thu, Dec 1, 2011 at 2:25 AM, Benjamin Peterson <benjamin@python.org> wrote:
2011/11/30 Matt Joiner <anacrolix@gmail.com>:
Given GCC's announcement that Intel's STM will be an extension for C and C++ in GCC 4.7, what does this mean for Python, and the GIL?
I've seen efforts made to make STM available as a context, and for use in user code. I've also read about the "old attempts way back" that attempted to use finer grain locking. The understandably failed due to the heavy costs involved in both the locking mechanisms used, and the overhead of a reference counting garbage collection system.
However given advances in locking and garbage collection in the last decade, what attempts have been made recently to try these new ideas out? In particular, how unlikely is it that all the thread safe primitives, global contexts, and reference counting functions be made __transaction_atomic, and magical parallelism performance boosts ensue?
Have you seen http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.h... ?
-- Regards, Benjamin
Azul has been using hardware transactional memory on their custom CPUs (and likely STM in their current x86 virtual machine based products) to great effect for their massively parallel Java VM (700+ cpu cores and gobs of ram) for over 4 years. I'll leave it to the reader to do the relevant searching to read more on that. My point is: This is up to any given Python VM implementation to take advantage of or not as it sees fit. Shoe horning it into an existing VM may not make much sense but anyone is welcome to try. -gps
On Thu, Dec 1, 2011 at 10:58 AM, Gregory P. Smith <greg@krypto.org> wrote:
Azul has been using hardware transactional memory on their custom CPUs (and likely STM in their current x86 virtual machine based products) to great effect for their massively parallel Java VM (700+ cpu cores and gobs of ram) for over 4 years. I'll leave it to the reader to do the relevant searching to read more on that.
My point is: This is up to any given Python VM implementation to take advantage of or not as it sees fit. Shoe horning it into an existing VM may not make much sense but anyone is welcome to try.
There's a patch somewhere on the tracker to add an "Armin Rigo hook" to the CPython eval loop so he can play with STM in Python as well (at least, I think it was STM he wanted it for - it might have been something else). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I saw this, I believe it just exposes an STM primitive to user code. It doesn't make use of STM for Python internals. Explicit STM doesn't seem particularly useful for a language that doesn't expose raw memory in its normal usage. On Thu, Dec 1, 2011 at 4:41 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Dec 1, 2011 at 10:58 AM, Gregory P. Smith <greg@krypto.org> wrote:
Azul has been using hardware transactional memory on their custom CPUs (and likely STM in their current x86 virtual machine based products) to great effect for their massively parallel Java VM (700+ cpu cores and gobs of ram) for over 4 years. I'll leave it to the reader to do the relevant searching to read more on that.
My point is: This is up to any given Python VM implementation to take advantage of or not as it sees fit. Shoe horning it into an existing VM may not make much sense but anyone is welcome to try.
There's a patch somewhere on the tracker to add an "Armin Rigo hook" to the CPython eval loop so he can play with STM in Python as well (at least, I think it was STM he wanted it for - it might have been something else).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi, On Thu, Dec 1, 2011 at 07:06, Matt Joiner <anacrolix@gmail.com> wrote:
I saw this, I believe it just exposes an STM primitive to user code. It doesn't make use of STM for Python internals.
That's correct.
Explicit STM doesn't seem particularly useful for a language that doesn't expose raw memory in its normal usage.
In my opinion, that sentence could not be more wrong. It is true that, as I discuss on the blog post cited a few times in this thread, the first goal I see is to use STM to replace the GIL as an internal way of keeping the state of the interpreter consistent. This could quite possibly be achieved using the new GCC __transaction_atomic keyword, although I see already annoying issues (e.g. the keyword can only protect a _syntactically nested_ piece of code as a transaction). However there is another aspect: user-exposed STM, which I didn't explore much. While it is potentially even more important, it is a language design question, so I'm happy to delegate it to python-dev. In my opinion, explicit STM (like Clojure) is not only *a* way to write multithreaded Python programs, but it seems to be *the only* way that really makes sense in general, for more than small examples and more than examples where other hacks are enough (see http://en.wikipedia.org/wiki/Software_transactional_memory#Composable_operat... ). In other words, locks are low-level and should not be used in a high-level language, like direct memory accesses, just because it forces the programmer to think about increasingly complicated situations. And of course there is the background idea that TM might be available in hardware someday. My own guess is that it will occur, and I bet that in 5 to 10 years all new Intel and AMD CPUs will have Hybrid TM. On such hardware, the performance penalty mostly disappears (which is also, I guess, the reasoning behind GCC 4.7, offering a future path to use Hybrid TM). If python-dev people are interested in exploring the language design space in that direction, I would be most happy to look in more detail at GCC 4.7. If we manage to make use of it, then we could get a version of CPython using STM internally with a very minimal patch. If it seems useful we can then turn that patch into #ifdefs into the normal CPython. It would of course be off by default because of the performance hit; still, it would give an optional alternate "CPythonSTM" to play with in order to come up with good user-level abstractions. (This is what I'm already trying to do with PyPy without using GCC 4.7, and it's progressing nicely.) (My existing patch to CPython emulating user-level STM with the GIL is not really satisfying, also for the reason that it cannot emulate some other potentially useful user constructs, like abort_and_retry().) A bientôt, Armin.
Armin, thanks for weighing in on this. I'm keen to see a CPython making use of STM, maybe I'll give it a try over Christmas break. I'm willing to take the single threaded performance hit, as I have several applications that degrade due to significant contention with the GIL. The other benefits of STM you describe make it a lot more appealing. I actually tried out Haskell recently to make use of many of the advanced features but came crawling back. If anyone else is keen to try this, I'm happy to receive patches for testing and review. On Thu, Dec 1, 2011 at 10:01 PM, Armin Rigo <arigo@tunes.org> wrote:
Hi,
On Thu, Dec 1, 2011 at 07:06, Matt Joiner <anacrolix@gmail.com> wrote:
I saw this, I believe it just exposes an STM primitive to user code. It doesn't make use of STM for Python internals.
That's correct.
Explicit STM doesn't seem particularly useful for a language that doesn't expose raw memory in its normal usage.
In my opinion, that sentence could not be more wrong.
It is true that, as I discuss on the blog post cited a few times in this thread, the first goal I see is to use STM to replace the GIL as an internal way of keeping the state of the interpreter consistent. This could quite possibly be achieved using the new GCC __transaction_atomic keyword, although I see already annoying issues (e.g. the keyword can only protect a _syntactically nested_ piece of code as a transaction).
However there is another aspect: user-exposed STM, which I didn't explore much. While it is potentially even more important, it is a language design question, so I'm happy to delegate it to python-dev. In my opinion, explicit STM (like Clojure) is not only *a* way to write multithreaded Python programs, but it seems to be *the only* way that really makes sense in general, for more than small examples and more than examples where other hacks are enough (see http://en.wikipedia.org/wiki/Software_transactional_memory#Composable_operat... ). In other words, locks are low-level and should not be used in a high-level language, like direct memory accesses, just because it forces the programmer to think about increasingly complicated situations.
And of course there is the background idea that TM might be available in hardware someday. My own guess is that it will occur, and I bet that in 5 to 10 years all new Intel and AMD CPUs will have Hybrid TM. On such hardware, the performance penalty mostly disappears (which is also, I guess, the reasoning behind GCC 4.7, offering a future path to use Hybrid TM).
If python-dev people are interested in exploring the language design space in that direction, I would be most happy to look in more detail at GCC 4.7. If we manage to make use of it, then we could get a version of CPython using STM internally with a very minimal patch. If it seems useful we can then turn that patch into #ifdefs into the normal CPython. It would of course be off by default because of the performance hit; still, it would give an optional alternate "CPythonSTM" to play with in order to come up with good user-level abstractions. (This is what I'm already trying to do with PyPy without using GCC 4.7, and it's progressing nicely.) (My existing patch to CPython emulating user-level STM with the GIL is not really satisfying, also for the reason that it cannot emulate some other potentially useful user constructs, like abort_and_retry().)
A bientôt,
Armin.
-- ಠ_ಠ
Hi, Actually, not even one month ago, Intel announced that its processors will offer Hardware Transactional Memory in 2013: http://www.h-online.com/newsticker/news/item/Processor-Whispers-About-Haskel... So yes, obviously, it's going to happen. A bientôt, Armin.
This is very interesting, cheers for the link. On Tue, Dec 6, 2011 at 8:55 PM, Armin Rigo <arigo@tunes.org> wrote:
Hi,
Actually, not even one month ago, Intel announced that its processors will offer Hardware Transactional Memory in 2013:
http://www.h-online.com/newsticker/news/item/Processor-Whispers-About-Haskel...
So yes, obviously, it's going to happen.
A bientôt,
Armin.
-- ಠ_ಠ
However given advances in locking and garbage collection in the last decade, what attempts have been made recently to try these new ideas out? In particular, how unlikely is it that all the thread safe primitives, global contexts, and reference counting functions be made __transaction_atomic, and magical parallelism performance boosts ensue?
I'd say that given that the current libitm implementation uses a single global lock, you're more likely to see a performance loss. TM is useful to synchronize non-trivial operations: an increment or decrement of a reference count is highly trivial (and expensive when performed atomically, as noted), and TM's never going to help if you put each refcount operation in its own transaction: see Armin's http://morepypy.blogspot.com/2011/08/we-need-software-transactional-memory.h... for more realistic use cases.
On Thu, 1 Dec 2011 01:31:14 +1100 Matt Joiner <anacrolix@gmail.com> wrote:
However given advances in locking and garbage collection in the last decade, what attempts have been made recently to try these new ideas out? In particular, how unlikely is it that all the thread safe primitives, global contexts, and reference counting functions be made __transaction_atomic, and magical parallelism performance boosts ensue?
IMHO, it sounds a bit too magical to be true.
I'm aware that C89, platforms without STM/GCC, and single threaded performance are concerns. Please ignore these for the sake of discussion about possibilities.
I find it interesting that the only example of hardware transactional memory mentioned in this page is a Sun CPU project which has been cancelled. Does Intel have anything similar in the works? Regards Antoine.
However given advances in locking and garbage collection in the last decade, what attempts have been made recently to try these new ideas out?
If that's the question you want an answer to, it would have been better had you listed the efforts that you are already aware of. If you really are unaware of any effort, try googling to find http://www.kamaelia.org/STM http://peak.telecommunity.com/DevCenter/TrellisSTM http://bugs.python.org/issue12850 http://dl.acm.org/citation.cfm?id=1978911 http://www-sal.cs.uiuc.edu/~zilles/papers/python_htm.dls2006.pdf and more Regards, Martin
participants (8)
-
"Martin v. Löwis" -
Antoine Pitrou -
Armin Rigo -
Benjamin Peterson -
Charles-François Natali -
Gregory P. Smith -
Matt Joiner -
Nick Coghlan