5 ms·

For those wondering, the TSX instruction set is http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions http://en.wikipedia.org/wiki/Transactional

by mrb 12y ago

For those wondering, the TSX instruction set is http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions http://en.wikipedia.org/wiki/Transactional_Synchronization_E... I first heard about transactional memory when Sun had plans to implement it for its UltraSPARC Rock processor. There is a decent overview of the concept at http://en.wikipedia.org/wiki/Transactional_memory http://en.wikipedia.org/wiki/Transactional_memory

mnarayan01 12y ago
The techreport.com article says: The obvious initial targets for TSX optimization are server-class applications like transactional database servers. Looking at your wiki links though, I would think this would be awesome for almost any high-performance multi-threaded program. Am I wrong about that?
- sdab 12y ago
  In theory yes, though thinking in terms of transactions is subtly different from thinking in terms of threading critical sections. Particularly, they differ in how they handle contention. Locks block while transactions abort/fail. Simply retry-ing a transaction is also not a good idea which is why it is currently suggested to fallback on locks [1]. So I assume the suggestion of using it for dbs is because it would be more straight-forward as dbs are already used to transactions. 1. https://software.intel.com/en-us/blogs/2013/06/23/tsx-fallback-paths https://software.intel.com/en-us/blogs/2013/06/23/tsx-fallba...
- colanderman 12y ago
  The idea with HLE at least, was that anywhere you had a highly contended lock that protected not-highly-write-contended data, it was a drop-in performance boost. Really sucks that they had to pull the plug on it.
- blt 12y ago
  It won't make any difference if the load is embarrassingly parallel, like rendering one frame of video per core. In those cases the amount of independent work is huge compared to time spent dealing with locks.
sdab 12y ago
As a systems guy who was intially very skeptical of Transactional Memory, I've been very excited about TSX for a while. Unfortunately, it seems that the initial implementation in the haswell processors wasnt very efficient[1]. Im looking forward to future hardware implementations by intel. 1. http://natsys-lab.blogspot.ru/2013/11/studying-intel-tsx-performance.html http://natsys-lab.blogspot.ru/2013/11/studying-intel-tsx-per...
- hendzen 12y ago
  As someone who has used TSX to optimize synchronization primitives, you can expect to see a ~15-20% performance increase, if (big if) your program is heavy on disjoint data access, i.e. a lock is needed for correctness, but conflicts are rare in practice. If you have a lot of threads frequently writing the same cache lines, you are probably going to see worse performance with TSX as opposed to traditional locking. It helps to think about TSX as transparently performing optimistic concurrency control, which is actually pretty much how it is implemented under the hood. While the API of TSX (_xbegin(), _xabort(), _xend()) gives the appearance of implementing transactional memory, it is really an optimized fast path - the abort rate will determine performance. The technical term for what TSX actually implements is 'Hardware Lock Elision'. If you are going to use TSX, don't use it directly unless you are writing your own primitives (i.e. transactional condition variables [0]), prefer using Andi Kleene's TSX enabled glibc [1] or the speculative_spin_mutex [2] in TBB. [0] - http://transact09.cs.washington.edu/9_paper.pdf http://transact09.cs.washington.edu/9_paper.pdf [1] - https://github.com/andikleen/glibc https://github.com/andikleen/glibc [2] - http://www.threadingbuildingblocks.org/docs/doxygen/a00248.html#ga69722571e9e4406693c4a1379f0b47eb http://www.threadingbuildingblocks.org/docs/doxygen/a00248.h...
  - sdab 12y ago
    Thanks for the links. Im aware of Andi's work and enjoy reading his posts on TSX. You're absolutely right about HLE vs HTM. Mostly I wish there was a better fallback than locking when transactions fail, but I suppose this is more in line with thinking of them as optimistic locks (such as what I assume the speculative spin lock does).
  - 12y ago
