Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Generational GC usually depends on write barriers to detect creation of references to newer generations inside older generations.

Immutability prevents the mutation of older generations, so no new references can occur.

So I expect generational GC to be easier to implement. I wouldn't expect it to be faster or slower though, because programs will need to be written differently to cope with the limitations on mutability. O(1) algorithms will likely be replaced by O(log(n)).



In the case of Clojure, log is log base 32, so it's close enough to O(1) as to make no difference in most circumstances.


Many immutable algorithms replace arrays with trees. Trees are pointer-heavy, and pointers are less cache-friendly than arrays.

Memory access is often over 100x the cost of an L1 cache hit. It doesn't take too many of those to make a big difference if you're CPU bound.

My comments are general, I'm sure Clojure has access to arrays where necessary for interop at least.


Again, true, but the big problem I'm facing isn't raw performance so much as it's guaranteed latency.


But the constant factor is Z, a very large number. A number so large it has a color and name. It pays taxes, has lunch and sees movies on the weekend.


Not true in the context of dynamic languages. The constant factor for persistent maps in that context is quite small.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: