Parallel Lisp

The person was asking about parallel language for LISP.

Paradigm: concurrent

Ada ----- Since the closing of the DOD mandate it has falling out
of favor, even though it still being use. GNAT is the
main suppiler and free, but it uses GCC and is under
GNU License. Current Version of Ada is 2005, but some
compiler are still using Ada 95 spec. Also, GNAT only uses
one processor in their current version.

Occam -- It is also falling out of favor. The parallel designed
structure is no longer maintain, since 1996.


Paradigm: parallel

ACL2 -- Lisp type of parallel that uses SBCL and OpenMCL. But it
stll is not true parallel.


Sisal -- it was designed by the people of LLNL for a SMP
type of systems. I even experiment with it on a 8
cpu system design at LLNL.

Other compilers such as Parallel Lisp, C, FORTRAN, and COBOL
still out of price for the average user. And they are not rated for
the new dual processors from Intel or AMD.

There are some projects that, but most are using PVM, MCP,
or Beowulf design using multi system or boards using Pentium or
AMD. But the processors like the old Pentium D, or new Core 2
(Dual/Quad) have not been around that long.


Beowulf -- Beowulf.org Design witch deals with clusters, type of
parallel.


Paradigm: ???

SBCL -- Not true parallel. Some projects have used SBCL in their
parallel design. Such as ACL2.


In <slrnfeb7ar.pbl.als@mordor.angband.thangorodrim.de >, Alexander Schreiber <als@usenet.thangorodrim.de> writes:
>anon <anon@anon.org> wrote:
>> Sometime between 1995 and 2005 (last time I checked) all parallel and
>> concurrent languages seam to have disappeared. Now, that the average
>> person can buy or build a multi-processor system, we needs these
>> languages but for some reason they are no where to be found.
>
>Hmm, Occam is still alive, with at least two freely available compilers:
> - KROC (Kent Retargetable Occam Compiler):
> http://www.cs.kent.ac.uk/projects/ofa/kroc/
> - The Amsterdam Compiler Kit also appears to contain an Occam compiler
> http://tack.sourceforge.net/
>
>Occam was designed as the native programming language for transputer
>systems (inherently parallel to massive parallel architecture).
>
>There is also ADA, which has multiprocessing as part of the language
>spec, with GNAT as a free compiler environment:
>http://www.gnu.org/software/gnat/gnat.html
>
>One can also do parallel programming in Lisp, preferable one that maps Lisp
>threads to operating system threads. As far as I'm aware, the only
>freely available Lisp for x86 that does this is SBCL - where it works
>nicely as the previous poster already wrote.
>
>> I know of only one parallel language that is non-lisp called "Sisal". It
>> is still on the net but is no longer supported by LLNL. It automatic
>> creates parallels code for the user.
>
>I am rather wary of such claims - typical code not explicitly designed for
>parallel execution tends not to win much by automagic parallelisation.
>
>> Just found an older parallel version of *lisp or StarLisp simulator which
>> may be downloaded at bottom of the following archive URL page but it
>> was created back in 1989.
>> File Name = Starsim-f20.zip File size = 580 KB
>>
>> http://examples.franz.com/index.html
>>
>> "*Lisp (pronounced "star Lisp") is a data parallel extension of the
>> Common Lisp programming language, designed for the Connection
>> Machine system."
>>
>>
>>
>> In <1189002231.167450.110710@k79g2000hse.googlegroups .com>, "Mike G." <michael.graffam@gmail.com> writes:
>>>I've spent a little free time over the last two months building a
>>>multi-processor / multi-core network computer in my basement. In no
>>>time at all, I've been able to hack up some primitives for doing
>>>parallel processing across this network in SBCL.
>>>
>>>My question is: can someone provide some names of parallel lisp
>>>environments? I know of *Lisp. Anything else? I've been trying to
>>>scare up a copy of the *Lisp Dictionary.
>>>
>>>Ultimately, I'm looking for parallel Lisp idioms to implement on top
>>>of my primitives.
>>>
>>>Right now, I have a macro plet which has the form:
>>>
>>>(plet ((var1 (foo1))
>>> (var2 (foo2))
>>> ...)
>>> (exit-form)
>>> (form1)
>>> (form2)
>>> ...)
>>>
>>>The idea is that the variables get initialized (as per an ordinary
>>>let), each form in the body gets executed in parallel, and exit-form
>>>is a chunk of code that executes after all parallel threads have ended
>>>which ties everything together. This macro expands into my primitives
>>>to initialize / access variables via my centralized tracker and a loop
>>>which patiently waits for the threads to complete. Works well enough.
>>>
>>>I also have a parallel MAP which splits a map up across multiple
>>>cpu's / cores.
>>>
>>>Implementing this is what made me come looking for guidance because I
>>>can think of several ways to split up a MAP that might make sense
>>>under different circumstances.
>>>
>>>Any ideas or pointers area welcome.
>
>
>--
>"Opportunity is missed by most people because it is dressed in overalls and
> looks like work." -- Thomas A. Edison

