Occam Programming Language for Parallella?

Occam Programming Language for Parallella?

Postby eduardo20 » Sun Apr 21, 2013 3:57 pm

in the 1980s there was once a company developing massiv parallel CPUs

The Company was Transmeta and for their massiv parallell hardware they also
developed a massiv parallel programming language!

The programming language is called Occam.

http://frmb.org/occtutor.html

http://www.cs.kent.ac.uk/projects/ofa/kroc/


It might be that Occam is just the right language for this new massiv parallell hardware.

have fun.

yours
eduardo20
 
Posts: 2
Joined: Sun Apr 21, 2013 3:51 pm

Re: Occam Programming Language for Parallella?

Postby 9600 » Sun Apr 21, 2013 4:45 pm

eduardo20 wrote:in the 1980s there was once a company developing massiv parallel CPUs

The Company was Transmeta and for their massiv parallell hardware they also
developed a massiv parallel programming language!

The programming language is called Occam.


I think you might be thinking of Inmos with the Transputer :) IIRC, Transmeta is the company Linus Torvalds was at and they had the Crusoe VLIW processor, some years later.

I suspect there are a few that would enjoy using Occam with Parallella! However, far more people are experienced with C and much more existing software that you might want to use is written in this. That said, it would be very cool to see an Epiphany back-end for KRoC.

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: Occam Programming Language for Parallella?

Postby aolofsson » Mon Apr 22, 2013 1:31 pm

Some folks at Halmstad University in Sweden has already used a mix of Occam and C for programming the Epiphany.
Andreas
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Re: Occam Programming Language for Parallella?

Postby 9600 » Mon Apr 22, 2013 2:12 pm

aolofsson wrote:Some folks at Halmstad University in Sweden has already used a mix of Occam and C for programming the Epiphany.
Andreas


Of course! Now I remember you posting a link to a presentation on this.

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: Occam Programming Language for Parallella?

Postby Sundance » Tue Apr 23, 2013 10:12 pm

Sorry, but I am having to jump up on the Soap-Box and give a little history lesson.

The Inmos Transputer was a revolution in terms of power/performance. It offered Floating-Point and Scalability in one single, relative low-power piece of silicon. If it has been developed and manufactured by Intel (or any US semiconductor company!) it would have found a large customer-base in the DoD and sold in millions. Eventually it would have made it main-stream and we would have been up and running with Parallel Processing for everything 20 years ago.

A single 20MHz T805 outperformed the fastest Intel CPU at time with a factor of 10 in some application. It had 4k of internal memory and crucially, a very easy (but slower) external DRAM Interface and 4x 2-wire communication lanes @ 20Mbits/sec.

It was a like a….. – “Epiphany” and you might have guess why I am interested in the Parallella Project. It was 30 years ago next year, 25+ years before Facebook 8-) - but Facebook serve a purpose = https://www.facebook.com/transputer30th

The chosen programming language, Occam, was another revolution and was/is perfect for Parallel processing. It enabled Hardware Engineers to write programs and that was ultimately the down-fold of both Inmos and Occam. It was too simple (guess you will have guess I was/am a hardware person…. ) for the traditional Software Engineers that had millions of lines of code for Fortran, Pascal, Cobol, ADA or whatever was around in the 1980’s.

Attempts were made to make such Compilers work on the Inmos Transputer, but never really got the best out of the processor. Like cross-compilers and other similar attempts to map the sequential programs to work on arrays of Parallel Processors. Just not quite working..

I am confident that the time for Parallel Processing has arrived and if Occam could play a role, then fantastic vision of the original people that developed the concept. Just like Newton and his pioneering discoveries that took Centuries to mature and being understood, then maybe Occam's time has come??

Flemming

P.S. If you got 6 minutes to spare, then watch this Video = http://youtu.be/o7byWAv6qCk = and all will be clear!
Flemming Christensen
Mobile: +44 7 850 911 417;
Email: Flemming.C@Sundance.com
Skype: Flemming_Sundance
Company Home Page: http://www.sundance.com
User avatar
Sundance
 
Posts: 50
Joined: Mon Dec 17, 2012 3:25 am
Location: Chesham, Bucks, England

Re: Occam Programming Language for Parallella?

Postby mhonman » Thu Apr 25, 2013 4:54 pm

Sundance wrote:Sorry, but I am having to jump up on the Soap-Box and give a little history lesson.


Hooray! There's a fellow grizzled veteran - let's see how our histories match up!

I'm a software engineer (though trained as a computer scientist) so have maybe a different perspective, having been involved in adapting number-crunching CFD applications for Transputer systems.

EDIT: before I start waffling, it is worth mentioning one big difference between the Parallella computer and a Transputer, that might make Occam not as good a fit - and that is that the Transputer was conceived as an Occam execution engine. Every Occam concept had purpose-designed features in the processor, which is the reason for Occam programs being both elegant and stunningly efficient. So a re-implementation of Occam for Parallella might not work quite as well...

Eventually it would have made it main-stream and we would have been up and running with Parallel Processing for everything 20 years ago.


I'm not sure about that, it still take a special way of thinking to write parallel programs that scale well and retain algorithmic efficiency.

As a programmer, what I *loved* about the Transputer was the low-latency links that had performance well-matched to the CPU performance, and also the elegant way in which communication occurred. That is, via a rendezvous mechanism that did not need to be mediated by an operating system, and worked in exactly the same way whether the communicating processes were on the same chip or communicating via an external link.

What wasn't so much fun was the deadlocks due to progamming errors, which would require a post-mortem debugging session in which one would have to check the state of each CPU to understand what had gone wrong.

It was a like a….. – “Epiphany” and you might have guess why I am interested in the Parallella Project.


Same here... and what looks good is that this eliminates the main hassle-factor in the Transputer model, i.e. global communication is available when needed.

The chosen programming language, Occam, was another revolution and was/is perfect for Parallel processing. It enabled Hardware Engineers to write programs and that was ultimately the down-fold of both Inmos and Occam. It was too simple (guess you will have guess I was/am a hardware person…. ) for the traditional Software Engineers that had millions of lines of code for Fortran, Pascal, Cobol, ADA or whatever was around in the 1980’s.


It was my first job... was hired by a bunch of aero engineers to adapt their Fortran to this new technology (the advantage of truly new technology is that very few people know anything about it, so lack of experience is not a deal-breaker!). The programming model that eventually emerged (for us at least) was to introduce "new" boundary conditions to the Fortran code which meant that the boundary was actually an interaction with an adjacent block. So the Fortran stayed sequential, and a bunch of Occam was written around it to handle the communication on its behalf.

The thing that killed the Transputer option for us was the endless delays on the T9000, which was a serious case of "second system syndrome". At the same time Unix workstations were moving to RISC architectures that put Intel and the Transputers completely in the shade - We ended up getting 3 or 4 of those boxes and my focus shifted to multi-block solving on just a few machines and a slow interconnect.

Mark

P.S. Flashback time (aaargh)... does anyone remember the i860, perhaps the most misbegotten Intel design of them all? There was a firm in Bristol that produced a system that was i860-based by used Transputers for the mesh network... I wonder how that worked out...
Last edited by mhonman on Fri Apr 26, 2013 7:42 am, edited 1 time in total.
mhonman
 
Posts: 112
Joined: Thu Apr 25, 2013 2:22 pm

Re: Occam Programming Language for Parallella?

Postby Sundance » Thu Apr 25, 2013 8:43 pm

P.S. Flashback time (aaargh)... does anyone remember the i860, perhaps the most misbegotten Intel design of them all? There was a firm in Bristol that produced a system that was i860-based by used Transputers for the mesh network... I wonder how that worked out..

I thought they were out of Cambridge; could be more than one company. ;) - and I happen to speak to one of them today. I shall introduce him to Parallella :idea:
Flemming Christensen
Mobile: +44 7 850 911 417;
Email: Flemming.C@Sundance.com
Skype: Flemming_Sundance
Company Home Page: http://www.sundance.com
User avatar
Sundance
 
Posts: 50
Joined: Mon Dec 17, 2012 3:25 am
Location: Chesham, Bucks, England

Re: Occam Programming Language for Parallella?

Postby 9600 » Fri Apr 26, 2013 6:35 am

mhonman wrote:P.S. Flashback time (aaargh)... does anyone remember the i860, perhaps the most misbegotten Intel design of them all? There was a firm in Bristol that produced a system that was i860-based by used Transputers for the mesh network... I wonder how that worked out...


I have two Meiko Computing Surface (CS-1) nodes. The older one of these is filled with Transputers and a graphics board, and relied on an external host for loading. The other one is a little newer and has few Transputers and a Sparc 1+ in it as a front-end processor, and also some i860 processors IIRC. Sadly, I wasn't able to recover the software from the failing HDD that came with the latter, and both haven't been turned on for a very long time and were at one point stored in a damp cellar. So, one summer I'm going to have to dismantle them, clean the PCBs of any whiskers and the chassis of rust, and check out the PSUs etc. before powering up once more. Then there is the small matter of software... All in the name of fun — it's like digital archaeology :)

Cheers,

Andrew
Andrew Back (a.k.a. 9600 / carrierdetect)
User avatar
9600
 
Posts: 997
Joined: Mon Dec 17, 2012 3:25 am

Re: Occam Programming Language for Parallella?

Postby mhonman » Fri Apr 26, 2013 8:11 am

9600 wrote:I have two Meiko Computing Surface (CS-1) nodes.


Yes, that's it!

Back to the original topic... I had a happy evening reading the Epiphany manuals and while it looks like it could be made to do Occam, that might be rather missing the point. Since it is a RISC architecture with a decent sized register file, context switches are going to be relatively more expensive than a Transputer, also some kind of mini-kernel would be needed to implement the channel abstraction.

On the other hand the main reason for having multiple processes running on a single Transputer was to decouple computation and communication (at least in the number crunching stuff I did), and this is provided by architectural features of Epiphany - the separate mesh network and DMA engines.

Part of the beauty of Occam lies in its freedom from pointers and address manipulation, which eliminates a whole class of potential bugs. The Epiphany approach to communication seems to be almost a polar opposite: "pointers happen" and the communication facilities are exposed in the form of what appears to be a shared-memory system. So rather than map message-passing onto it, I'd guess it would be more efficient to code to the architecture, e.g. by having a core use DMA to push results to its neighbours' memory.
mhonman
 
Posts: 112
Joined: Thu Apr 25, 2013 2:22 pm

Re: Occam Programming Language for Parallella?

Postby aolofsson » Fri Apr 26, 2013 11:53 pm

mhonman,
With the Epiphany, we didn't want to force a message passing programming model (although based on our experience it is the most suitable programming model for this type of architecture). The good news is a simple send/receive model can be implemented that is really light weight with minimal overhead even for short messages).

A heterogeneous model with C/C++ being used for core programs and occam for higher level composition and explicit communication could be quite nice imho.

100% agree that we need to completely abstract away pointers and absolute addresses from the general programmer. We are working on it..

Andreas
User avatar
aolofsson
 
Posts: 1005
Joined: Tue Dec 11, 2012 6:59 pm
Location: Lexington, Massachusetts,USA

Next

Return to Occam

Who is online

Users browsing this forum: No registered users and 1 guest

cron