3 ms·

whats wrong with software transactional memory?

by platz 9y ago

poopoopoopoo 9y ago
STM in Haskell is a thing of beauty
qznc 9y ago
Nobody figured out how to implement it efficiently yet.
- marcosdumay 9y ago
  Haskell's STM is not efficient?
  - platz 9y ago
    Instead of opt-in STM, perhaps he's referring to whole-program STM like when they tried to do that in C#.
  - qznc 9y ago
    Haskell is not efficient with all these thunks and memory allocations. Maybe the way Haskell does STM is efficient relatively. However, you cannot port that to C/C++/Java/C#, because they do not provide the type system to make it safe. Maybe Rust can deliver. A quick search gives me rust-stm [0]. All these disclaimers in the README looks discouraging, though. For example, "Calls to atomically should not be nested", but isn't that the whole point about composable STM? Repeating transactions is a no-go, because it does not mix well with side effects. Thus, we need a lock-everything-required scheme. You do not want to expose this in the type system, because it explodes everywhere and gets really tiresome. Thus you need a whole-world analysis to find out what is "required" for a transaction. That breaks modular compilation and is inconvenient in general. In general, I don't see how this could work even a very high level. [0] https://github.com/Marthog/rust-stm https://github.com/Marthog/rust-stm
    - platz 9y ago
      Yes, in a non-pure type system, you are "on your honor" to not cause side effects. Clojure made STM a first-class language feature despite this https://clojure.org/reference/refs https://clojure.org/reference/refs Second, the problems with impurity you listed are exactly solved by Haskell. Just because "you cannnot port that to x/y/z" language should've be counted against the haskell language. We are talking about transactions here, but you're worried about thunks and memory allocations, and comparing this to java? It seems like you've simply decided Haskell is categorically slow, regardless of the context we're talking about.

whats wrong with software transactional memory?

by platz 9y ago

whats wrong with software transactional memory?

poopoopoopoo 9y ago

STM in Haskell is a thing of beauty

qznc 9y ago

Nobody figured out how to implement it efficiently yet.

marcosdumay 9y ago
Haskell's STM is not efficient?
- platz 9y ago
  Instead of opt-in STM, perhaps he's referring to whole-program STM like when they tried to do that in C#.
- qznc 9y ago
  Haskell is not efficient with all these thunks and memory allocations. Maybe the way Haskell does STM is efficient relatively. However, you cannot port that to C/C++/Java/C#, because they do not provide the type system to make it safe. Maybe Rust can deliver. A quick search gives me rust-stm [0]. All these disclaimers in the README looks discouraging, though. For example, "Calls to atomically should not be nested", but isn't that the whole point about composable STM? Repeating transactions is a no-go, because it does not mix well with side effects. Thus, we need a lock-everything-required scheme. You do not want to expose this in the type system, because it explodes everywhere and gets really tiresome. Thus you need a whole-world analysis to find out what is "required" for a transaction. That breaks modular compilation and is inconvenient in general. In general, I don't see how this could work even a very high level. [0] https://github.com/Marthog/rust-stm https://github.com/Marthog/rust-stm
  - platz 9y ago
    Yes, in a non-pure type system, you are "on your honor" to not cause side effects. Clojure made STM a first-class language feature despite this https://clojure.org/reference/refs https://clojure.org/reference/refs Second, the problems with impurity you listed are exactly solved by Haskell. Just because "you cannnot port that to x/y/z" language should've be counted against the haskell language. We are talking about transactions here, but you're worried about thunks and memory allocations, and comparing this to java? It seems like you've simply decided Haskell is categorically slow, regardless of the context we're talking about.