What would motivate conversion to a new concurrent model akin to that of the transputer?

What would motivate conversion to a new concurrent model akin to that of the transputer?

Post by James Harr » Sun, 29 Jan 2006 21:13:36



Some would say the transputer was well ahead of its time. It certainly
had some novel features and it was good, imo, to see a design that was
so clean - i.e. it had no baggage from having to maintain binary
compatibility with previous generations. Unavoidably, though, as new
generations of any product are produced there will be some quirks
engineered in to maintain that compatibility (otherwise they probably
wouldn't be called "generations" - just a thought).

How viable would it be, I wonder, rather than building another cpu with
transputer features, to design and build the language first (with a
conceptual architecture) and give the language time to mature in the
market. Then, if it becomes popular enough, the expense of chip
development to run the code more efficiently would have a justification.

There are some key arguments against this:
1) What would motivate people to start using a new language?
2) What would motivate the migration of vast existing system code?
3) What would motivate conversion of applications to the new code?
4) Speed or cost/benefit of the new code may not be as good as for
existing software on the existing hardware.

To overcome these would require something extraordinary. As e-mail was a
killer-app for networking something similar would be needed

The benefits of the approach
1) The language would begin clean.
2) If designed right - so that the semantics of the code were evident in
source rather than needing compilation to work out what the code was
doing (e.g. no uncontrolled pointers, no aliasing of variables, no
hidden modification of variables, comments attributable to the statement
or statements to which they refer) I think old copies of the source
could be 'upgraded' automatically and remain in a human-readable form.
They could simply have been converted to the upgraded source language
specification.
3) If the idea dies and the language doesn't catch on much less expense
will have been, er, expended.

Whatever model of computation the language uses would have to be
fundamental - i.e. more related to computing per se than to any
particular current trend - something akin to the communicating process
model, perhaps, though possibly more flexible. IPC expressed as along
channels can be /implemented/ in different ways (invisible to the
programmer). And, of course, there is the option of communicating
between machines as well as intra-machine. Rather than transputer links
there would be system memory or a network link. But the source would
stay the same.

Does this all make sense to anyone but me? It's always hard to strike
the balance of express enough detail in Usenet without drowning the
meaning in text. If you've been kind enough to read this far maybe you
have some idea of what I'm getting at.

Can anyone here see such a language as workable - or what would make it
workable for you? Is there something that would be required to motivate
people to go down this road despite the objections mentioned above?

Your comments - kind and caustic - would be appreciated.
 
 
 

What would motivate conversion to a new concurrent model akin to that of the transputer?

Post by Alec Cawle » Mon, 30 Jan 2006 06:16:35

n article <43db5fe1$0$29563$ XXXX@XXXXX.COM >, "James Harris"
<no.email.please> says...

<snipped the question, becasue I am answering the spirit and not the
detail>

