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 272400
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: This is a beautiful design
by rayiner on Tue 18th Sep 2007 23:14 UTC in reply to "RE: This is a beautiful design"
rayiner
Member since:
2005-07-06

How on earth would a program completely avoid the issue of "mutable state" altogether?

A pure functional program has no mutable state at the language level. Logically, objects are never modified --- instead, new objects are created in response to computations. Obviously registers are mutated at the implementation level, and memory is "mutated" as it's reclaimed by the GC and used to store new objects*, but language-level transformations, the kind that can be used to extract parallelism, aren't restricted by those implementation details.

That said, I don't know how suitable a threaded architecture is for functional-level parallelism. The cost of starting new threads of computation is probably too much. Functional programs seem more well suited to very wide superscaler designs, perhaps even dataflow machines.

Maybe functional languages are the next wave of the future, and perhaps the next relatively short-lived fad

Functional languages have been around for more than 40 years. Much of the formal theoretical underpinnings of CS are based on functional models of computation (the lambda calculus). They're not going anywhere.

*) Initializing writes are not considered mutation. It helps to make the distinction between mutation (writes to memory that's "live", from the perspective of the GC), and initialization (writes to memory that's "dead").

Edited 2007-09-18 23:18

Reply Parent Score: 2