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 272290
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 tuttle on Tue 18th Sep 2007 18:49 UTC in reply to "RE: This is a beautiful design"
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

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