Re: What makes Transputer interesting

#2295

Author: Ravi Masand
Date: Wed, 16 Nov 1988 20:11

79 lines
4339 bytes

In article <> josef@ugun21.UUCP writes:
>
>What distinguishes a Transputer from any other processor, especially if
>I take a, let's say 68030 or 32532, add 4 communication channels
>and write software to do processor-processor communication?
>What makes a Transputer so interesting?
>
>		Josef Moellers
>

'Interesting' is a subjective characteristic. I personally feel that the 
transputer is interesting because, atleast from a hardware developer's
viewpoint it offers a lot of bang for the design effort.

Lets start with your 68030 alongwith its four communication channels - to match
the transputer these links need to operate at 10 Mbps and contending with
these communication devices is no cakewalk - both in terms of H/W and S/W

The transputer provides a multitasking kernel built right in the microcode.
The multitasking processes use channels for interprocess communication - and
these channels can be implemented either with memory exchanges or over the
serial links. This can be made transparent to the application programmer. What
this does is that it allows initial development and use over a lesser number
of transputer and at a later time, if so desired, performance can be enhanced
and almost linear speedup achieved, by increasing the number of transputers
in the system and redistributing processes.
As far as the multitasking is concerned, all instructions use a register stack
(on chip) which is valid only for the duration of the instruction. This makes
context switching extremely fast.

This philosophy of integrating the links right into the kernel pays divedends
in another manner. The transputer is capable of booting itself right from 
the links. This implies that in a multiple processor system only one transputer
is required to have a ROM. The others will be perfectly content with a simple
RAM subsystem.

Another hardware facility provided is that of a DRAM controller built right
into the chip. This simplifies DRAM system design considerably.

Also provided in hardware is a floating point unit. As to how it compares with
the 80387 and Motorola's FPU I don't know. Reasonably well I'd suspect. 

Another hardware goody provided is on-chip memory. This is either 2k or 4k
depending on the CPU (T414 or T800 resp). While not much in itself it can
be used for code optimization as instructions running out of this on chip RAM
run a lot faster than from external RAM.

And the final hardware goody provided is an on chip frequency multiplier. 
This means that the different speed versions all take in 5 MHz clocks and 
multiply it appropriately to generate 20/25/30 Mhz. Thus these high frequencies
are restricted to within the chip.

These are all the hardware pluses I can think of. There probably are some
more.

Far as the software is concerned - Inmos claims that a high percentage (~70?) of
the instructions can be coded in one byte. I have looked at the instruction
encoding philosophy and found it to be impressive. If you are at all interested
in CPU architectures you really should look at it. It is, to say the very least,
'Interesting'.
I haven't really had any experience with the software but soon will have some.
But probably not with Occam.

Please keep in mind that I am no transpu-phile and Inmos has no say in my 
material well being. I have simply worked with the CPU for a little while and
was favorably impressed. Furthermore I don't think that the transputer is
'better' than the 68030 or vice versa. For a given application one or the
other may be more appropriate and for still other applications a Z-80/8085
would be clearly more desirable :-).

Questions: Has anyone out there worked with the transputer in  a language other
than Occam ? How has it worked out ? Is Occam really mandatory to use the
CPU to its fullest ? And anyone know of a good book/reference to pick up
Occam in a hurry ??

Thats it. Cheers.
Ravi Masand
Bellcore
(201)-829-4593.

Re: What makes Transputer interesting

#2297

Author: Colin Plumb
Date: Thu, 17 Nov 1988 02:37

45 lines
2835 bytes

First of all, I agree that it's the level of integration that makes
a transputer interesting.  They can do useful work with no external
components - just feed it power, ground, clock, reset line, and
hook up a link or two.  You can boot it, download programs, and run
them.

In article <1389@thumper.bellcore.com> rtm1@thumper.UUCP (Ravi Masand) writes:
>Also provided in hardware is a floating point unit. As to how it compares with
>the 80387 and Motorola's FPU I don't know. Reasonably well I'd suspect. 

It blows them away.  Against good FP ALUs (MIPS, Am29027, BIT's
stuff) it's not great, but it's at least in Weitek's league.
We've timed 2 MFLOPS doing dot products in on-chip RAM.

>Far as the software is concerned - Inmos claims that a high percentage (~70?)
>of the instructions can be coded in one byte. I have looked at the instruction
>encoding philosophy and found it to be impressive. If you are at all interested
>in CPU architectures you really should look at it. It is, to say the very
>least, 'Interesting'.

