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 272216
To read all comments associated with this story, please click here.
This is a beautiful design
by tuttle on Tue 18th Sep 2007 08:30 UTC
tuttle
Member since:
2006-03-01

You might think that this is irrelevant for general purpose computing, but I would not be surprised to see something like this showing up in designs from AMD and intel in a few years.

Of course to really use such an architecture for desktop tasks a new approach to multithreading is required. Something like transactional memory (which the niagara 2 also supports), or functional programming which avoids the issue of mutable state altogether.

Traditional multithreading primitives like monitors are much too difficult to use.

Reply Score: 1

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

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