Haswell to offer new extensions for transactional synchronization

Ivy Bridge isn’t yet out the door, but Intel is already talking about more enhancements coming in Haswell. The next-generation chip will bring a new microarchitecture and, according to this blog post, a set of Transactional Synchronization Extensions dubbed TSX. The instructions are designed to simplify programming for developers working on multithreaded applications, which must lock sections of memory to ensure that data being manipulated by one thread isn’t modified by another. Intel’s James Reinders explains:

These extensions can help achieve the performance of fine-grain locking while using coarser grain locks. These extensions can also allow locks around critical sections while avoiding unnecessary serializations. If multiple threads execute critical sections protected by the same lock but they do not perform any conflicting operations on each other’s data, then the threads can execute concurrently and without serialization. Even though the software uses lock acquisition operations on a common lock, the hardware is allowed to recognize this, elide the lock, and execute the critical sections on the two threads without requiring any communication through the lock if such communication was dynamically unnecessary.

Reinders goes into more detail in a subsequent blog post. I’m not a programmer, but it looks like Haswell is capable of determining when it’s safe for incoming threads to ignore the locks imposed by other threads. This should allow more threads to be executed in parallel, at least for applications relying on coarse locking techniques. Coarse locking is easier to implement than fine-grained locks, Intel says.

Applications will have to be modified to take advantage of TSX. Two options are available: developers who want to retain compatibility with non-TSX hardware can use the Hardware Lock Elision instruction set, while those who want more flexibility can use the Restricted Transactional Memory instruction set. The latter requires an alternate code path for hardware that doesn’t support TSX instructions. If you want more information on TSX, check out chapter 8 of Intel’s programming reference (PDF).