Well, they have got a patent on it.  I think it's closer to 50%, but still
the code is highly compact.  (There are a few rearrangements I'd like to make,
but that's another story.)  Having programmed it in assembler a fair bit,
I'll avoid "impressive" and stick to "interesting".  There are things they
could have done better.  (Have cj pop the 0?  Unsigned gt?)

>Questions: Has anyone out there worked with the transputer in  a language other
>than Occam ? How has it worked out ? Is Occam really mandatory to use the
>CPU to its fullest ? And anyone know of a good book/reference to pick up
>Occam in a hurry ??

Well, several C compilers are available.  I reccomennd Logical Systems' C
compiler, $6xx.xx with full source last time I looked.  Kirk, are you
still out there to correct me?  They're based in Corvallis, Oregon.  We had
a couple of problems writing our OS in it, but it can handle serious work.

I haven't done any work in Occam, but C works fine.  No, Occam isn't mandatory,
although it makes communications-rich code a bit more legible.  Kirk's
compiler has #pragma asm and #pragma endasm so you can escape to assembler
and get at anything the machine provides.

It's fun to play around with.  I enjoy watching Mandelbrot sets running on
28 processors.
-- 
	-Colin (microsof!w-colinp@sun.com)

Re: Transputer Benchmarks

#2310

Author: jevans David Jevans
Date: Mon, 21 Nov 1988 03:14

22 lines
1384 bytes

Several articles have compared the Transputer to 68000s
(SUN 3s) and VAX 780s.  I had got similar results when
testing some T800s with a beta C compiler (the developer
of which shall remain nameless).  Needless to say I was
less than impressed.  About 2 months ago I got ahold of
another demo board and a Logical Systems C compiler
(from CSA).  My ray tracer, which is very cpu and
floating point intensive, ran 25 times faster than
with the other vendors C compiler.  The execution
time was equal to that of a SUN 4!

This just goes to show you that while hardware may be
the same, the compiler can make all the difference.
I would reccommend potential buyers to test as many
different compilers (C, OCCAM, whatever) before
buying.  You could be wasting a lot of compute
power.

David Jevans, U of Calgary Computer Science, Calgary AB  T2N 1N4  Canada
uucp: ...{ubc-cs,utai,alberta}!calgary!jevans
David Jevans, U of Calgary Computer Science, Calgary AB  T2N 1N4  Canada
uucp: ...{ubc-cs,utai,alberta}!calgary!jevans

Re: Transputer Benchmarks

#2317

Author: Nick Rothwell
Date: Tue, 22 Nov 1988 14:53

34 lines
2336 bytes

In article <228@cs-spool.calgary.UUCP> jevans@.ucalgary.ca (David Jevans) writes:
>Several articles have compared the Transputer to 68000s
>(SUN 3s) and VAX 780s.  I had got similar results when
>testing some T800s with a beta C compiler (the developer
>of which shall remain nameless).  Needless to say I was
>less than impressed.  About 2 months ago I got ahold of
>another demo board and a Logical Systems C compiler
>(from CSA).  My ray tracer, which is very cpu and
>floating point intensive, ran 25 times faster than
>with the other vendors C compiler.  The execution
>time was equal to that of a SUN 4!
>
>This just goes to show you that while hardware may be
>the same, the compiler can make all the difference.

I view this as a non-sequitur. You don't say whether the second board was
identical to the first - same clock speed and so on? I very much doubt that
the compiler has much to do with it, but it's probably the run-time support
(the floating point package, or whatever); perhaps your first version was
running with floating point emulation rather than using the hardware? Perhaps
your second version was configured to use the on-chip RAM for stack space?
Perhaps a lot of things... :-)

Disclaimer: I don't know much about transputer hardware systems, but I
have programmed transputers and know something about compilers.

>David Jevans, U of Calgary Computer Science, Calgary AB  T2N 1N4  Canada
>uucp: ...{ubc-cs,utai,alberta}!calgary!jevans

Nick Rothwell,	Laboratory for Foundations of Computer Science, Edinburgh.
		nick@lfcs.ed.ac.uk    <Atlantic Ocean>!mcvax!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
...while the builders of the cages sleep with bullets, bars and stone,
they do not see your road to freedom that you build with flesh and bone.

Re: Transputer Benchmarks

#2327

Author: Moshe Braner
Date: Fri, 25 Nov 1988 02:46

21 lines
1657 bytes

[response to doubts expressed about posted benchmark]

I've seen compiler differences of 100-fold before, using the same
program on the same hardware.  In this case (a ray-tracing program)
I would guess that the key compiler feature is the trigonometry library,
since the T800 FPU only does +-*/ plus sqrt (sort of).  I have seen
rather naive trig libs using simple algorithms written in C, and, in
contrast, good algorithms hand-optimized in assembler.  The Logical
Systems math library is of the latter sort, and is the fastest there is
on the T800 as far as I know.  So the quoted 25-fold advantage (over a
beta version of an unnamed compiler) seems believable to me.

BTW for graphical rendition purposes single precision is frequently
adequate and a compiler that allows breaking the standard C rule of
doing everything in double wins if it can do single precision faster.
A library that does it even faster in half-precision can also be useful.

- Moshe Braner

"compiled BASIC can be faster than interpreted C"
"Spaghetti code is possible even in Pascal"

🚀 go-pugleaf

Thread View: comp.sys.transputer

Re: What makes Transputer interesting

Re: What makes Transputer interesting

Re: Transputer Benchmarks

Re: Transputer Benchmarks

Re: Transputer Benchmarks

Thread Navigation