On Sep 10, 12:52 pm, "Mike G." <michael.graf...@gmail.com> wrote:
> On Sep 10, 3:03 am, alex.repenn...@gmail.com wrote:
>
>
>
> > On Sep 5, 4:23 pm, "Mike G." <michael.graf...@gmail.com> wrote:
>
> I had contemplated using PS3's instead of my bare-bones Xeons. It
> costs
> me more money per core this way (about twice as much, in fact) but I
> can
> easily add all the RAM I like.

One discouraging, in terms of parallel computation, performance issue
is that of the 2 Tflops the PS3 makes 0.2 are by the 8 cells and 1.8
by the SINGLE GPU.

>
>
> > Repenning, A., Collaborative Diffusion: Programming Antiobjects. in
> > OOPSLA 2006, ACM SIGPLAN International Conference on Object-Oriented
> > Programming Systems, Languages, and Applications, (Portland, Oregon,
> > 2006), ACM Press.
>
> >http://www.cs.colorado.edu/~ralex/pa...ntiobjects.pdf
>
> Thanks for the link. I'll let you know if I end up doing anything
> related to this.

ps. forgot to say what is probably most interesting to this group. The
current implementation, including visualization, of Antiobjects is all
done with Lisp.

Just found this on the net:
The article is something like Microsoft saying we would neven need
more than 640K for Ram size. But it does give other information.


Microsoft sees shift to parallel in 10yrs
Posted: 03 Sep 2007


Multicore processors are driving a historic shift to a new parallel
architecture for mainstream computers. But a parallel programming
model to serve those machines will not emerge for five to 10 years,
according to experts from Microsoft Corp.

...

by Rick Merritt
EE Times

The complete artile can be found at:
http://www.eetasia.com/ART_880047801...T_692e7452.HTM

On Sep 11, 5:13 am, alex.repenn...@gmail.com wrote:

> One discouraging, in terms of parallel computation, performance issue
> is that of the 2 Tflops the PS3 makes 0.2 are by the 8 cells and 1.8
> by the SINGLE GPU.

Actually, I think the PS3 has only 7 cells (to increase usable yield
out
of the fab). But yes.. requiring access to the GPU stinks - mostly
because
AFAIK, we have no open specs for it.

> ps. forgot to say what is probably most interesting to this group. The
> current implementation, including visualization, of Antiobjects is all
> done with Lisp.

Is the source available?

On Sep 11, 9:22 am, a...@anon.org (anon) wrote:
> Just found this on the net:
> The article is something like Microsoft saying we would neven need
> more than 640K for Ram size. But it does give other information.

This is kinda funny, mostly because some serious multi-core machines
are available today. And with AMD entering the race with a quad
Opteron, and 8-core systems from Intel on the immediate horizon, I
expect to see prices for 4/8-way systems fall to a reasonable range
within a year or two. Now, granted, my definition of "reasonable" may
be slightly higher than some people's, but still.. they are coming,
and they'll be here before the decade mark for sure.

On an altogether different note, I've put some new constructs into my
parallel programming environment this morning for data-driven
parallelism. Each core/node recieves data on a socket, applies a
transform to it, and pumps it out a socket to another core/node. Its
very limited right now -- I have to expand it to allow multiple
inputs / outputs, for instance. But the basic method seems OK - I got
pretty good results doing a simple FFT / filter / iFFT chain. Not as
fast as an analog computer though

That's the reason I posted it.

Everyone one know there are the groups that are into supercomputers. But
what Microsoft forgot is the two new groups on the block.

First, even though it been around a while is the Internet servers. They
need all the power they can get. But what they really need is "Internet 2"
for bandwidth.

But the newest person is the Gamer. They want more and more power to
play those games. And they are willing to spend the money for that power.
Intel and AMD knows this and are will to comply with the Gamer.

But Microsoft like always will play catch-up and try to dominate the field
of software, again.


In <1189614703.140874.284250@d55g2000hsg.googlegroups .com>, "Mike G." <michael.graffam@gmail.com> writes:
>On Sep 11, 9:22 am, a...@anon.org (anon) wrote:
>> Just found this on the net:
>> The article is something like Microsoft saying we would neven need
>> more than 640K for Ram size. But it does give other information.
>
>This is kinda funny, mostly because some serious multi-core machines
>are available today. And with AMD entering the race with a quad
>Opteron, and 8-core systems from Intel on the immediate horizon, I
>expect to see prices for 4/8-way systems fall to a reasonable range
>within a year or two. Now, granted, my definition of "reasonable" may
>be slightly higher than some people's, but still.. they are coming,
>and they'll be here before the decade mark for sure.
>
>On an altogether different note, I've put some new constructs into my
>parallel programming environment this morning for data-driven
>parallelism. Each core/node recieves data on a socket, applies a
>transform to it, and pumps it out a socket to another core/node. Its
>very limited right now -- I have to expand it to allow multiple
>inputs / outputs, for instance. But the basic method seems OK - I got
>pretty good results doing a simple FFT / filter / iFFT chain. Not as
>fast as an analog computer though
>