Comments closed
    • ronch
    • 8 years ago

    I’m surprised – and skeptic – to read here that Haswell will have a new microarchitecture. I think it’s gonna be more like an evolution of the Sandy/Ivy Bridge microarchitecture.

      • OneArmedScissor
      • 8 years ago

      It’s still Core-derived. While there are undoubtedly tweaks to the core that every CPU will share, like these new extensions, the big difference for PCs lies in what changes in the rest of the chip.

      Nehalem has L3 cache and (sometimes) an integrated memory controller and PCIe controller. Sandy Bridge has synchronized L3 cache and system bus clocks and integrated graphics. Haswell has a larger cache system and an integrated voltage regulator.

      It’s the same trend since the “tick-tock” thing started.

    • tfp
    • 8 years ago

    This seems like a feature that would be useful for drivers and embedded products. I wonder how long it will take to filter it’s way down.

    • Vulk
    • 8 years ago

    OMG… A feature that will only be useful if every Haswell CPU has them, and everyone only has Hasweel or later CPUs… So as a programmer I’ll need to worry about learning how to do Restricted Transactional Memory IS… never?

      • Mime
      • 8 years ago

      If it wasn’t backwards compatible with existing code, then yeah.. probably. HLE is though, or will be once support has been added for the new instructions. It’s just RTM that requires new code.

      • BobbinThreadbare
      • 8 years ago

      Is this something you need to learn, or is it something that can be done by a complier if you’re using course thread locking?

        • Mime
        • 8 years ago

        It sounds like a little of both depending on what kind of lock you need. HLE should be backwards compatible with existing code as soon as compilers start using the new XACQUIRE and XRELEASE instructions. RTM allows for a fallback path if the transaction fails which is something that will require new code to be written.

      • chuckula
      • 8 years ago

      Vulk tripped and fell into a time machine to the year…. 1985!! Here’s what he said when he stepped out of the machine:

      OMG… 32 Bit memory access! A feature that will only be useful if every i386 CPU has them, and everyone only has i386 or later CPUs… So as a programmer I’ll need to worry about learning how to do 32 bit instructions… never?

      • HisDivineOrder
      • 8 years ago

      In a few years, I’m sure post-Haswell tech will be more prevalent and the uses will be more prevalent as well.

    • jensend
    • 8 years ago

    I would think that OS kernels, which do [url=http://james.bond.edu.au/courses/inft73626@033/Assigs/Papers/kernel_locking_techniques.html<]all kinds of locking all over the place[/url<], could benefit from this even if user space applications aren't rewritten. Anybody with more insight have an opinion on that?

    • khands
    • 8 years ago

    Sounds like something Bulldozer really, really needed.

      • NeelyCam
      • 8 years ago

      Don’t worry. AMD will copy this soon, just like they do with pretty much all other brilliant Intel ideas. I’m just excited to see what kind of a cool almost-like-TSX acronym they come up with this time.

        • chuckula
        • 8 years ago

        Come on Neely… don’t “rise” to the level of the competition here. AMD will likely implement transactional memory, but it’ll take a little while (maybe Steamroller?)

        Both Intel & AMD have copied features from each other for a long time and I won’t insult AMD for using a good idea just like I don’t let AMD fanboys claim that Intel stole everything from them.

          • NeelyCam
          • 8 years ago

          I’ve been on this for a while, ever since AMD fanbois claimed Intel stole 64b, HyperTransport and on-chip memory controllers from AMD.

          I know everyone copies everything, and the only thing that matters is who does it better (which is Intel). But AMD fanboi double standard just annoys me too much to let this opportunity pass by. What did UberGerbil say? If you give crap, you’re gonna get crap, and it takes a while before you’re forgiven.

          Also, I have trouble filling my troll quota at S|A, because the AMD fanbois there are so delusional that I can’t get a decent debate even started.

            • Lans
            • 8 years ago

            Funny way of showing:
            [quote<]only thing that matters is who does it better[/quote<]

            • NeelyCam
            • 8 years ago

            You missed this:

            [quote<]But AMD fanboi double standard just annoys me too much to let this opportunity pass by. [/quote<]

        • kalelovil
        • 8 years ago

        Actually, AMD has been working on an equivalent by themselves for quite a while: [url<]http://developer.amd.com/tools/ASF/Pages/default.aspx[/url<] The problem is that while you only control 10-15% of the market it is difficulty to unilaterally push an extension to x86. AMD's x64 was only successful because it had Microsoft's backing and Intel was still doggedly obsessed with IA64, while AMD SIMD extensions such as 3DNOW, SSE4a and FMA4 have not gained the prevalence of their Intel equivalents.

          • MadManOriginal
          • 8 years ago

          So AMD works on something for almost 3 years so far, and Intel, by implementing it first, will actually make it matter. Regardless of market share AMD could have implemented it first, there should have been plenty of time to put this into Bulldozer, but they didn’t.

            • jensend
            • 8 years ago

            Major ISA changes take time, and this is a good thing. When you consider the development cycle of a CPU (remember, tapeout happens a [i<]long[/i<] time before stuff hits retail, you realize that the only way AMD would have had this in Bulldozer was if it was thrown in quite quickly after the idea surfaced, with the result that we would have had another half-baked mess of incompatible ISA extensions. Haswell is still almost a year and a half away. As much as I'm sure hardware transactional memory will be a great boon for a lot of situations, I'm glad people are trying to take the time to get it right.

        • Grigory
        • 8 years ago

        It should be made illegal for you to use any computer with an AMD64 ISA.

          • NeelyCam
          • 8 years ago

          Should it be made illegal for you to use any computer employing Turbo? Power Gates? HKMG transistors? Strain-engineered transistors?

            • Grigory
            • 8 years ago

            Do I spew fanboy hatred in any particular direction?

            Edit: Except in yours. 😀

            • NeelyCam
            • 8 years ago

            Hate is such a strong emotion. I don’t hate – I just tease..

            Can’t we all just be friends? It’s Friday, after all.

        • derFunkenstein
        • 8 years ago

        TURBO CORE TXT – transaction extension type

        • HisDivineOrder
        • 8 years ago

        That’s the point of Intel and AMD sharing a license to use each other’s x86-based tech. Intel “steals” x86-64. AMD steals MMX, SSE, SSE2, SSE3, SSE(whatever), etc.

        You can generally count on any instruction set that Intel comes up with showing up in an AMD CPU down the line. In fact, I think Intel prefers it as those instruction sets generally favor their processors and give them more applications to take advantage of said enhancements.

        Intel wins, AMD wins, but Intel wins bigger. And that’s just how Intel likes it.

        • WillBach
        • 8 years ago

        Neely, let it go. I get how you feel so take from me when I say it’s healthier for you, and even if it isn’t, it makes TR look better. There are three things I want to express here:
        [list=1<] [*<]Copying ideas isn't wrong. [/*<][*<]It's better to let forum rage go. [/*<][*<]I can totally sympathize.[/*<] [/list<] [b<]To be continued[/b<] You know what, Neely, I'll flesh this out later. I have a ridiculous head cold right now. Just trust that as a person who has a degree in computer engineering and who's married to a climate scientist, the stuff that makes me want to rage quit grows faster than the speed of light on the Internet.

    • Tristan
    • 8 years ago

    Great solution from Intel. So far this is best step to better utlilize available cores. I think there will be lot of speed from these features.
    This ‘optimistic locking’ allows for easy coarse locking, but also for removing most deadlocks, which is also important.
    Let us hope that AMD will implement this as soon as possible.

      • bhassel
      • 8 years ago

      Well, since the transactional code has to fall back on regular locks when it fails (the extensions don’t guaranteed they’ll ever succeed), it seems you still have to deal with deadlock issues…

    • ImSpartacus
    • 8 years ago

    Enough to impress Krogoth?

      • chuckula
      • 8 years ago

      The beauty of transactional memory is that Krogoth can be impressed and unimpressed AT THE SAME TIME*!

      (* with the occasional collision requiring him to re-run his impressiveness code)

        • OneArmedScissor
        • 8 years ago

        …or he might just be multi-unimpressed!

        • ImSpartacus
        • 8 years ago

        I wouldn’t get your hopes up.

Pin It on Pinterest

Share This