4 ms·

Interesting, do you have a link to the documentation for this (or even a paper describing the design)? Does Clang/LLVM have something similar? I wonder would ad

Interesting, do you have a link to the documentation for this (or even a paper describing the design)? Does Clang/LLVM have something similar? I wonder would adding STM to Rust be more practical in terms of performance (or does the question even make sense given it already guarantees data race freedom)?

arghnoname 4y ago
There's an Intel ABI specification that GCC closely follows. The gcc implementation is called libitm and their specification is just listed as a diff of intel's specification. Here is gcc's doc on libitm https://gcc.gnu.org/onlinedocs/libitm/ https://gcc.gnu.org/onlinedocs/libitm/ Here is intel's document (much more useful): https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFile&do=get&target=Intel-TM-ABI-1_1_20060506.pdf https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFi... I'm not sure what the support story is like on clang.
gpderetta 4y ago
A few years ago it seemed that every cpu architecture was going to get hardware transactional memory acceleration. SPARC had it, POWER had it, even Intel added it. A transactional memory proposal for C++ made it into a Technical Report, it got implemented in GCC and it seemed to be ready to be merged into the standard. Then I'm not sure what happened, things seem to have run out of steam, Intel never managed to make its HTM to work well and it unofficially deprecated it and generally TM went out of fashion. The TR is still there and gets minor updates, but I haven't heard about any push to merge it.
- jdougan 4y ago
  As I understand it, a bunch of people became less convinced of TM's usefulness eg. http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/ http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-...
  - anonymousDan 4y ago
    Thanks a lot for that, very interesting perspective (particularly the challenges with unbounded transactions and nontransactional I/O). It makes me wonder (i) whether bounded transactions were also found to be too hard to use (given restrictions on transaction sizes) (ii) what has replaced STM in terms of better fine-grained concurrency control abstractions (if anything). Maybe better type system support through new languages (e.g. Rust)?
    - jdougan 4y ago
      I am not familiar with any details, but the haskellians seem to still be working with STM. At least there are a bunch on talks online about it. I had spent most of the 90s working with transactional systems and while they are useful and powerful, they aren't magic and require awareness to keep from making errors. Joe Duffy wasn't wrong when he says those problems are well known. The solutions normally are either Don't Do That Then, or managing the policy details and logic yourself, which wasn't giving them the easy concurrency they were trying for. Edit: He has a followup post at http://joeduffyblog.com/2010/05/16/more-thoughts-on-transactional-memory/ http://joeduffyblog.com/2010/05/16/more-thoughts-on-transact...

arghnoname 4y ago

There's an Intel ABI specification that GCC closely follows. The gcc implementation is called libitm and their specification is just listed as a diff of intel's specification. Here is gcc's doc on libitm https://gcc.gnu.org/onlinedocs/libitm/ https://gcc.gnu.org/onlinedocs/libitm/ Here is intel's document (much more useful): https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFile&do=get&target=Intel-TM-ABI-1_1_20060506.pdf https://gcc.gnu.org/wiki/TransactionalMemory?action=AttachFi... I'm not sure what the support story is like on clang.

gpderetta 4y ago

A few years ago it seemed that every cpu architecture was going to get hardware transactional memory acceleration. SPARC had it, POWER had it, even Intel added it. A transactional memory proposal for C++ made it into a Technical Report, it got implemented in GCC and it seemed to be ready to be merged into the standard. Then I'm not sure what happened, things seem to have run out of steam, Intel never managed to make its HTM to work well and it unofficially deprecated it and generally TM went out of fashion. The TR is still there and gets minor updates, but I haven't heard about any push to merge it.

jdougan 4y ago
As I understand it, a bunch of people became less convinced of TM's usefulness eg. http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/ http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-...
- anonymousDan 4y ago
  Thanks a lot for that, very interesting perspective (particularly the challenges with unbounded transactions and nontransactional I/O). It makes me wonder (i) whether bounded transactions were also found to be too hard to use (given restrictions on transaction sizes) (ii) what has replaced STM in terms of better fine-grained concurrency control abstractions (if anything). Maybe better type system support through new languages (e.g. Rust)?
  - jdougan 4y ago
    I am not familiar with any details, but the haskellians seem to still be working with STM. At least there are a bunch on talks online about it. I had spent most of the 90s working with transactional systems and while they are useful and powerful, they aren't magic and require awareness to keep from making errors. Joe Duffy wasn't wrong when he says those problems are well known. The solutions normally are either Don't Do That Then, or managing the policy details and logic yourself, which wasn't giving them the easy concurrency they were trying for. Edit: He has a followup post at http://joeduffyblog.com/2010/05/16/more-thoughts-on-transactional-memory/ http://joeduffyblog.com/2010/05/16/more-thoughts-on-transact...