lelf 12y ago
And it was the only widespread TM implementation in metal. So N years more till we see software transactional memory with dedicated hardware support.
- wahern 12y ago
  Strong LL/SC provides the ability to do real software transactional memory. I believe ARM has the strongest LL/SC implementation, with the architecture supporting transaction blocks up to 2KB in size! Although ARM has specified LL/SC such that vendors can choose to only support blocks much smaller than 2KB. Note that people have totally confused the terms. Originally "software transactional memory" meant using primitives like [strong] LL/SC to get lock-free, wait-free algorithms. Strong LL/SC has been proven to be a universal primitive which can be used to implement most known lock-free, wait-free algorithms. "Hardware transactional memory" gave you access to lock-free, wait-free algorithms in a much more convenient manner. But really it's a difference of degree because strong LL/SC requires _significant_ hardware support. These days people (like the PyPy project and most STM libraries) use "software transactional memory" for implementations which just use a mutex under the hood. It's emulated STM; they're just being fanciful. I believe TSX is more like strong LL/SC. Maybe stronger. OTOH I'm not sure if it's universal enough to implement wait-free algorithms.
- tedunangst 12y ago
  More like N more months. They say they've already fixed it.
fmstephe 12y ago
There has been a CPU with transactional memory running big business servers. The Vega boxes from Azuul (~800 cores) running their JVMs. I know of two good internet discussions available talking about their real world experience using them Gil Tene https://groups.google.com/forum/#!searchin/mechanical-sympathy/transactional$20memory/mechanical-sympathy/f84bwRQpyTQ/Ncc5gGz29xkJ https://groups.google.com/forum/#!searchin/mechanical-sympat... Cliff Click http://www.azulsystems.com/blog/cliff/2009-02-25-and-now-some-hardware-transactional-memory-comments http://www.azulsystems.com/blog/cliff/2009-02-25-and-now-som... It can be enlightening to hear from a real application of these technologies. I am sad to see it disabled. Had it in the back of my head to play around with it some time.
- Marat_Dukhan 12y ago
  PowerPC A2 (Blue Gene/Q) and POWER 8 support hardware transactional memory as well
  - fmstephe 12y ago
    It's such a shame. The Intel one is our best chance to get HTM under my desk. Alas :)
- Alupis 12y ago
  > Some of the savviest software developers are likely building TSX-enabled software right about now. Really a non-statement statement. The only people who are using CPU instructions in their code will be low level maintainers, ie. kernel devs and other OS devs. So this doesn't effect really anyone except those folks (and of course the benefits it may have provided up the stack via layers of abstractions).
  - fmstephe 12y ago
    The finance sector produces a lot of low level code driving business applications directly. But, broadly you are right I think.
  - dakull 12y ago

by mrb 12y ago

mnarayan01 12y ago

The techreport.com article says: The obvious initial targets for TSX optimization are server-class applications like transactional database servers. Looking at your wiki links though, I would think this would be awesome for almost any high-performance multi-threaded program. Am I wrong about that?

sdab 12y ago
In theory yes, though thinking in terms of transactions is subtly different from thinking in terms of threading critical sections. Particularly, they differ in how they handle contention. Locks block while transactions abort/fail. Simply retry-ing a transaction is also not a good idea which is why it is currently suggested to fallback on locks [1]. So I assume the suggestion of using it for dbs is because it would be more straight-forward as dbs are already used to transactions. 1. https://software.intel.com/en-us/blogs/2013/06/23/tsx-fallback-paths https://software.intel.com/en-us/blogs/2013/06/23/tsx-fallba...
colanderman 12y ago
The idea with HLE at least, was that anywhere you had a highly contended lock that protected not-highly-write-contended data, it was a drop-in performance boost. Really sucks that they had to pull the plug on it.
blt 12y ago
It won't make any difference if the load is embarrassingly parallel, like rendering one frame of video per core. In those cases the amount of independent work is huge compared to time spent dealing with locks.

sdab 12y ago

As a systems guy who was intially very skeptical of Transactional Memory, I've been very excited about TSX for a while. Unfortunately, it seems that the initial implementation in the haswell processors wasnt very efficient[1]. Im looking forward to future hardware implementations by intel. 1. http://natsys-lab.blogspot.ru/2013/11/studying-intel-tsx-performance.html http://natsys-lab.blogspot.ru/2013/11/studying-intel-tsx-per...

