You are not logged in.

sprezzatech blog #0003

Dirty South Supercomputers and Waffles
UNIX, HPC, cyberwarfare, and chasing perf in Atlanta.
behold a pale horse!
wed 2012-02-08 15:45:22 est
It's official, according to this post on Intel SDN: Haswell, the "tock" of mighty Ivy (née Sandy) Bridge, will feature transactional memory, while maintaining the 22nm Trigate MOSFET process (Intel goes to 14nm with Broadwell in 2014). I didn't really believe in transactional memory when it was first being kicked around; if you know where
Logo of the defunct STM.NET project
Classy! STM.NET's logo was the envy of all who knew her.
you need locking, I reasoned, just lock and be done with it. That was before I heard about Speculative Lock Elision (tip of the hat to Jesse Beu, leader of men and killer of ladies) in Prof. Tom Conte's CS8803MCA [0], and the possibilities became apparent (software transactional memory, on the other hand, was and remains a bunch of crap). If you're not yet up-to-speed on TM/STM, check out the TM-101 seminar notes from SPbSU (and, par for the course, avoid the extortionist output of the for-profit scientific press).

The Intel AVX Manual (aka the Intel® Architecture Instruction Set Extensions Programming Reference) has been updated as of 2012-02 to include the new interfaces (collectively known as Intel TSX (aka Intel® Transactional Synchronization Extensions)). The following data are summarized from §8.2 of Intel Ref. № 319433-012: Nested transactions are supported as a single monolithic transaction (an abort restores state at the outermost XACQUIRE-prefixed HLE or XBEGIN instruction). Unfortunately, the nesting is subject to an implementation-defined limit (referred to as MAX_HLE_ELIDED_LOCKS in the Reference), unavailable to application code and not even published in the Reference, at which point the transaction may abort. Argh, not cool! Handling the myriad abort codes will be a minor pain for low-level implementors. Here's a fun game: design a sensible API (assume C++-style exceptions) around Table 8-1:

EAX bitsMeaning
0Set if abort caused by XABORT instruction.
1If set, the transaction may succeed on a retry. This bit is always clear if bit 0 is set.
2 Set if another logical processor conflicted with a memory address that was part of the transaction that aborted.
3 Set if an internal buffer overflowed.
4 Set if a debug breakpoint was hit.
5 Set if an abort occurred during execution of a nested transaction.
23:6 Reserved.
31:24 XABORT argument (only valid if bit 0 set, otherwise reserved).

Overall, it seems pretty well-designed. Either way, yet another fun new development from the 256-bit AVX instructions!
  1. Prof. David Bader appears to be teaching the class next; here's his 2007 syllabus. From what I can tell, our instance covered a lot more VLSI, optimizing compilation, and true manycore.