4 ms·
You don't need to copy immutable values.
by ranit 9y ago
You don't need to copy immutable values.
- 1ris 9y agoI feel that immutable (almost) everything is good thing for multi-threaded programming and programming in general.
- agumonkey 9y agotook decades and hardware capabilities for mainstream to realize that immutability can be extremely good for 1) people reasoning 2) machine execution.
- pron 9y agoImmutability is quite the opposite of good for machine execution. Much of modern CPU architecture is based on the idea of memory locality, and that you'd be reusing the same memory addresses in a given unit of work. Also, immutability helps people reason when the language doesn't have a clock. If the language does have a clock -- i.e. it is synchronous, like Eve or Céu -- mutability poses no difficulty.
- laythea 9y agoIf you don't copy it and don't wait on any synchronisation mechanisms, how do you protect the memory?
- kccqzy 9y agoYou don’t need to protect it if every thread only ever reads it without writing.
- laythea 9y agoSomeone writes to it. And if they write before the read threads are run (and never again), then this is not really equivalent to the complexity we imagine when we say complexity in the context of multi-threading.
- kccqzy 9y agoYou are misunderstanding me. When I said no thread ever writes to it, I truly mean no one. There’s not a possibility of “someone writing to it.” And I think you also have a very narrow view of multi-threading. Shared memory, mutable-everything isn’t the only way of doing multi-threading (or more precisely concurrency). This very article is trying to introduce to you a new way of doing concurrency that doesn’t involve mutable variables shared between threads.
- millstone 9y agoIt makes no sense to choose immutable values for the multithreading performance benefit. You can usually get a much larger benefit from using a single threaded mutable implementation. For example, a mutable hash table will outperform a persistent hash-tries for updates. (Of course there are good reasons for using immutable values; performance is just not one of them.) Swift collections are logically immutable but may mutate under the hood if there is a unique owner. This conceptually provides a best-of-both-worlds, but a downside is that the language does not provide much help to enforce single-owner (yet).