[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Transputer - schools
Running example Occam program commstime.occ on the Raspberry Pi :
Commstime in occam ...
Using the SEQ-output version of the delta process
yields a more accurate measure of context-switch time
Using the PAR-output version carries an extra overhead
of one process startup/shutdown per Commstime loop
By comparing *loop* times between the SEQ and PAR versions,
the process startup/shutdown overhead may be deduced
Sequential delta? yes
Commstime starting ...
Last value received = 1000015
Time = 10303522 microsecs
Time per loop = 10303 nanosecs
Context switch = 2575 nanosecs
Cheers,
Beau
-----Original Message-----
From: J.B.W.Webber
Sent: 27 June 2013 19:53
To: 'Larry Dickson'
Cc: Bob Gustafson; Ruth Ivimey-Cook; occam-com@xxxxxxxxxx
Subject: RE: Transputer - schools
Thanks Larry,
There is a noticeable pause on compilation, but the run-rate of the example tty-based demos is clearly completely nominal.
Certainly I only regard the Raspberry Pi as a test-bed for development, for low-cost experimentation and school use.
Cheers,
Beau
-----Original Message-----
From: Larry Dickson [mailto:tjoccam@xxxxxxxxxxx]
Sent: 27 June 2013 17:39
To: J.B.W.Webber
Cc: Bob Gustafson; Ruth Ivimey-Cook; occam-com@xxxxxxxxxx
Subject: Re: Transputer - schools
This is yeoman work, a mighty step forward, especially for demos. My quibble (and it's really with the Transterpreter) is, to quote you: "it is just not fast on a Raspberry Pi." I think I saw that coming after looking at some Transterpreter commstime results. I don't think it is an essential characteristic.
This is probably a lot of work, but would it be possible to revisit the Transterpreter? In the INMOS Compiler Writer's Guide, it shows the assembly commands coming in structured clumps, each corresponding to a very clear occam primitive. Since occam is such a flat language, it ought to be possible to go through output of the occam compiler and recognize these clumps, thus decompiling to the point of exposing the essential process and communication structure. This semi-source could then be implemented on the target using its native capabilities, once target-specific techniques are designed to do the short list of critical occam primitives. Maybe blocks of pure sequential code could even use LLVM, if it could be purified of its stackiness. It should certainly be possible to map a "PRI PAR" onto interrupt code.
I would expect that could give a speed improvement of tenfold or more. It ought to work especially well on chips like the XMOS and the Adapteva, whose primitives are already very close.
Larry
On Jun 27, 2013, at 9:10 AM, J.B.W.Webber <J.B.W.Webber@xxxxxxxxxx> wrote:
> Hi all,
> Thanks for the various pointers.
> Fred Barnes sorted me out, and as per what Ruth suggested (it was there in the documentation) :
> I had to create a transterpreter version :
> I used :
> ./build --with-toolchain=tvm --prefix=/usr/local/kroc
>
> So it has taken me more than a day, but Kroc is now up and running and compiling Occam and producing runnable code on the Raspberry Pi :
>
> jbww@raspberrypi ~/Src/Occam/kroc-git/Work $ occbuild --program
> hello.occ jbww@raspberrypi ~/Src/Occam/kroc-git/Work $ ls hello
> hello.occ hello.tbc hello.tce jbww@raspberrypi
> ~/Src/Occam/kroc-git/Work $ ./hello Hello, world!
>
> So the compilation from the Git sources works fine, it is just not fast on a Raspberry Pi.
>
> As I say, I would like to offer fully updated Raspberry Pi SD cards at low cost with the Linux OS etc, Aplc concise/agile array manipulation language and the Kroc Occam, complete will all pre-requisites, up and running with TightVNC, SSH and SCP.
>
> I already have a Raspberry Pi SD card with Linux OS + Apache Web Server + TightVNC + SSH + SCP, available on Lab-Tools :
> http://www.lab-tools.com/instrumentation/#RaspberryPi
>
> My hope is that people will join me in experimenting re making these tools work together. As and when we understand how to connect the Raspberry Pis together in Beowulf clusters, this would also be included on the SD card.
> Cheers,
> Beau
>
> -----Original Message-----
> From: Sympa,pkg125 [mailto:sympa@xxxxxxxxxx] On Behalf Of J.B.W.Webber
> Sent: 26 June 2013 18:40
> To: Bob Gustafson
> Cc: occam-com@xxxxxxxxxx
> Subject: RE: Transputer - schools
>
> Thanks Bob,
> I have asked for help : it is trying to determine the endian status (it is little-endian), but there are also comments about related bits in an m4 file, so needs someone who knows what they are doing.
> Cheers,
> Beau
>
> -----Original Message-----
> From: Bob Gustafson [mailto:bobgus@xxxxxxx]
> Sent: 26 June 2013 18:21
> To: J.B.W.Webber
> Cc: occam-com@xxxxxxxxxx
> Subject: Re: Transputer - schools
>
> This link might be useful:
> http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=44487
>
> On Wed, 2013-06-26 at 16:55 +0000, J.B.W.Webber wrote:
>> OK, the first attempt at a Kroc build (from source) for the Raspberry Pi has just failed (after a few hours) :
>> unsupported architecture armv6l
>> I will chase more.
>> Cheers,
>> Beau
>>
>> -----Original Message-----
>> From: J.B.W.Webber
>> Sent: 26 June 2013 16:35
>> To: 'Larry Dickson'
>> Cc: Richard Dobson; occam-com@xxxxxxxxxx
>> Subject: RE: Transputer - schools
>>
>> That sounds excellent.
>> I am, right now, part way through building the UKC Kroc installation on a Raspberry Pi - one that already has the aplc array software compiled and running on it. If this works :
>> I aim, with the permission of Peter and the Kent group, to add this to the list of software I will make available on pre-configured plug-in SD cards (with OS) for the Raspberry Pi, at a slight mark-up over the cost I will have to pay someone to sit there making copies of the SD card.
>> Cheers,
>> Beau
>>
>> -----Original Message-----
>> From: Larry Dickson [mailto:tjoccam@xxxxxxxxxxx]
>> Sent: 26 June 2013 16:28
>> To: J.B.W.Webber
>> Cc: Richard Dobson; occam-com@xxxxxxxxxx
>> Subject: Re: Transputer - schools
>>
>> Beau and Tony,
>>
>> I think "occarm" and channel-to-native mapping for Epiphany, etc, are great ideas. The key is to present something people can hack with - using "ordinary" tools with a little boost. Thus, occam functions (at least at first) as pseudocode. The hummocks in the path are:
>>
>> (1) establishing communication superstructure
>> (2) loading executable code
>> (3) assemble resources and start
>> (4) communicate and run
>> (5) shut down cleanly and return resources
>>
>> and communication channels/links should be EXTREMELY general so people can do real stuff.
>>
>> If anyone is interested, I am going to try to launch a Kickstarter
>> project to do some of this. Go to
>>
>> http://www.LAZM.org
>>
>> and follow the "Kickstarter draft link". (It's not live yet, only a
>> preview.)
>>
>> Larry
>>
>> On Jun 26, 2013, at 4:37 AM, J.B.W.Webber <J.B.W.Webber@xxxxxxxxxx> wrote:
>>
>>>
>>> -----Original Message-----
>>> From: Sympa,pkg125 [mailto:sympa@xxxxxxxxxx] On Behalf Of Richard
>>> Dobson
>>> Sent: 26 June 2013 10:17
>>> To: occam-com@xxxxxxxxxx
>>> Subject: Re: Transputer - schools
>>>
>>> On 26/06/2013 08:21, Tony wrote:
>>> ..
>>>>
>>>> Maybe what we need is "occarm" for the Raspberry PI?
>>>>
>>>>
>>>
>>> That would be a great thing to have. Of course the R-Pi already has a parallel processor in the form of the built-in GPU (in the Broadcom chip). Unfortunately there is little scope for programming it directly.
>>> Not exactly CSP-ready, but there are many important/interesting massively-parallel tasks which could be explored. If Broadcom could be persuaded to provide some low latency GPU-based FFT operations, and maybe a few other vector-based arithmetic ops, I am sure a phase vocoder could be got to run in real time on the R-Pi, with enough spare CPU to do some interesting things (such as pitch shifting) with it.
>>>
>>> Richard Dobson
>>>
>>> __________________________________________
>>>
>>> On 26/06/2013 08:21, Tony wrote:
>>> ..
>>>>
>>>> Maybe what we need is "occarm" for the Raspberry PI?
>>>>
>>>
>>> That would be great.
>>> For the Raspberry Pi and Adaptva Parallella we are talking standard Linux host - so presumably quite simple I would have thought.
>>> What will probably be significantly harder is porting Occam so it can say run in the Adapteva multi-cpu Epiphany chips.
>>>
>>> It is to Occam that I look for providing a "harness" in which to embed concise/agile array processing nodes.
>>> So questions arise :
>>>
>>> How difficult will it be to link the communication channels provided by such an Occam harness in a multi-core processor to the pipe input/output of the array processing nodes at each core ?
>>>
>>> How difficult will it be to use the communication channels in a Beowulf Cluster from Occam ?
>>> Cheers,
>>> Beau Webber
>>> www.Lab-Tools.com
>>>
>>>
>>
>>
>
>