hendzen 12y ago
As someone who has used TSX to optimize synchronization primitives, you can expect to see a ~15-20% performance increase, if (big if) your program is heavy on disjoint data access, i.e. a lock is needed for correctness, but conflicts are rare in practice. If you have a lot of threads frequently writing the same cache lines, you are probably going to see worse performance with TSX as opposed to traditional locking. It helps to think about TSX as transparently performing optimistic concurrency control, which is actually pretty much how it is implemented under the hood. While the API of TSX (_xbegin(), _xabort(), _xend()) gives the appearance of implementing transactional memory, it is really an optimized fast path - the abort rate will determine performance. The technical term for what TSX actually implements is 'Hardware Lock Elision'. If you are going to use TSX, don't use it directly unless you are writing your own primitives (i.e. transactional condition variables [0]), prefer using Andi Kleene's TSX enabled glibc [1] or the speculative_spin_mutex [2] in TBB. [0] - http://transact09.cs.washington.edu/9_paper.pdf http://transact09.cs.washington.edu/9_paper.pdf [1] - https://github.com/andikleen/glibc https://github.com/andikleen/glibc [2] - http://www.threadingbuildingblocks.org/docs/doxygen/a00248.html#ga69722571e9e4406693c4a1379f0b47eb http://www.threadingbuildingblocks.org/docs/doxygen/a00248.h...
- sdab 12y ago
  Thanks for the links. Im aware of Andi's work and enjoy reading his posts on TSX. You're absolutely right about HLE vs HTM. Mostly I wish there was a better fallback than locking when transactions fail, but I suppose this is more in line with thinking of them as optimistic locks (such as what I assume the speculative spin lock does).
- 12y ago

lelf 12y ago

And it was the only widespread TM implementation in metal. So N years more till we see software transactional memory with dedicated hardware support.

wahern 12y ago
Strong LL/SC provides the ability to do real software transactional memory. I believe ARM has the strongest LL/SC implementation, with the architecture supporting transaction blocks up to 2KB in size! Although ARM has specified LL/SC such that vendors can choose to only support blocks much smaller than 2KB. Note that people have totally confused the terms. Originally "software transactional memory" meant using primitives like [strong] LL/SC to get lock-free, wait-free algorithms. Strong LL/SC has been proven to be a universal primitive which can be used to implement most known lock-free, wait-free algorithms. "Hardware transactional memory" gave you access to lock-free, wait-free algorithms in a much more convenient manner. But really it's a difference of degree because strong LL/SC requires _significant_ hardware support. These days people (like the PyPy project and most STM libraries) use "software transactional memory" for implementations which just use a mutex under the hood. It's emulated STM; they're just being fanciful. I believe TSX is more like strong LL/SC. Maybe stronger. OTOH I'm not sure if it's universal enough to implement wait-free algorithms.
tedunangst 12y ago
More like N more months. They say they've already fixed it.

fmstephe 12y ago

There has been a CPU with transactional memory running big business servers. The Vega boxes from Azuul (~800 cores) running their JVMs. I know of two good internet discussions available talking about their real world experience using them Gil Tene https://groups.google.com/forum/#!searchin/mechanical-sympathy/transactional$20memory/mechanical-sympathy/f84bwRQpyTQ/Ncc5gGz29xkJ https://groups.google.com/forum/#!searchin/mechanical-sympat... Cliff Click http://www.azulsystems.com/blog/cliff/2009-02-25-and-now-some-hardware-transactional-memory-comments http://www.azulsystems.com/blog/cliff/2009-02-25-and-now-som... It can be enlightening to hear from a real application of these technologies. I am sad to see it disabled. Had it in the back of my head to play around with it some time.

Marat_Dukhan 12y ago
PowerPC A2 (Blue Gene/Q) and POWER 8 support hardware transactional memory as well
- fmstephe 12y ago
  It's such a shame. The Intel one is our best chance to get HTM under my desk. Alas :)
Alupis 12y ago
> Some of the savviest software developers are likely building TSX-enabled software right about now. Really a non-statement statement. The only people who are using CPU instructions in their code will be low level maintainers, ie. kernel devs and other OS devs. So this doesn't effect really anyone except those folks (and of course the benefits it may have provided up the stack via layers of abstractions).
- fmstephe 12y ago
  The finance sector produces a lot of low level code driving business applications directly. But, broadly you are right I think.
- dakull 12y ago