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 272286
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: This is a beautiful design
by JonathanBThompson on Tue 18th Sep 2007 17:51 UTC in reply to "This is a beautiful design"
JonathanBThompson
Member since:
2006-05-26

How on earth would a program completely avoid the issue of "mutable state" altogether? All software does (eventually) is modify states with one bit of code, and do computations based on that sooner or later, or do something with it, but if you haven no "mutable state" there's no point in executing code at all. While that may not be visible to the developer using a functional language, the interpreter/compiler eventually gets down to banging bits and branching based on them.

Maybe functional languages are the next wave of the future, and perhaps the next relatively short-lived fad (like Pascal, etc. for the mainstream) that goes out of style and leaves a fair amount of legacy code behind. After all, it just may be that people on average won't go for functional languages and the thought patterns they require, just like a lot of people won't readily grok object-oriented languages.

Reply Parent Score: 3

tuttle Member since:
2006-03-01

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


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.

While that may not be visible to the developer using a functional language, the interpreter/compiler eventually gets down to banging bits and branching based on them.


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.

Maybe functional languages are the next wave of the future, and perhaps the next relatively short-lived fad (like Pascal, etc. for the mainstream) that goes out of style and leaves a fair amount of legacy code behind.


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.

After all, it just may be that people on average won't go for functional languages and the thought patterns they require, just like a lot of people won't readily grok object-oriented languages.


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.

Reply Parent Score: 1

project_2501 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...

Reply Parent Score: 2

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