5 ms·

Immutability is slow, so if you are somebody squeezing the maximum FLOPS out of a CPU, you might want to stay away (sorry, 1.3x slowdown in your best case is no

by bitL 4y ago

Immutability is slow, so if you are somebody squeezing the maximum FLOPS out of a CPU, you might want to stay away (sorry, 1.3x slowdown in your best case is not acceptable, and "leave it out to the compiler" is not a valid argument). It's like with project management - the iron triangle of speed, quality, price, pick two. With each programming paradigm you pick a different set of attributes that might or might not be the best for what you need and they enable you on one thing and constrain you on another thing.

duped 4y ago
Immutability is an API not an implementation. Immutable code often outperforms mutable, it depends on the use case.
- bitL 4y ago
  There is often some "redefinition of terms" going on with dedicated functional programming folks in order to assert their claims as you just demonstrated. There was some benchmark where mutable Java was shown to be around 30x faster than immutable OCaml and the discussion went to something like "no, no, that's a wrong comparison, compare it with immutable vs mutable OCaml, that is then just 2x slower! And the next compiler revision will remove it! 100% sure about it!" etc. Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong.
  - mrkeen 4y ago
    Awesome, I'd love to read it!
  - freedomben 4y ago
    > Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong. Why do you think GP is saying or doing that? I think you've put a lot of words into their mouth that aren't there, and then got yourself worked up about it, enough to accuse them of ignorance and small-mindedness (at best). I see absolutely nothing in their comment that even weighs in favor of FP, let alone saying other modes of thinking can't coexist. For all we know GP is a rabid OOP fan but sees the value in immutability (which FP certainly does not have a monopoly on).
    - bitL 4y ago
      OK, my apologies, that comes as a baggage from previous discussions with FP experts that routinely dismissed any opposing ideas and the OP's answer struck the same chord.
  - duped 4y ago
    Sorry I don't mean to sound like an evangelist, I just meant that there are misconceptions out there about immutable data structures (functional programming aside: the two are not so intimately involved that they're equivalent). I hope you can understand why benchmarking OCaml against Java isn't necessarily fair, since they have two completely different implementations (the latter being possibly the most mature set of JIT compilers and runtimes ever built). A more interesting comparison are immutable DAs in languages like C++, for example the immer library which has some very impressive performance characteristics for the problems it solves. And other applications like immutable ropes used in text editors which have extremely high performance compared to mutable variations. At the same time it's not a silver bullet, plenty of other immutable DAs have issues that are non-negligible and applications domains where in-place mutable DSs are required like hard-realtime. Software engineering is about tradeoffs and not dogma, and that's what I was getting at. A take like "immutable is slow" is the counter dogma to "immutable is perfect."
freedomben 4y ago
Immutability can be fast or slow depending on the implementation. There are tons of copy-on-write implementations that blaze past mutable implementations. When the compiler knows that a particular variable/piece of data will never be changed, it opens up a ton of optimizations that can be used to make it fast. With mutable memory it's on the developer to optimize, rather than the compiler. Most of the time, the latter is better at it.
- guelo 4y ago
  The problem is that developer has no idea if the implementation is going to be performant for their use case. The mutable compilers normally have less magic and thus are easier for the developer to understand and optimize. FP is really just a higher level language, that's why they don't teach algorithms classes using FP languages.
- bitL 4y ago
  With infinite memory and "no cost memory allocation" you'll be likely correct, but in real world production loads you'll hit those limits quickly and then the immutability is likely getting in the way. Imagine just keeping a large (possibly compressed) bitmap (TBs in memory) to keep track of subscribers in your queue which is what many distributed queues use - how would you do it in immutable fashion? Copy the whole bitmap on each small change? There are simply many problems where immutability is the wrong answer if you want anything resembling performance.
  - freedomben 4y ago
    Absolutely, that would be one of the cases where "most of the time" is not "this time." Although for most developers/applications, I would imagine keeping TBs of bitmap in memory isn't a common task. Fetching some rows from the DB and transforming them into some sort of HTML or JSON probably is
  - kephasp 4y ago
    Do you have any examples? Tons of system use immutability with extremely high throughputs, most notably WhatsApp. I don't need infinite memory to make a finite number of modifications to an optimized persistent data structure.

