[Nomen-dev] Two interesting articles

[Brian H. <bh...@sp...>]

(Dave, don't forget to subscribe to this list!)

Nomen is still in deep coma, I just wanted to post some links.

From LTU:
http://lambda.weblogs.com/discuss/msgReader$9289
http://lambda.weblogs.com/discuss/msgReader$9297

Concurrency-oriented programming is something I've thought of before, but 
in a slightly different context.  One of the big problems in modern CPU 
design is that we're hitting a wall with regard to the number of 
instructions per clock we can execute, see:
http://citeseer.nj.nec.com/wall90limits.html

Good RISC CPUs like the PA-RISC and Power4 are already hitting 4 IPC, with 
a limit of 5-7.

Now, consider having two purely applicative functions foo and bar (they 
only compute their return value, they don't change global state, etc), in 
code like:
	let a = foo ...
	and b = bar ...
	in
	...

Now, since both functions are purely applicative (and assuming that the
call to bar doesn't need the result from foo), we can run them in either
order and not change the meaning (end result) of the program.  We can, in 
fact, run them in parallel.  If each function had an IPC rate of say, 4, 
we could interleave the two functions and create a combined function with 
an IPC rate of maybe 8.  With a capable enough machine, we've just doubled 
the speed of the program.

This wouldn't be much help on the x86- the lack of registers and constant
side-effects will kill you.  Well, you might be able to get a 2 IPC
instead of the more normal 1 IPC most x86 programs get.  But the huge
advantage would be with RISC CPUs, where you have the registers to be
running multiple different functions at the same time and still "fit".  
An even bigger winner would be Intel's Itanium- with lots of registers
(128, a lot even for RISC), predictated instructions, and
compiler-scheduled instructions, having 6-8 functions being executed
simultaneously would really show off the capabilities of that
architecture.

It wouldn't be too hard to do.  Every function would be either applicative 
or imperitive.  Imperitive functions have side effects- or call other 
imperitive functions.  Applicative functions have no side effects and call 
only other applicative functions (Impertitive functions can call 
applicative functions, but not the other way around).  The top levels of 
the program will almost always be imeritive- so what?  Imperitive 
functions have to be called in sequential order, applicative functions the 
compiler knows it can dink with a lot more and preserve the semantics of 
the program a lot more.

Brian