Home > Archive > APL > August 2004 > APL for the Cell Processor Architecture?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
APL for the Cell Processor Architecture?
|
|
| Steve Rogers 2004-07-24, 3:55 pm |
| The Sony/IBM/Toshiba cell processor arcitecture
<http://www.linuxinsider.com/story/34548.html> promisses extreme
performance at low cost with a high degree of hardware parallelism,
state of the art semiconductor processing technology, and large volume
consumer device markets. The first systems are likely to ship by the
end of this year, development workstations primarily for game and
movie content creation.
Writing software that makes effective use of hardware parallelism is
often the limiting factor for parallel hardware. Are any APL
implementors looking at how well APL and friends map to this
architecture?
| |
| Robert Bernecky 2004-07-27, 3:56 pm |
| On Sat, 24 Jul 2004 09:16:17 -0400, Steve Rogers wrote:
> The Sony/IBM/Toshiba cell processor arcitecture
> <http://www.linuxinsider.com/story/34548.html> promisses extreme
> performance at low cost with a high degree of hardware parallelism,
> state of the art semiconductor processing technology, and large volume
> consumer device markets. The first systems are likely to ship by the
> end of this year, development workstations primarily for game and movie
> content creation.
>
> Writing software that makes effective use of hardware parallelism is
> often the limiting factor for parallel hardware. Are any APL
> implementors looking at how well APL and friends map to this
> architecture?
You might want to look at APEX, my APL compiler. It generated
SISAL code, and got reasonably good speedups on CRAY and
other multi-processor machines, with NO work from the programmer
at all.
Check my MSc thesis at: www.snakeiland.com
Bob
| |
| phil chastney 2004-07-27, 3:56 pm |
| "Robert Bernecky" <bernecky@rattler.snakeisland.com> wrote in message
news:pan.2004.07.26.02.12.50.122973.1704@rattler.snakeisland.com...
> On Sat, 24 Jul 2004 09:16:17 -0400, Steve Rogers wrote:
>
>
> You might want to look at APEX, my APL compiler. It generated
> SISAL code, and got reasonably good speedups on CRAY and
> other multi-processor machines, with NO work from the programmer
> at all.
>
> Check my MSc thesis at: www.snakeiland.com
>
> Bob
correction: make that www.snakeisland.com
| |
| Steve Rogers 2004-07-28, 3:56 pm |
| Robert Bernecky <bernecky@rattler.snakeisland.com> wrote in message news:<pan.2004.07.26.02.12.50.122973.1704@rattler.snakeisland.com>...
> ...
>
> You might want to look at APEX, my APL compiler. It generated
> SISAL code, and got reasonably good speedups on CRAY and
> other multi-processor machines, with NO work from the programmer
> at all.
>
> Check my MSc thesis at: www.snakeiland.com
>
> Bob
I have your thesis, though I've only begun to read it. Your basic
approach should be applicable to Cell Processors. Unfortunately SISAL
doesn't seem to run under Linux, which appears to be the base OS for
the operating environment that Sony is developing for Cell Processor
applications. It'll be interesting to see what Sony/IBM provide in
the way of development tools.
Regards,
Steve
| |
| Robert Bernecky 2004-08-03, 3:55 pm |
| Hi, Steve,
Two comments here regarding the state of the APEX APL Compiler:
a. As of yesterday, I have managed to compile a simple APL program
(plus reduce iota N, expressed as a :FOR loop) into SAC [cf.].
Once I get the existing set of APEX benchmarks running as well under the
SAC backend as they did under the SISAL backend, I intend to make
the compiler available under the GPL.
b. SISAL most certainly does run under Linux, as does SAC. Back in The
Dark Ages, I spent about two months trying to make SISAL
run under **#^* Windoze,
then gave up, installed Linux for the first time (in a few hours), and
got SISAL running under Linux in another few hours. Piece of cake.
Bob
On Tue, 27 Jul 2004 21:14:00 -0400, Steve Rogers wrote:
> Robert Bernecky <bernecky@rattler.snakeisland.com> wrote in message
> news:<pan.2004.07.26.02.12.50.122973.1704@rattler.snakeisland.com>...
>
> I have your thesis, though I've only begun to read it. Your basic
> approach should be applicable to Cell Processors. Unfortunately SISAL
> doesn't seem to run under Linux, which appears to be the base OS for the
> operating environment that Sony is developing for Cell Processor
> applications. It'll be interesting to see what Sony/IBM provide in the
> way of development tools.
>
> Regards,
> Steve
| |
| Robert Bernecky 2004-08-03, 3:55 pm |
|
Hi, Steve,
Two comments here regarding the state of the APEX APL Compiler:
a. As of 2004-08-03, I have managed to compile a simple APL program
(plus reduce iota N, expressed as a :FOR loop) into SAC [cf.].
Once I get the existing set of APEX benchmarks running as well under the
SAC backend as they did under the SISAL backend, I intend to make
the compiler available under the GPL.
b. SISAL most certainly does run under Linux, as does SAC. Back in The
Dark Ages, I spent about two months trying to make SISAL
run under **#^* Windoze,
then gave up, installed Linux for the first time (in a few hours), and
got SISAL running under Linux in another few hours. Piece of cake.
Bob
Steve Rogers wrote:
> Robert Bernecky <bernecky@rattler.snakeisland.com> wrote in message news:<pan.2004.07.26.02.12.50.122973.1704@rattler.snakeisland.com>...
>
>
>
> I have your thesis, though I've only begun to read it. Your basic
> approach should be applicable to Cell Processors. Unfortunately SISAL
> doesn't seem to run under Linux, which appears to be the base OS for
> the operating environment that Sony is developing for Cell Processor
> applications. It'll be interesting to see what Sony/IBM provide in
> the way of development tools.
>
> Regards,
> Steve
| |
| Steve Rogers 2004-08-04, 3:55 am |
| Robert Bernecky <bernecky@rattler.snakeisland.com> wrote in message news:<pan.2004.08.03.15.40.39.433807.1748@rattler.snakeisland.com>...
> Hi, Steve,
>
> Two comments here regarding the state of the APEX APL Compiler:
>
> a. As of yesterday, I have managed to compile a simple APL program
> (plus reduce iota N, expressed as a :FOR loop) into SAC [cf.].
> Once I get the existing set of APEX benchmarks running as well under the
> SAC backend as they did under the SISAL backend, I intend to make
> the compiler available under the GPL.
>
> b. SISAL most certainly does run under Linux, as does SAC. Back in The
> Dark Ages, I spent about two months trying to make SISAL
> run under **#^* Windoze,
> then gave up, installed Linux for the first time (in a few hours), and
> got SISAL running under Linux in another few hours. Piece of cake.
>
> Bob
>
>
Hi Bob:
This is good news. I obviously gave up too soon. Good luck.
Steve
| |
| Curtis A. Jones 2004-08-06, 3:55 pm |
| I asked Bob Bernecky "What's SAC?"
His response:
"
Hi, Curtis,
SAC is an interesting language, designed by Sven-Bodo Scholz
and others at the Christian-Albrechts Universitat in Kiel, Germany.
Scholz has just taken up a professorship in the UK, but here's
the SAC web site:
http://www.sac-home.org
SAC started out as a purely functional subset of C, so that it
would easy for C programmers to use, then had these things
added to it:
- call-by-value (rather than call-by-reference), so
it's functional
- multiple results (unlike C or APL) - WOW!
- Array extensions, taken from APL
- the WITH-loop: a FORALL loop of sorts, but
more powerful
When Scholz got his WITH-loop-folding optimizations working,
he got superb performance (better than SISAL for most apps!),
but was disappointed to find that all the optimizations
stopped whenever they hit an APL-like array op (take,drop,
reshape, reverse, rotate, etc.).
So... here's the neat insight-- he rewrote the APL extensions
(except for the shape and rank primitives) as SAC defined
functions instead of library routine calls, and presto --
they were now exposed to the optimizations, so performance
was superb AND:
- if you don't like the definition of an APL-like
primitive, you can just modify the library routine
and make your own definition, with NO performance
loss
- the language and the compiler become smaller and simpler!
It's quite neat, although I find the semantics somewhat oddball.
Bob
"
|
|
|
|
|