bit-tech.net

Intel's Haswell brings transactional memory tech

Intel's Haswell brings transactional memory tech

Intel's Haswell architecture is going to bring a supercomputing technology to the desktop: transactional memory.

Intel has released further details of its next-next generation processor architecture, Haswell, and its transaction memory functionality.

Due to take over from the yet-to-be-released Ivy Bridge, Haswell will be constructed on the same process size but with a new microarchitecture. The company has previously detailed some of the improvements that will bring, including the Haswell New Instructions, but this week's announcement is something a bit special.

Dubbed Transaction Synchronisation Extensions, or TSX, the technology provides extensions to the processor's instruction set that allows programmers to specify particular regions of code as suitable for transactional synchronisation.

As Intel's James Reinders puts it in his blog post on the matter: 'With transactional synchronisation, the hardware can determine dynamically whether threads need to serialise through lock-protected critical sections, and perform serialisation only when required. This lets the processor expose and exploit concurrency that would otherwise be hidden due to dynamically unnecessary synchronisation.'

Code engineered to take advantage of TSX could prove pretty nippy. Reinders explains that if the programmer has done his or her job correctly and the transactional execution completes successfully, all memory operations performed in that code segment will appear to have occurred instantaneously from the perspective of other processors in the system.

The technology works in a similar way to a transactional database: operations can be performed in isolation, making it possible for a multicore processor to run code more efficiently. Like a database, it's also possible to roll back a transaction if necessary, while TSX promises to do away with the requirement to lock resources during computation in order to prevent modification by other process threads.

Put simply: with TSX, Intel promises, coders will be able to push their workloads onto multiple processing cores without worrying about complex and performance-sapping fine-grain locking techniques.

Transactional memory isn't new. IBM's BlueGene/Q supercomputer uses a very similar method, while other HPC platforms have their own implementations. TSX will mark the first time that transactional memory technology has been available at a consumer level, however, and it holds the potential to be a significant disruptive influence in the multithreading arena.

Sadly, as with any new instruction set, it could be a while before consumers start to see the benefit. With Haswell due to launch in 2013, expect a teething period of a year or two for developers to figure out the best ways to implement TSX in their own applications.

10 Comments

Discuss in the forums Reply
r3loaded 9th February 2012, 16:30 Quote
Another clever thing about this tech is that it's backwards compatible with existing software that uses locks for safe concurrency. The thread will believe it has an exclusive lock on the data, but the system will actually allow another thread access to the data in a transactional manner. This'll allow a speed improvement in cases where thread #1 is modifying the data, but thread #2 is only reading it or modifying a non conflicting part of it. Of course, software written with transactions in mind will run even better.

Sent from my GT-I9000 using Tapatalk
DbD 9th February 2012, 16:41 Quote
From what I can tell this is just a very low level somewhat restrictive read/write lock. Except instead of waiting for a write lock everything just runs at once and the one that commits the finished operation back to memory first gets to do it, the others then finish, get told they failed and have to start again.

Hence it seems very computensively expensive as before if 6 processes all wanted a write lock 5 would wait and one would do it's work. Now all 6 go for it, but 5 have to abort and start all over again.
schmidtbag 9th February 2012, 19:14 Quote
if we're going to have features that are incompatible with current software, personally i'd rather go with amd's route of using a fused cpu and gpu rather than TSX. i'd like to know how much of a difference tsx makes, because i feel like certain tasks won't benefit from this at all.
azrael- 9th February 2012, 20:30 Quote
I'd like to refer you to Andreas Stiller's article from December 2011. In a nutshell, with future many core CPUs transactional memory isn't a "nice-to-have" feature but more of a "must-have" feature.

PS: You can read the original German version here.
b1candy 9th February 2012, 21:40 Quote
Quote:
Originally Posted by schmidtbag
if we're going to have features that are incompatible with current software, personally i'd rather go with amd's route of using a fused cpu and gpu rather than TSX. i'd like to know how much of a difference tsx makes, because i feel like certain tasks won't benefit from this at all.

How can you program for extensions you don't even know about yet?
Like SSE/SSE2, it made a difference when programmers started coding for it. It didn't help straight away on legacy software. And it only helps if the situation warrants it. You can't just go around implementing everything on everything - these functions have specific tasks, not a catch all situation.
Buddidge 9th February 2012, 22:59 Quote
if it does to cpu's as it did databases then this could be epic.

sent from my keyboard using my fingers! :-P
Gradius 10th February 2012, 01:02 Quote
There is any "demo" (simulated is ok) around?
r3loaded 10th February 2012, 09:53 Quote
Quote:
Originally Posted by Gradius
There is any "demo" (simulated is ok) around?
I'm sure Intel will demo it at an engineering conference once their Haswell chips are ready to be shown to the world.
Risky 10th February 2012, 16:58 Quote
Quote:
Originally Posted by schmidtbag
if we're going to have features that are incompatible with current software, personally i'd rather go with amd's route of using a fused cpu and gpu rather than TSX. i'd like to know how much of a difference tsx makes, because i feel like certain tasks won't benefit from this at all.

I'm not sure I see the point here. This doesn't preclude a CPU/GPU at all.

And yes certain talks won't benefit from it but that appliest to almost and particular element of processor technologyn
fluxtatic 12th February 2012, 05:57 Quote
Quote:
Originally Posted by schmidtbag
if we're going to have features that are incompatible with current software, personally i'd rather go with amd's route of using a fused cpu and gpu rather than TSX. i'd like to know how much of a difference tsx makes, because i feel like certain tasks won't benefit from this at all.

You missed it - it isn't incompatible. There is a still a fallback to the current lock mechanisms. The question is, with as much software that remains unupdated as far as threading goes around, how long will we have to wait for software that can take full advantage of this? If the procs aren't due to drop 'til 2013, it'll be 2020 before we see mainstream software that can take advantage of this (assuming it isn't deemed a failure and dropped in the arch that follows Haswell.)
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.



Discuss in the forums