by bitL 4y ago

duped 4y ago

Immutability is an API not an implementation. Immutable code often outperforms mutable, it depends on the use case.

bitL 4y ago
There is often some "redefinition of terms" going on with dedicated functional programming folks in order to assert their claims as you just demonstrated. There was some benchmark where mutable Java was shown to be around 30x faster than immutable OCaml and the discussion went to something like "no, no, that's a wrong comparison, compare it with immutable vs mutable OCaml, that is then just 2x slower! And the next compiler revision will remove it! 100% sure about it!" etc. Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong.
- mrkeen 4y ago
  Awesome, I'd love to read it!
- freedomben 4y ago
  > Why can't other modes of thinking coexist with your view? FP is OK, so is OOP, so is imperative, low-level machine code, "loop programs" (see Dennis Ritchie dissertation), logic programming etc. I like them all but hate it when somebody tries to push me one way telling me all other ways are wrong. Why do you think GP is saying or doing that? I think you've put a lot of words into their mouth that aren't there, and then got yourself worked up about it, enough to accuse them of ignorance and small-mindedness (at best). I see absolutely nothing in their comment that even weighs in favor of FP, let alone saying other modes of thinking can't coexist. For all we know GP is a rabid OOP fan but sees the value in immutability (which FP certainly does not have a monopoly on).
  - bitL 4y ago
    OK, my apologies, that comes as a baggage from previous discussions with FP experts that routinely dismissed any opposing ideas and the OP's answer struck the same chord.
- duped 4y ago
  Sorry I don't mean to sound like an evangelist, I just meant that there are misconceptions out there about immutable data structures (functional programming aside: the two are not so intimately involved that they're equivalent). I hope you can understand why benchmarking OCaml against Java isn't necessarily fair, since they have two completely different implementations (the latter being possibly the most mature set of JIT compilers and runtimes ever built). A more interesting comparison are immutable DAs in languages like C++, for example the immer library which has some very impressive performance characteristics for the problems it solves. And other applications like immutable ropes used in text editors which have extremely high performance compared to mutable variations. At the same time it's not a silver bullet, plenty of other immutable DAs have issues that are non-negligible and applications domains where in-place mutable DSs are required like hard-realtime. Software engineering is about tradeoffs and not dogma, and that's what I was getting at. A take like "immutable is slow" is the counter dogma to "immutable is perfect."

freedomben 4y ago

Immutability can be fast or slow depending on the implementation. There are tons of copy-on-write implementations that blaze past mutable implementations. When the compiler knows that a particular variable/piece of data will never be changed, it opens up a ton of optimizations that can be used to make it fast. With mutable memory it's on the developer to optimize, rather than the compiler. Most of the time, the latter is better at it.

guelo 4y ago
The problem is that developer has no idea if the implementation is going to be performant for their use case. The mutable compilers normally have less magic and thus are easier for the developer to understand and optimize. FP is really just a higher level language, that's why they don't teach algorithms classes using FP languages.
bitL 4y ago
With infinite memory and "no cost memory allocation" you'll be likely correct, but in real world production loads you'll hit those limits quickly and then the immutability is likely getting in the way. Imagine just keeping a large (possibly compressed) bitmap (TBs in memory) to keep track of subscribers in your queue which is what many distributed queues use - how would you do it in immutable fashion? Copy the whole bitmap on each small change? There are simply many problems where immutability is the wrong answer if you want anything resembling performance.
- freedomben 4y ago
  Absolutely, that would be one of the cases where "most of the time" is not "this time." Although for most developers/applications, I would imagine keeping TBs of bitmap in memory isn't a common task. Fetching some rows from the DB and transforming them into some sort of HTML or JSON probably is
- kephasp 4y ago
  Do you have any examples? Tons of system use immutability with extremely high throughputs, most notably WhatsApp. I don't need infinite memory to make a finite number of modifications to an optimized persistent data structure.