-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
http://lispnik.newmail.ru/lpvm
LPVM is PVM3 bindings for Common Lisp with UFFI.
PVM is Parallel Function Machine, message-passing communication
library for parallel computations.
This package requires UFFI. See http://www.clicki.net/UFFI for more
information.
This is pre-alfa version of LPVM. It was developed and tested with
CMU CL 18e. I used UFFI for portablity, but I'm not sure I got UFFI
docs right. So, patches are welcome :)
Some function has special fast implementation for CMU CL.
LPVM is distributed under terms of MIT-like license. See LICENSE.MIT
for more details.
- --
Ivan Boldyrev
| recursion, n:
| See recursion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUBQIqOiQ4ALcwzZFpVAQJgkAf8DKsR/g3XnJNJDNZ9TlpgA9toaJIILgfg
a5j/5xNinJ0gTVqSWHRHTEYyxmSe60FroGw0dX/gYxvEpraz08k+fgBJpT2gKbxg
0U1p4cf513Ogi+N3CRFbaP54izTPeP3JUnXPT3QfJWNXjYItggXdVWAHUMU+TcsU
cwi9sOybkETiPi8id3sB3KOpCcUg/FTkG0DKC6NDtEBpRXD+1vQmo7vKwEQAnPNk
FL3LFFBQb3vsS+prp7aFO2cij6KTLS5g3RoZxViwSEotOLySdHzVLPNWlz4p6G9E
dyECSx8OmJAIXkct2VZu14GzQS4MC0KoKT5jtTIITaGuBiQKyL+G4g==
=zrEK
-----END PGP SIGNATURE-----
Ivan Boldyrev wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://lispnik.newmail.ru/lpvm
>
> LPVM is PVM3 bindings for Common Lisp with UFFI.
Cool. Pardon a Networking for Dummies question, but can this be used
instead of sockets? Or does it sit on top of sockets? I looked around
but could figure out: can I just give it an ip address when adding hosts?
kenny
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8725 day of my life Kenny Tilton wrote:
> Ivan Boldyrev wrote:
>
>> http://lispnik.newmail.ru/lpvm
>> LPVM is PVM3 bindings for Common Lisp with UFFI.
>
> Cool. Pardon a Networking for Dummies question, but can this be used
> instead of sockets?
Probably :) But PVM is more high-level than sockets.
Main difference: with sockets you communicate from ip+port to ip+port
with sequences of bytes. With PVM you communicate from task to task
with messages (messages has message IDs which are similar to
conception of ports). Two task may run at different or same machine,
but they communicate in same faction. Plus group operations, barrier
synchronization etc.
Here is a sample of passing a message from one process to another:
(defconstant +msgid+ 101)
;;; One task
(defun send-data (recipient len)
;; Generate data
(let ((ddata (make-array len
:element-type 'double-float
:initial-contents
(loop :for i :from 1 :to len
:collect (sin (coerce i 'double-float))))))
(pvm:send-message (recipient +msgid+)
(pvm:pkint len) ; Send size of array
(pvm:pkdouble ddata len)))) ; Send array
;;; Second task
(defun recv-data ()
(let ((ddata (make-array len
:element-type 'double-float)))
(pvm:recv-message (-1 +msgid+ ret) ; -1 means "from any sender"
(let ((len (pvm:upkint))) ; Unpack number -- length of data
(pvm:upkdouble-array len))))) ; Unpack array of double floats
(NO WARRANTY: this is modification of one of samples. I did test
original version, but I didn't test modified one.)
PVM:SEND-MESSAGE and PVM:RECV-MESSAGE are macros that can be used when
you do not worry about error-checking :)
You can pass strings, numbers of different sizes (C/FORTRAN types only).
> Or does it sit on top of sockets?
Implementation dependent. For example, implementation for
multiprocessors can use shared memory, and so on...
And there are indeed some version of PVM for special hardware:
PVM is a software system that enables a collection of
heterogeneous computers to be used as a coherent and flexible
concurrent computational resource.
The individual computers may be shared- or local-memory
multiprocessors, vector supercomputers, specialized graphics
engines, or scalar workstations, that may be interconnected by
a variety of networks, such as ethernet, FDDI.
And all implementations must be interoperable.
> I looked around but could figure out: can I just give it an ip
> address when adding hosts?
Implementation dependent, again :) Common implementation for clusters
can. But added host must be pre-configured: e.g. you must provide a
way to run tasks at added host (again, it's for common implementation;
I don't know about other ones). It is usually done with SSH pubkey
authentication or just RSH for clusters in protected networks. If SSH
daemon is started by system administrator, all other configuration job
may be performed by user.
I wouldn't use PVM for implementing Internet service a-la HTTP server
or something like that. All nodes of PVM are parts of united Parallel
Virtual Machine, and they are, ahem, almost equal :)
- --
Ivan Boldyrev
Is 'morning' a gerund?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUBQIrJaw4ALcwzZFpVAQJpJQf/aaG0TWDAjs1xczi7WEvtrrphwu8sLtr/
kifb2BieMtYCg+R3NOJB/G3oizJihMFdiJBUlSUWIU6KJTGwRl+tX/nIo2li0oHm
S3CrVGa3ygVk42y2Pe/9Mw9YqEOeDbcUO/YaMvl7XjVtvZigDeIrRPkWao72txDb
lxCQZyi+mcsWHFzgaHZz/4L3qT2eAt7WY+CceaizjDgTMLSdYr6i4NhiFa79qqsZ
5tJFA+s8HH2EUcngwqJSROAbdhq3pY+NH+sAPXcBS0UG4Tk/vsuV/VNnwd+My2sM
pY0hFTnU5pkjIzUj5QzutMn9WAxwUWDGrRTCLC6x8m0vhNiTVmdn1Q==
=SqXR
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8725 day of my life Kenny Tilton wrote:
> Ivan Boldyrev wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> http://lispnik.newmail.ru/lpvm
>> LPVM is PVM3 bindings for Common Lisp with UFFI.
>
> Cool. Pardon a Networking for Dummies question, but can this be used
> instead of sockets? Or does it sit on top of sockets? I looked around
> but could figure out: can I just give it an ip address when adding
> hosts?
Suggested reading:
* An Introduction to PVM Programming
Short description PVM and most important functions
<http://www.csm.ornl.gov/pvm/intro.html>
* PVM: Parallel Virtual Machine: A Users' Guide and Tutorial for
Networked Parallel Computing
(aka PVM Book) On-line version of book published in 1994 by MIT Press.
<http://www.netlib.org/pvm3/book/pvm-book.html>
* PVM: Parallel Virtual Machine
Main site. Source code, documentation, links etc.
<http://www.csm.ornl.gov/pvm/pvm_home.html>
- --
Ivan Boldyrev
Your bytes are bitten.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUBQIrLzg4ALcwzZFpVAQLOgggAm0EcWigAjgaAG9lnaSUJczoKlfWgcB7b
yX5V0o9u5Y9yaP4/hcHZf2RZOSBgyWtauy7Soy3IuXLBRzp715jj9M/ePyU9PBYp
9aFwSc8vkzCrch4HcbXa8fyFes7rMYoTtR1tgSrhAVx5XI1Lz0OeN2Ll/oMnHjAd
TMBiZYxwYIVVNjkn3JjA8vDlhGaPAS3n7+X6VwJNc5QgxHzGFIYSCWnMx5cb6MiL
Th/6l54tdH253PNqPPEf0ASWulHkT00s2G7O+h7HcfNuwn+r/cxniYjXTo5GyYjz
bw5d2Qd0BoxnUz/E5pHrRpTkfamWKeSYLBPltjL2HOcKDfPn/Sf52w==
=IyZ6
-----END PGP SIGNATURE-----
Ivan Boldyrev <···············@cgitftp.uiggm.nsc.ru> writes:
> On 8725 day of my life Kenny Tilton wrote:
> > Ivan Boldyrev wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >> http://lispnik.newmail.ru/lpvm
> >> LPVM is PVM3 bindings for Common Lisp with UFFI.
> >
> > Cool. Pardon a Networking for Dummies question, but can this be used
> > instead of sockets? Or does it sit on top of sockets? I looked around
> > but could figure out: can I just give it an ip address when adding
> > hosts?
>
> Suggested reading:
>
> * An Introduction to PVM Programming
> Short description PVM and most important functions
> <http://www.csm.ornl.gov/pvm/intro.html>
>
> * PVM: Parallel Virtual Machine: A Users' Guide and Tutorial for
> Networked Parallel Computing
> (aka PVM Book) On-line version of book published in 1994 by MIT Press.
> <http://www.netlib.org/pvm3/book/pvm-book.html>
>
> * PVM: Parallel Virtual Machine
> Main site. Source code, documentation, links etc.
> <http://www.csm.ornl.gov/pvm/pvm_home.html>
I am going to have a look at these links. Just one question: How is
PVM as compared to MPI? Is it similar, or at a different level of
abstraction?
Bj�rn
> I am going to have a look at these links. Just one question: How is
> PVM as compared to MPI? Is it similar, or at a different level of
> abstraction?
I'd say this is the sort of question people don't really agree on. If
you stand far enough away and squint, they solve roughly the same
kinds of problems, but if you start to examine them closely and talk
to the advocates of one system or the other, they come off as quite
different (i.e., Google for "PVM vs MPI"). Speaking *very* roughly,
I'd say that MPI is stronger if you're trying to build a "fine-grained
parallel" system, where all the computers are really doing the same
thing --- you're multiplying a vector by an enormous matrix, and you
want different machines to store and operate on different parts of the
matrix. PVM is stronger if you're doing something heterogenous ---
different machines connected to different databases, for instance.
That said, I've not actually used MPI. I've used PVM some and found
it useful.
rif
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8725 day of my life Björn Lindberg wrote:
>> Suggested reading:
...
>> * PVM: Parallel Virtual Machine
>> Main site. Source code, documentation, links etc.
>> <http://www.csm.ornl.gov/pvm/pvm_home.html>
>
> I am going to have a look at these links. Just one question: How is
> PVM as compared to MPI? Is it similar, or at a different level of
> abstraction?
Level of abstraction is rather same, but MPI has more functions than
PVM. And AFAIK some of PVM creators took part in creation of MPI
standard.
Key differences:
1. MPI is standard, PVM is defined by implementation (it's like
Common Lisp and Perl).
2. PVM is interoperable, MPI implementation may not (i.e. hosts of
different architectures can be members of virtual machine). MPI
standard doesn't even guarantee that C program is interoperable
with FORTRAN program compiled with libraries of same vendor...
3. PVM is fault-tolerant, MPI is not. If any task of MPI system
crash, nothing useful happen (I do not remember exactly: may be
whole system must halt execution, may be tasks just can't know if
other task/host crashed...). In PVM, negative return value of
most of functions is sign of some error. And even more, task
may ask for notification about crash of other task or host.
4. PVM is dynamic (tasks can be created and finished at runtime,
hosts can be added and removed at runtime), MPI is static (though
MPI-2 can spawn new tasks).
5. MPI has more communication functions and some concepts as
datatypes.
6. Rumors: PVM is slower. Because of 2, 3, 4 and other issues.
But you better see paper "PVM and MPI: A Comparison of Features"
<http://www.csm.ornl.gov/pvm/PVMvsMPI.ps>.
- --
Ivan Boldyrev
Perl is a language where 2 x 2 is not equal to 4.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUBQIwHXQ4ALcwzZFpVAQKM2Af/S9PAj5znW8x1DERAywj/eOd7M3CmH3Ri
2gVDo452nrH558vKjShsTQCek4e1rcF9O7Jid0xOdIqxY/fK4+y+/+y7zDQ2xSj9
tyIGH4L8MrCSoxlRXTwNicKwg8LiyNdiAgmPakowywKcnw6ypDcfp3EPBw+RdAA9
svqDZPaLEDp8IX+kAMMZpmIjFViiJOGC9EWawOemMFOg/oMRi3JuKxMkw5X0p9GM
mr4ls3hC2n8Gd5cL3Xb7J2RtVAz3h/FOCLXSgcj1o1PoxtximR6DQacphJe4EJ0n
dJI9R28gEpzY40fM1DnGStCAe7Hi3STYC9INXMc6uUA2KVIpASFj7A==
=niMa
-----END PGP SIGNATURE-----
Kenny Tilton <·······@nyc.rr.com> writes:
> Cool. Pardon a Networking for Dummies question, but can this be used
> instead of sockets? Or does it sit on top of sockets? I looked around
Are there any Common Lisp benchmark programs using sockets
available/published?
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
>>>>> "PG" == Petter Gustad <·············@gustad.com> writes:
[...]
PG> Are there any Common Lisp benchmark programs using sockets
PG> available/published?
None that I know of other than the little toy one at Bagley's shootout
page. If you are concerned about http, I suppose you could use
apache bench (called ab comes with apache) with lisp web servers. AFAIR
some cl web servers come with web flogger code for testing and
benchmarking.
I too would be interested to find out if there is more.
cheers,
BM
* Petter Gustad wrote:
> Are there any Common Lisp benchmark programs using sockets
> available/published?
Not published (or in fact available), but I did some tests using ACL a
fair while ago that indicated it was obviously limited by network
bandwidth. This was on a 100Mbit ether, Gbit or faster might be
different. I didn't test open/close performance, but anyone who cares
about performance will presumably trying to keep the socket open and
send multiple requests. It is possible that for character streams
things could now be worse as there is (perhaps) more encode/decode
overhead now it does Unicode (this was pre Unicode in ACL). On the
other hand it was also pre simple streams, which I expect are faster
again.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Petter Gustad wrote:
>
> > Are there any Common Lisp benchmark programs using sockets
> > available/published?
>
> Not published (or in fact available), but I did some tests using ACL a
> fair while ago that indicated it was obviously limited by network
> bandwidth. This was on a 100Mbit ether, Gbit or faster might be
My intention was to measure bandwidth and latency using various
interconnects. I was hoping to find some standard Common Lisp socket
benchmarks for this purpose. We recently made a socket interface for
our interconnect and the latency is at 2.27 microseconds
(send/receive) and the bandwidth has been measured to up to 255
MBytes/sec(1).
Further, I got the impression that some people were using sockets and
some sort of remote eval to do parallel programming in Lisp, rather
than running MPI, PVM, or similar. A low latency interconnect high
speed interconnect would most likely result better application
scalability in such a case.
Petter
1) http://www.dolphinics.no/news/2004/2_25.html
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad <·············@gustad.com> wrote in message news:<··············@scimul.dolphinics.no>...
>
> My intention was to measure bandwidth and latency using various
> interconnects. I was hoping to find some standard Common Lisp socket
> benchmarks for this purpose. We recently made a socket interface for
> our interconnect and the latency is at 2.27 microseconds
> (send/receive) and the bandwidth has been measured to up to 255
> MBytes/sec(1).
I don't see any reason for socket overhead in Lisp to be significantly
more than it is for C. Without extreme cleverness the two places I
can think of are stream encoding/decoding for character streams
(because of external formats) which you can just avoid by using
non-character streams, and spurious copies, which could cost you a
fair amount. I think that simple streams has some mechanisms which
can avoid copying buffers.
Beyond that, I suspect that serious C-based comms things do amazing
tricks to ensure zero-copy and things like that (much of which
obviously requires OS support), as well as asynchronous I/O and all
sorts of magic things. But I wonder how many applications actually
*do* that? Certainly some do.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> Petter Gustad <·············@gustad.com> wrote in message news:<··············@scimul.dolphinics.no>...
>
> >
> > My intention was to measure bandwidth and latency using various
> > interconnects. I was hoping to find some standard Common Lisp socket
> > benchmarks for this purpose. We recently made a socket interface for
> > our interconnect and the latency is at 2.27 microseconds
> > (send/receive) and the bandwidth has been measured to up to 255
> > MBytes/sec(1).
>
> I don't see any reason for socket overhead in Lisp to be significantly
> more than it is for C. Without extreme cleverness the two places I
I didn't expect that either. I was hoping to find a standard Lisp
benchmark, presumably a parallel application using sockets, and see
the speedup I would get by replacing ethernet with my favorite
interconnect.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
>>>>> On 29 Apr 2004 22:43:04 +0200, Petter Gustad ("Petter") writes:
Petter> ··········@tfeb.org (Tim Bradshaw) writes:
>> Petter Gustad <·············@gustad.com> wrote in message news:<··············@scimul.dolphinics.no>...
>>
>> >
>> > My intention was to measure bandwidth and latency using various
>> > interconnects. I was hoping to find some standard Common Lisp socket
>> > benchmarks for this purpose. We recently made a socket interface for
>> > our interconnect and the latency is at 2.27 microseconds
>> > (send/receive) and the bandwidth has been measured to up to 255
>> > MBytes/sec(1).
>>
>> I don't see any reason for socket overhead in Lisp to be significantly
>> more than it is for C. Without extreme cleverness the two places I
Petter> I didn't expect that either. I was hoping to find a standard Lisp
Petter> benchmark, presumably a parallel application using sockets, and see
Petter> the speedup I would get by replacing ethernet with my favorite
Petter> interconnect.
There isn't a "standard Lisp" benchmark of anything, since there
are many entirely distinct implementations of Common Lisp.
Maybe if you pointed to the standard benchmark in some other language,
along with the platform specifications, someone might write the same
program in one or more Common Lisp implementations.
(I'm not really volunteering to be that someone, at this moment.)
But when you refer to a "parallel application", I'm not sure what
you're talking about. If you mean a program that opens a bunch of
sockets in parallel, it sounds like this would be benchmarking quite
a lot of things other than sockets; it would involve process scheduling
(and I can think of several different techniques that bring up all
kinds of different issues in that area). Not to mention that you would
be benchmarking whatever work it is that this program does.
(It goes without saying that you're benchmarking the operating system.)
Another approach would be to pick the Lisp implementation that you
are considering, and write a simple sockets program that does either
approximately no work, or some work like you had in mind for the real
program. Then you could see how well it performs, and ask for help
in tuning it. And if there are problems in the sockets interface in
the Common Lisp you're using, perhaps you can get the vendor to tune
that end of it. (And notice that we're already talking about possibly
changing your code around; read on.)
In general, you ought to write your program with enough abstraction
so that the communication layer is quite seperate from the work to be
done, and so that the interface to the low-level communications will
work with whichever strategy you pick. "Sockets" is a rather low-level
abstraction. You probably want at least "stream" or "message", instead.
And on top of that would be be your application-specific protocol.
If you take this approach, it will be easier to plug in a better
communications implementation later on, if it turns out you need that,
or if you want to change it for some other reason.
······@news.dtpq.com (Christopher C. Stacy) writes:
> Petter> I didn't expect that either. I was hoping to find a standard Lisp
> Petter> benchmark, presumably a parallel application using sockets, and see
> Petter> the speedup I would get by replacing ethernet with my favorite
> Petter> interconnect.
>
> There isn't a "standard Lisp" benchmark of anything, since there
> are many entirely distinct implementations of Common Lisp.
There are common benchmark programs like the Gabriel benchmark. In the
C/Fortran world SPEC is common for integer and floating point
performance.
> Maybe if you pointed to the standard benchmark in some other language,
> along with the platform specifications, someone might write the same
> program in one or more Common Lisp implementations.
Netperf (www.netperf.org) if fairly common. But I don't think there is
much point of porting it. Again, I was hoping that there was some kind
of socket benchmark program that was commonly used in the Common Lisp
community.
> (I'm not really volunteering to be that someone, at this moment.)
>
> But when you refer to a "parallel application", I'm not sure what
> you're talking about. If you mean a program that opens a bunch of
I was thinking of an application which was sending data or Lisp code
over the socket for parallel execution. I got the impression that Lisp
programmers was writing parallel programs using remote eval, or
passing data (SIMD) over the socket rather than using MPI and PVM. My
conception might be completely wrong however.
> sockets in parallel, it sounds like this would be benchmarking quite
> a lot of things other than sockets; it would involve process scheduling
> (and I can think of several different techniques that bring up all
> kinds of different issues in that area). Not to mention that you would
> be benchmarking whatever work it is that this program does.
> (It goes without saying that you're benchmarking the operating system.)
This is true. But my goal was to benchmark the interconnect using some
hopefully well known Lisp benchmark application (which does not seem
to exist).
> Another approach would be to pick the Lisp implementation that you
> are considering, and write a simple sockets program that does either
> approximately no work, or some work like you had in mind for the real
> program. Then you could see how well it performs, and ask for help
> in tuning it. And if there are problems in the sockets interface in
> the Common Lisp you're using, perhaps you can get the vendor to tune
> that end of it. (And notice that we're already talking about possibly
> changing your code around; read on.)
This is good advice. But I don't have an application. I have an
interconnect that I wanted to know if it could provide a relevant
performance increase for Lisp socket based applications. I should have
emphasized this earlier.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad <·············@gustad.com> wrote in message news:<··············@zener.home.gustad.com>...
> This is good advice. But I don't have an application. I have an
> interconnect that I wanted to know if it could provide a relevant
> performance increase for Lisp socket based applications. I should have
> emphasized this earlier.
If you'll lend me some of the interconnect I'll write some benchmarks (:-).
--tim
Petter Gustad wrote:
> This is good advice. But I don't have an application. I have an
> interconnect that I wanted to know if it could provide a relevant
> performance increase for Lisp socket based applications. I should have
> emphasized this earlier.
This is interesting. A Cello porter suggested extending Cells (my little
dataflow hack) to work across a network. This would be useful for I do
not know what. But online gaming springs to mind, where multiple users
are effectively sharing a single application. the idea would be to make
the network disappear by building some networking into Cells. This would
unleash the developer's creativity by letting them forget about
funneling everything through a socket (or multiple sockets if that is
what they do, I haven't a clue); two remote users just seem like two
instances in a single application space, and the developer is free to
author as fine a granularity of interaction as they like.
The downside would be the overhead of sending extremely small data
pulses in individual socket messages. probably a buffering scheme would
be necessary to bundle up a bunch of dataflow pulses into one socket
message.
Cells already handle inter-instance dependencies which commence by one
instance finding another by searching an application namespace, so that
just needs to be extended to know about URLs or somesuch. Add the
interconnect mechanism and away we go. I guess GUIDs, too.
How available is your interconnect to others?
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Petter Gustad wrote:
> > This is good advice. But I don't have an application. I have an
> > interconnect that I wanted to know if it could provide a relevant
> > performance increase for Lisp socket based applications. I should have
> > emphasized this earlier.
>
> This is interesting. A Cello porter suggested extending Cells (my
> little dataflow hack) to work across a network. This would be useful
> for I do not know what. But online gaming springs to mind, where
> multiple users are effectively sharing a single application. the idea
> would be to make the network disappear by building some networking
> into Cells. This would unleash the developer's creativity by letting
> them forget about funneling everything through a socket (or multiple
> sockets if that is what they do, I haven't a clue); two remote users
> just seem like two instances in a single application space, and the
> developer is free to author as fine a granularity of interaction as
> they like.
This sounds neat, but the interconnect I have in mind (SCI - IEEE Std
1596) is targeted for clusters, i.e. box to box (up to 10 meters).
Gamers are more happy when they can shoot each other whithout seeing
the other guy on the other side of their monitor.
> The downside would be the overhead of sending extremely small data
> pulses in individual socket messages. probably a buffering scheme
> would be necessary to bundle up a bunch of dataflow pulses into one
> socket message.
This is a case where SCI is optimal because of the low latency. You
can send small abounts of data using PIO and use DMA for larger data
transfers.
> Cells already handle inter-instance dependencies which commence by one
> instance finding another by searching an application namespace, so
> that just needs to be extended to know about URLs or somesuch. Add the
> interconnect mechanism and away we go. I guess GUIDs, too.
>
> How available is your interconnect to others?
You can find sales offices i most regions:
http://www.dolphinics.no/sales/
There's also a white paper on the socket interface at:
http://www.dolphinics.no/papers/abstract/sci_socket.html
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
>>>>> On 30 Apr 2004 00:38:27 +0200, Petter Gustad ("Petter") writes:
Petter> But I don't have an application. I have an interconnect that
Petter> I wanted to know if it could provide a relevant performance
Petter> increase for Lisp socket based applications. I should have
Petter> emphasized this earlier.
If I understand you correctly, you have a library that one would
use instead of programming using the sockets library. If that's
what you're saying, then what you would need to do is to develop
the library binding for Lisp. It seems that you must be interested
in nothing more than the performance of function calling into your
library. (The application author already decided that he wanted
to write the application in Lisp: you're not benchmarking that.
You're not benchmarking your library against sockets, because
you have already done that in C. So that leaves the binding.)
Now, Common Lisp does not include any kind of library binding or
"foreign function calling" (nor is there anything standard about
the implementation of regular function calling, or the implementation
of anything, for that matter). Most Lisp implementations do provide a
way to call out to libraries like your "interconnect". So, you'll
be benchmarking the "foreign function call" feature in various Lisp
implementations, and also specifically comparing the overhead of
calling into the sockets library specifically. The main difference
will have to do with what kinds of "foreign" data needs to be managed
and/or converted using the two different APIs, so you might be able
to pretty well guess how that will turn out from first principles
and some trivial programming experiments. If your library uses
any multiprocessing features like signals or callbacks or threads,
then you'll have a much more complex problem on your hands.
······@news.dtpq.com (Christopher C. Stacy) writes:
> >>>>> On 30 Apr 2004 00:38:27 +0200, Petter Gustad ("Petter") writes:
>
> Petter> But I don't have an application. I have an interconnect that
> Petter> I wanted to know if it could provide a relevant performance
> Petter> increase for Lisp socket based applications. I should have
> Petter> emphasized this earlier.
>
> If I understand you correctly, you have a library that one would
> use instead of programming using the sockets library. If that's
Well, if the application use the socket library I expect that I could
replace it using LD_PRELOAD (under Linux that is).
> what you're saying, then what you would need to do is to develop
> the library binding for Lisp. It seems that you must be interested
This is another option. Rather than preload in intercept the standard
socket library one could explicitly use PF_SCI rather than PF_INET. A
third option would be to create Lisp bindings (using UFFI or similar)
to the low level library (called SISCI).
> in nothing more than the performance of function calling into your
> library. (The application author already decided that he wanted
> to write the application in Lisp: you're not benchmarking that.
> You're not benchmarking your library against sockets, because
> you have already done that in C. So that leaves the binding.)
This is correct. But I'm interested to learn if there are Lisp
applications out there which would benefit enough from a low latency
interconnect to invest the time to 1) test it using LD_PRELOAD, 2)
using PF_SCI, or even create foreign function bindings for the SISCI
low level interface.
> Now, Common Lisp does not include any kind of library binding or
> "foreign function calling" (nor is there anything standard about
I'm aware of that the Common Lisp standard does not specify an ffi,
socket interface or multiprocessing support. But most Common Lisp
implementations do.
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
--=-=-=
Content-Type: text/plain
On 8724 day of my life Ivan Boldyrev wrote:
> http://www.clicki.net/UFFI
<http://www.cliki.net/UFFI>, of course :)
--
Ivan Boldyrev
Is 'morning' a gerund?
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.5 (GNU/Linux)
iQEVAwUAQIqS+A4ALcwzZFpVAQIDBAf/WprE2hNfqLqxUZxMb/AhawOFRQDQL21Y
FsT8vtmEPdrzY2ep7qIepaQep75QK+d81C6WmEZcqplnAtrG786nDXx820sfwT4L
IPH843fLllGI0MTLKUQdNgO7ok5H7Rhkk/wLVQeB4NeU+O2ahF39gEO0XR78FgI+
2Nshg9X9WBAP2VvFn8nTHlUqDp42qIkOlgn3lomlIsdS2q8IT8i79UYOrDiqn1vl
9S39yEeq0jEZOBBjJCmvYcZR3lux763uv0A/Nm0nZ08t/VzapHxkSng00hhEifrq
hbT2WbQVVEkT0N1B+1AHkCvBosOuaz6ZcTE79KTQnAb43tO3C+QyFQ==
=KfYH
-----END PGP SIGNATURE-----
--=-=-=--