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

(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" <alec@xxxxxxxxxxxxxx> wrote in message 
news:MPG.1e45ef217b9ccc13989aec@xxxxxxxxxxxxxxxxxxxxxx
In article <43db5fe1$0$29563$da0feed9@xxxxxxxxxxxxxx>, "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.

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.

>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.

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.

>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.

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).

>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 from the calling Asynchronous
>Object, which suspends until the reply is returned. If the method has 
>no
>return value, the the caller does not suspend.

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......

--
James


.

Relevant Pages

  • Re: What would motivate conversion to a new concurrent model akin to that of the transputer?
    ... invented by individuals and have spread out becasue they solved peoples ... So a new language in the transputer spirit has to add good concurrency ... the CPU over external memory access stalls. ... Asynchronous Objects may enclose both Synchronous Objects and lesser ...
    (comp.sys.transputer)
  • Re: Thinking assembly?
    ... I simply needs to understand the CPU and how it works, ... > understand the instructions, be a good and experienced programmer, ... assembly language is the machine's language (or, at least, ...
    (alt.lang.asm)
  • Re: TASM revisited
    ... overhead" do you mean the overhead of the associated system calls that ... Neumann architecture, system calls could be coded in assembly language ... system could help your HLA students learn assembly even better, ...
    (alt.lang.asm)
  • Re: How Many Processor Cores Are Enough?
    ... Let's say the language is strictly Assembly, ... If a particular architecture does not have the correct barrier for this kind ... that architecture very much at all; RCU performance would tank with explicit ...
    (comp.arch)
  • Re: .NET and ActiveX
    ... all it does is define an interface (NOT a language interface) on ... > the CLR, then it is a .NET component, can run outside of traditional COM ... COM is an architecture. ... The CLR is just passing messages ...
    (microsoft.public.dotnet.framework)