4 ms·
Generally in compiler technology, immutability is an important tool in letting compilers reason about and make program transformations. See eg the "single stati
by fulafel 5y ago
Generally in compiler technology, immutability is an important tool in letting compilers reason about and make program transformations. See eg the "single static assignment" intermediate-representation form that is mainstream in low level language compilers. But SSA form isn't as good as having the original program expressed immutably, because you get false or incidental data dependencies if the compiler has to conservatively derive the optimization-friendly SSA representation out of the original non-immutable code.
In practice a JS implementation that had special optimizations for code using immutability as a convention might for example auto-parallelize code.
Also it by no means a bad thing if a compiler turns a piece of easy to reason about functional code "back" to generated code that exploits local mutability behind the scenes in some circumstances, that's exactly how we want it to work. We still get the robustness guarantees of semantics where our objects don't change from under us in programmer visible ways.
- gpderetta 5y agoTalking about parallelization opportunities is a bit pointless when you need 50 cores to match the performance of the single threaded code (in the best case, assuming perfect scaling).
- azakai 5y agoFair enough, but parallelism isn't just about cores since SIMD can also help. Also, immutability doesn't just help through parallelism, it also allows other things (as another example, avoiding redundant work like loads of an immutable field and computations on them). Would that help with a huge 50x difference? Maybe not, but the point is that evaluating the benefits of immutability on a VM that does not optimize it - JS VMs - is not relevant. (And that 50x might also be caused by other limitations of JS VMs and not immutability at all, like say deopts.)
- fulafel 5y agoI disagree - lots of compiler work is done on languages that aren't best in class for high performance work. Look at all the effort that people are putting into making Python faster. And indeed JS itself, it wasn't always this fast. High level language users live by "There's more to life than increasing its speed" and then if they take off, people come work on performance and make them faster. Also let's not forget that this was already "fast enough" for a long time before the 50x rewrite.
- gpderetta 5y agoMy issue was specifically with the claim that persistent data structures are great for parallelization. I have absolutely no issues with efforts to improve single threaded performance of programming languages (and indeed the advances made by JS are remarkable) and I don't believe any language needs to be "As Fast As Cee". But There are other perfectly reasonable languages that are within a small integer factor of C and C++. You do not need to pay a large penalty for ergonomics.
- hedora 5y agoThese techniques are also applied by compilers such as clang.