Implementations for parallel programming?
T. West
I require something beyond threads, e.g., based on MPI, in order
to run on a cluster.
Guile and Schemik offer convenient forms to use threads; other
implementations offer a more low-level interface. But I know none
that would allow to run a program in parallel on a cluster.
For Common Lisp, there exists CL-MPI, which offers MPI bindings
and abstractions. Interesting.
But I'd rather try to stay with Scheme.
Any suggestions?
Jay Reynolds Freeman
piece of software that might help a little bit.
Wraith Scheme, which I provide as shareware for the Macintosh, is
*not* a system that allows you to run in parallel on a cluster, but it
does allow separate Scheme processes on the same computer to run
cooperatively. (The Scheme main memory is shared by all such
processes, which is why Wraith Scheme is a long way from being able to
run on a cluster: Main memory access is of course very frequent and
needs to be fast; network speeds would likely be inadequate for any
useful purpose.) Wraith Scheme provides a couple of straightforward
APIs for the different Scheme processes to talk to one another, which
might conceivably be useful for developing software to run on a real
cluster.
For details, downloads, and a lot of on-line documentation that you
can read without downloading the program or source code, see the
"Software" page of my web site, whose home URL is
http://web.mac.com/Jay_Reynolds_Freeman
Good luck.
Andrew Reilly
> Which Scheme implementations allow to write parallel programs?
As Jay Reynolds has posted, Wraith is one that seems to have shared
memory parallelism (threading) as a design goal. Most of the others, as
far as I can tell, do threads as "green" threads, on a single processor.
There is an experimental version of PLT scheme that introduces the notion
of "futures" that run as OS threads on separate processors, but there are
some catches yet.
I would imagine that the schemes that compile to JVM bytecodes could make
good use of the Sun JVM's good threading and parallel memory management.
However, none of these are what you're after:
> I require something beyond threads, e.g., based on MPI, in order to run
> on a cluster.
That sounds like a job for termite, which runs on (at least) Gambit-C.
Termite claims to provide erlang-style message passing and shared-nothing
parallelism in scheme, and can pass messages both on the same machine and
across networks of machines.
> For Common Lisp, there exists CL-MPI, which offers MPI bindings and
> abstractions. Interesting.
I don't know of an MPI binding for scheme. I suspect that you could
readily use the FFI features of most schemes to use the system MPI
libraries.
> But I'd rather try to stay with Scheme.
Good luck! Please let us know how you get on.
Cheers,
--
Andrew
Ivan Raikov
Hello,
I have created MPI bindings for Chicken Scheme, described here:
http://chicken.wiki.br/eggref/4/mpi
You can download Chicken Scheme from its home page,
http://www.call-with-current-continuation.org/ and use the
chicken-install program to install the mpi library.
Please let me know if you have any questions.
-Ivan
Jay Reynolds Freeman
poster is really, really desperate (and has a Macintosh, and some
knowledge of socket programming), it is would be possible to use
Wraith Scheme's "coarse-grained" foreign-function interface to
construct a means for separate instances of Wraith Scheme, running on
separate computers, to pass the external representations of S-
expressions to one another to be evaluated and to return results of
some kind. There is some sample code distributed with Wraith Scheme
2.10 that shows how to use the foreign-function interface to allow
Wraith Scheme to communicate with other Unix processes running on the
same computer, and return results, and in the sample code that I
provide, I chose to use other processes that were talking to each
other by means of Unix sockets, rather like this (use constant-width
font to see the ASCII graphics):
mmapped shared memory <--> program using sockets
/ |
Wraith Scheme (Unix socket interface)
\ |
mmapped shared memory <--> program using sockets
In this demonstration program, Wraith Scheme merely talks to itself by
roundabout means, through mmapped memory and a couple of C++ programs
that communicate using Unix Sockets. (I chose that for a demo because
I have been using Wraith Scheme to talk to other programs by means of
sockets for personal projects.)
However, it should certainly be possible to use network sockets
instead of Unix sockets, and to have the two "programs using sockets"
on separate computers, talking to separate instances of Wraith
Scheme. In that case, the messages sent would be either text strings
to be read and evaluated, or results retrieved from such evaluation.
(Wraith Scheme has sufficient enhancements over R5 Scheme to make it
possible to write a read-eval-print loop that reads from text strings
and recovers a text version of whatever is printed, to do with what
you will.)
I don't actually recommend that the original poster try this unless
very desperate; I have a feeling that the result would at most be
rather like the celebrated talking dog, remarkable not because it does
it well but because it does it at all ...
Now that I think of it, if I were willing to do a fair amount of work,
I could probably add to Wraith Scheme some kind of facility to send
the internal representation of an S-expression over a socket
interface, either including a substantial lexical closure if required,
or complaining if the closure was "too big", or if the system couldn't
figure out how to do it. I wish I hadn't thought of that, it almost
sounds like fun ...
Jay Freeman
Jay_Reynol...@mac.com
http://web.mac.com/Jay_Reynolds_Freeman
Heiliger
Hi:
I have a question for you. I have often requested people on the Bigloo
mailing list to post some examples teaching us mortal readers how to
use Bigloo for parallel programming task. However, no one seems to be
doing numerical parallelized code. The following introduction
describes the Bigloo thread facilities. Please can anyone
knowledgeable explain to me what the following means in terms of: a)
MPI, b) dual core processors c) Linux (or any other) multi processor
farm. We are using Fortran MPI for our numerical code on our multi
processor machines:
==
Bigloo supports multithreaded programming. Two different libraries
programming are available. The first one, the Fair Thread (see Section
Fair Threads), enables, simple, easy to develop and to maintain code.
The second one, the Posix Thread (see Section Posix Threads) enables
more easily to take benefit of the actual parallelism that is now
available on stock hardware. Because it is easier to program with
fthread than with pthread, we strongly recommend to use the former as
much as possible and leave the former for specially demanding
applications. Both libraries are described in this chapter.
==
Thank you very much indeed,
Ein wahnsinniger Milchbauer
Raffael Cavallaro
> Please can anyone
> knowledgeable explain to me what the following means in terms of: a)
> MPI, b) dual core processors c) Linux (or any other) multi processor
> farm. We are using Fortran MPI for our numerical code on our multi
> processor machines:
>
> =Bigloo supports multithreaded programming. Two different libraries
> programming are available. The first one, the Fair Thread (see Section
> Fair Threads), enables, simple, easy to develop and to maintain code.
> The second one, the Posix Thread (see Section Posix Threads) enables
> more easily to take benefit of the actual parallelism that is now
> available on stock hardware. Because it is easier to program with
> fthread than with pthread, we strongly recommend to use the former as
> much as possible and leave the former for specially demanding
> applications. Both libraries are described in this chapter.
fair threads: minus: "Cooperative threads are not skilled to benefit
of [sic] multi processors [sic] platforms." plus: deterministic
semantics.
posix threads: minus: nondeterministic semantics; require explicit
synchronization management by the programmer.
plus: (on linux) *can* take advantage of multicore hardware.
hth.
--
Raffael Cavallaro
Heiliger
Hi:
Sorry for the naive question: what do you mean by "nondeterministic
semantics"? Does it mean a Bigloo program for a single processor will
not always deliver the same output on a multi processor based on posix
threads?
I really wished the knowledgeable people start posting more examples
here on comp.lang.scheme on how to use Scheme for parallel code.
Thanks,
Foerster vom Silberwald
Raffael Cavallaro
> Sorry for the naive question: what do you mean by "nondeterministic
> semantics"? Does it mean a Bigloo program for a single processor will
> not always deliver the same output on a multi processor based on posix
> threads?
Using fair threads, you can be sure that your code will always execute
in the same order from one run to another because you control the
scheduling from within scheme and everything runs on one core (i.e.,
you have the illusion of concurrency, but really, only one piece of
code is running at any one time).
Using posix threads, you cannot be sure which of two threads will
execute some portion of your code first because they will be scheduled
by the OS scheduler in an unpredictable way. If you have a multicore
machine, two or more threads of code can and will be running at the
same time, and which thread gets to some checkpoint first is
unpredictable, and must be explicitly managed by the use of condition
variables, semaphores and/or mutex locks.
As for your complaint about not posting code, I don't use bigloo. The
docs are completely crystal clear on all of this and my last reply even
included a quote. Read the bigloo docs in the threads section. They're
perfectly clear as long as you know what basic terms like "cooperative"
"condition variable" "semaphore" and "mutex" mean. If you don't, you
shouldn't be doing cocurrent programming until you learn what they are.
--
Raffael Cavallaro
George Neuner
<raffaelc...@pas.espam.s.il.vous.plait.mac.com> wrote:
>On 2010-02-27 08:00:52 -0500, Heiliger said:
>
>> Sorry for the naive question: what do you mean by "nondeterministic
>> semantics"? Does it mean a Bigloo program for a single processor will
>> not always deliver the same output on a multi processor based on posix
>> threads?
>
>Using fair threads, you can be sure that your code will always execute
>in the same order from one run to another because you control the
>scheduling from within scheme and everything runs on one core (i.e.,
>you have the illusion of concurrency, but really, only one piece of
>code is running at any one time).
"Fair" does not mean deterministic, it means that the scheduler
provides a non-starvation guarantee for runnable (i.e. not blocked)
threads.
Only _cooperative_ threads may be completely deterministic because the
programmer decide when and where to yield control. Pre-emptive user
space threads are non-deterministic just as are OS threads ... but
they still may be "fair" wrt starvation.
Many threaded schemes are cooperative, but not all of them.
>Using posix threads, you cannot be sure which of two threads will
>execute some portion of your code first because they will be scheduled
>by the OS scheduler in an unpredictable way. If you have a multicore
>machine, two or more threads of code can and will be running at the
>same time, and which thread gets to some checkpoint first is
>unpredictable, and must be explicitly managed by the use of condition
>variables, semaphores and/or mutex locks.
In general, the same caveats apply for pre-emptive user space threads.
George
Raffael Cavallaro
> "Fair" does not mean deterministic, it means that the scheduler
> provides a non-starvation guarantee for runnable (i.e. not blocked)
> threads.
"Fair" is the name of the Bigloo *cooperative* threading API. Bigloo
has two threading APIs, "Fair Threads" and "Posix Threads." These are
not my terms, but the names of the Bigloo APIs.
--
Raffael Cavallaro
George Neuner
"Fair" enough 8)
George