What does it ta\ke to get a new language taken up? Basically, that it
solves peoples problems. Some new languages (Java and C#) have been
pushed by big corporations. Others (Perl, PHP, Python, Ruby) have been
invented by individuals and have spread out becasue they solved peoples
problems.

The problem with occam was that, while it provided an excellent solution
to the problems of concurrency, it didn't solve any of the other
problems that people have. And, while concurrencey is not a small
problem, data structureing, namespaces, modularity over large teams,
compactness of expression, are all problems whuch are equally large, and
which occam ignores.

So a new language in the transputer spirit has to add good concurrency
handling to a clean and simple language with good structures.

I tis not obvious to me that you necessary need a complete new
architecture. Intel's success in greasing up the grotty x86
architecture, and the non-success of Itanium, show that compilers can
gloss over an unbeautiful architecture with software.

One thing that a transputer successor would need is a very lightweight
task switch. This is partly handled by having a register-poor
architecture so there is not much to save and restore over a task
switch. Another solution would be massive hyperthreading; current Intel
CPUsoffer only two threads, becasue ther are attempting only to optimise
the CPU over external memory access stalls. But if you had, say, 1024
register sets all effectively running threads in parallel, with the
oldest being saved to memory in background, the cost of parallelism
would be greatly increased.

Tha other transputer-like thing is that memory-to-memory copies should
be very cheap, even when the memory is physically in another CPU, and
integrated with the threading mechanism. Tecnologies such as Infiniband
make this very easy.

So it would not strike me as hard to buld a CPU using basically current
x86 technology and instruction set, with a transputer-like
communications capability and hundreds of threads per CPU. Is a 64-bit
address space, arbitraily split into (say) 40 bit local address and 24-
bit CPU ID.

I also thingk that there is not yet a good merger between the Object
Oriented model and threading. Current threaded OO langiuages treat the
thread as something bugger than the object - a thread can run from one
Object to another. And, once you have relinquished control of your
thread to another Object, you have no idea what it will do.

I think the priority should be the other way around. Ther are two
classes of Objects: Synchronous Objects and Asynchronous Objects.
Asynchronous Objects may enclose both Synchronous Objects and lesser
Asynchronous Objects, but not vice versa. Inside each Asynchronous
Object is a single thread, which is effectively locked inside it. The
semantics of method calls on Syncronous and Asunchronous Objects are the
same, but the implementations are different. A call on a Synchronous
Object is the standard method call: the thresd disappears into the
Synchronous Object, does what it has to (atomically) and re-appears. For
a call on an Asynchronous Object, the implemntation is the Remote
Procedure Call: the paramters are sent
 
 
 

What would motivate conversion to a new concurrent model akin to that of the transputer?

Post by Kai Kn » Mon, 30 Jan 2006 22:51:43


In the essay "The End of History and the Last Programming Language" by
Richard P. Gabriel analyses the history of programming languages, and
the properties that determine the languages success or failure. His
theory consists of four parts:

1. Lanuages are accepted and evolve by a social process, not a
technical or technological one.
2. Successful languages must have modest or minimal computer resource
requirements.
3. Successful languages must have a simple performance model.
4. Successful languages must not require users have "mathematical
sophistication"

Without going into to much detail, the bottom line is that people do not
accept new languages just because of its technical superiority.
Instead, things like availability, speed, and support by local wizards
matter. Another important point is that a language should be similar to
existing popular languages; people want evolution, not revolution.

The (very insightful) essay is part of the book "Patterns of Software",
available for free at
http://www.yqcomputer.com/

Regards,

Kai Koehne
 
 
 

What would motivate conversion to a new concurrent model akin to that of the transputer?

Post by James Harr » Fri, 03 Feb 2006 04:46:10

"Alec Cawley" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
In article <43db5fe1$0$29563$ XXXX@XXXXX.COM >, "James Harris"
<no.email.please> says...

<snipped the question, becasue I am answering the spirit and not the
detail>

What does it ta\ke to get a new language taken up? Basically, that it
solves peoples problems. Some new languages (Java and C#) have been
pushed by big corporations. Others (Perl, PHP, Python, Ruby) have been
invented by individuals and have spread out becasue they solved peoples
problems.

The problem with occam was that, while it provided an excellent solution
to the problems of concurrency, it didn't solve any of the other
problems that people have. And, while concurrencey is not a small
problem, data structureing, namespaces, modularity over large teams,
compactness of expression, are all problems whuch are equally large, and
which occam ignores.

So a new language in the transputer spirit has to add good concurrency
handling to a clean and simple language with good structures.

I tis not obvious to me that you necessary need a complete new
architecture. Intel's success in greasing up the grotty x86
architecture, and the non-success of Itanium, show that compilers can
gloss over an unbeautiful architecture with software.

One thing that a transputer successor would need is a very lightweight
task switch. This is partly handled by having a register-poor
architecture so there is not much to save and restore over a task
switch. Another solution would be massive hyperthreading; current Intel
CPUsoffer only two threads, becasue ther are attempting only to optimise
the CPU over external memory access stalls. But if you had, say, 1024
register sets all effectively running threads in parallel, with the
oldest being saved to memory in background, the cost of parallelism
would be greatly increased.

Tha other transputer-like thing is that memory-to-memory copies should
be very cheap, even when the memory is physically in another CPU, and
integrated with the threading mechanism. Tecnologies such as Infiniband
make this very easy.

So it would not strike me as hard to buld a CPU using basically current
x86 technology and instruction set, with a transputer-like
communications capability and hundreds of threads per CPU. Is a 64-bit
address space, arbitraily split into (say) 40 bit local address and 24-
bit CPU ID.

I also thingk that there is not yet a good merger between the Object
Oriented model and threading. Current threaded OO langiuages treat the
thread as something bugger than the object - a thread can run from one
Object to another. And, once you have relinquished control of your
thread to another Object, you have no idea what it will do.

I think the priority should be the other way around. Ther are two
classes of Objects: Synchronous Objects and Asynchronous Objects.
Asynchronous Objects may enclose both Synchronous Objects and lesser
Asynchronous Objects, but not vice versa. Inside each Asynchronous
Object is a single thread, which is effectively locked inside it. The
semantics of method calls on Syncronous and Asunchronous Objects are the
same, but the implementations are different. A call on a Synchronous
Object is the standard method call: the thresd disappears into the
Synchronous Object, does what it has to (atomically) and re-appears. For
a call on an Asynchronous Object, the implemntation is the Remot
 
 
 

What would motivate conversion to a new concurrent model akin to that of the transputer?

Post by James Harr » Fri, 03 Feb 2006 06:26:21

Had a bit of trouble with the newsreader - for some reason it failed to
automatically ">" mark the prev message. Sorry if this is a repost.)

"Alec Cawley" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
In article <43db5fe1$0$29563$ XXXX@XXXXX.COM >, "James Harris"
<no.email.please> says...

Your comments on solving problems are encouraging. I am in complete
agreement on the need for the language to get the basics right so it can
be used for dealing with general programming requirements as well as
parallel ones. I've been amazed as how difficult a task it has been to
do that. So far the results have been good. I still have quite a bit of
work yet to do, though.


This may refer to my comments on a conceptual architecture. That was
meant to be a paradigm of how the language works - in particular IPC.
FWIW I'm thinking of passing typed tuples - CHAN OF <tuple> if you
like - and allowing flexibility in terms of buffering. The flexibility
seems required to reflect the real-world requirements.


I'll keep all these comments in mind. I have an OS project that is going
hand-in-glove with the language one. There is nothing I can do on the
hardware side but it has been important to me to keep task switching and
message passing as lightweight as possible on the hadrware available
(while not compromising ALT-type selections).


This sounds very similar to what I have in mind - maybe even the same.
The locus of execution can go with the message or remain with the
sender. Some processes can have just one thread, picking their work up
from incoming channels they effectively serialise access to a resource.
Stateless processes can be duplicated etc. Yes, if the caller expects no
return value it can either pass what's left of its timeslice or keep it
as desired.

I honestly don't have a clear way forward wrt object orientation.
Abstract data types, yes, but how best to deal with inheritance is still
an open question......


 
 
 

What would motivate conversion to a new concurrent model akin to that of the transputer?

Post by James Harr » Fri, 03 Feb 2006 06:32:04


Thanks Kai, for the link - and at over 200 pages especial thanks for
summarising it!! Will keep this in mind.
 
 
 

What would motivate conversion to a new concurrent model akin to that of the transputer?

Post by Kai Koehn » Fri, 03 Feb 2006 22:28:09

James Harris schrieb:

You might have a look at "Towards a Viable Alternative to OO - Extending
the occam/CSP Programming Model" by Tom Locke:
http://www.yqcomputer.com/
OO and CSP as alternatives, and shows that inheritance can be sometimes
emulated by delegation.

Personally, I am very sceptical about combining OO and CSP. It seems to
me that putting things like inheritance into CSP would do more harm
(lack of locality, easyness etc) than good. However, the Honeysuckle
language (a kind of occam successor) seems to have features like object
encapsulation, whatever an object means in that context (I. East, The
Honeysuckle programming language: an overview:
http://www.yqcomputer.com/ )

Regards,

Kai Koehne