Linked by Thom Holwerda on Mon 17th Sep 2007 20:51 UTC
"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 272290
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: This is a beautiful design
by project_2501 on Tue 18th Sep 2007 22:59
in reply to "RE[2]: This is a beautiful design"
Member since:2006-03-20
Funcional programming is very nice theoretical properties, and you can make certain assurances that you can't with languages such as C. A nice outcome was that i was very applicable to massively parallel computation.
The downside is that memory is consumed fairly rapidly (because you don't write over previous values - you keep creating new memory stores). Though these days memory is cheap and plentiful...
RE[4]: This is a beautiful design
by tuttle on Tue 18th Sep 2007 23:52
in reply to "RE[3]: This is a beautiful design"
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.
Member since:
2006-03-01
Is that a rhetorical question? The program is a function that transforms the old state to the new state
state[t+1]=f(state[t])
This model of computation is turing complete, yet at no point does f have to modify the old state.
Of course at some point bits are being modified. The compiler does all kinds of stuff behind the scenes. Like e.g. register allocation.
That does not mean that a developer should have to worry about that.
Lazy evaluation might be a fad. But the concept of mathematical functions without side effects is much older than computers. It is not likely to go out of style any time soon.
We are talking about people who want to utilize a massively multithreaded CPU, not average computer users writing batch files or excel macros.
The alternatives for writing parallel algorithms are fine-grained locking, transactional memory and functional programming.
The only approach that allows transparent use of massively parallel CPUs is FP. Transactional memory will have better performance in some very rare situations, and fine-grained pessimistic locking is slow and very difficult to get right.