prepare for thousands of processing cores

[Matthew Dillon]

:Have a look at http://news.cnet.com/8301-13924_3-9981760-64.html and 
:http://blogs.intel.com/research/2008/06/unwelcome_advice.php
:
:"... developers should start thinking about ... thousands of cores now in 
:their algorithmic development and deployment pipeline."
:
:I am curious: what about DragonFly and "thousands of cores"?

    Kinda what Sun is doing.

    The problem we face as developers is not so much in developing new
    algorithms but instead in needing a wholely new programming language
    which naturally operates, even assumes, a many-threads model.

    And here I'm not talking about Java and its piss-poor structural
    locking.

    I've experimented with this sort of thing by building simple
    interpreted languages, for example a new procedural model that is
    naturally threaded and works something like this:

    ...
    x += fubar(x);
    x += fubar(x);
    x += fubar(x);

    __thread
    int
    fubar(int x)
    {
	... do some stuff synchronously ...

	/* return a synchronous result... */
	result(x + 50);
	/* then continue as a thread ... */
	blah blah
	blah 
	blah
	blah
	return;	/* (or fall off the end of the procedure) */
    }

    The idea being that to take proper advantage of a many-cores system
    the programming language must not only be naturally threaded, but
    also be able to efficiently and dynamically allocate and free cpu cores
    for threading as well as seemlessly combine timeshare scheduling with
    threading.

    The actual implementation is not too hard to do.  The programming
    language must do away with the standard notion of a fixed-sized stack
    and instead allocate a procedure's stack resources dynamically,
    allowing the program to split and collapse many execution paths
    as part of its natural operation.

    In anycase, a programming language that efficiently does the above as
    part of its core is an absolute requirement for being able to work
    in a many-cores environment.  The developer has to not be afraid of
    calling a __thread procedure in a critical path.  We will not be able
    to take advantage of such an environment until threads are thought of
    as low cost, natural entities with overheads on the same order as
    an unthreaded procedure call.

    Ultimately that means the cpu core needs to have instructions to
    dynamically create and destroy threads, which automatically fall back
    to time-share if no hardware threads are available.  And it has to
    be able to do it in less then a few nanoseconds to be viable, and
    not break the instruction pipeline.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>