Linked by Thom Holwerda on Mon 17th Sep 2007 20:51 UTC
Oracle and SUN "Sun announced Niagara 2 the other day, an evolution of the older Niagara 1, now called the UltraSPARC T1. From the 10000-foot view, it all looks quite familiar, but once you delve into the details, it quickly becomes apparent that almost everything has changed."
Thread beginning with comment 272406
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: This is a beautiful design
by tuttle on Tue 18th Sep 2007 23:52 UTC in reply to "RE[3]: This is a beautiful design"
tuttle
Member since:
2006-03-01

The downside is that memory is consumed fairly rapidly (because you don't write over previous values - you keep creating new memory stores).


In my experience, this is not the case in general. Most object oriented code contains a lot of "defensive copying".

For example an object that holds an internal mutable array may not expose a reference to that array to the outside world, since that would break encapsulation. Instead it must make a copy even if the user of the array is only reading.

In a functional language you can safely expose a reference to all internal data structures if you want the outside world to see them.

Besides, modern memory allocators/garbage collectors are incredibly fast in allocating and disposing short-lived objects. Not as fast as stack allocation, but quite close.

There are some situations where some kind of mutable state can result in a significant performance improvement. Manipulation of small areas of large bitmaps might be one example.

But there are ways to do this without violating referential transparency (uniqueness typing or monads). And if you really need mutable state you can always choose a non-pure functional language such as scala or ocaml that discourages, but allows mutable state.

Reply Parent Score: 1