This is very interesting, cheers for the link.
On Tue, Dec 6, 2011 at 8:55 PM, Armin Rigo 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-
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-Haskell-and-Haswell-1389507.html
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?
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 u
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
Hi,
On Thu, Dec 1, 2011 at 07:06, Matt Joiner 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 n
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 wrote:
> On Thu, Dec
On Thu, Dec 1, 2011 at 10:58 AM, Gregory P. Smith 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 ove
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
searchi
On Thu, 1 Dec 2011 01:31:14 +1100
Matt Joiner 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
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 wrote:
> 2011/11/30 Matt Joiner :
>> 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
> 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_ato
2011/11/30 Matt Joiner :
> 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 ba
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 gr
13 matches
Mail list logo
