4 ms·
The techreport.com article says: The obvious initial targets for TSX optimization are server-class applications like transactional database servers. Looking
by 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 agoIn 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 agoThe 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 agoIt 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.