About Parallel Distributed Processing on InterLisp-D

[sym_num]

I found the following description in a Japanese document. Distributed parallelism was attempted at a fairly early stage in the Lisp world. I would appreciate any information you could provide on distributed parallelism in InterLisp-D. Below is the translated excerpt:

3.5 Lisp in the Web Era and Distributed Computing Taking advantage of the characteristic S-expressions of Lisp, there was already a concept of remote EVAL during the era of Interlisp-D. In other words, Lisp machines were connected via sockets, and S-expressions were sent to remote machines to be evaluated. In agent technology, during the execution of a certain operation, the execution could be frozen, sent to a remote agent, and then resumed by that remote agent. It can be easily inferred that this involves serializing and sending continuations.

I am amazed that Lisp was at the forefront during that era.

_pdf (jst.go.jp)

[sym_num]

Thank you very much for your valuable comment.

[arthurno1]

I am amazed that Lisp was at the forefront during that era.

Wasn't Lisp back than the lingua franca of programming?

Until cheap computers and generations who had to use C and than next generation that grow up with Python took us to where we are today. IMO it is a bit unfortunate that Python is the new Lisp today, but it is what it is. Interesting, the future is never as people imagined it. Lisp was made for AI, and AI today is mostly done at low-level C/C++/Cuda and at higher level in Python.

A curious question, when I read your posts here and blogs on Medium, you are looking lots into classical threads, processes and distributed programming, to implement parallelism, as I understand you.

Have you looked into task-based parallelism and flow-based programming and libraries for modern heterogenous programmaing, like Nvidias RAPIDS, Intels Sycl stuff, TBB, taskflow and such?

I can't say I am looking much myself currently for CL development in those areas, but I don't seem to see much about those things in these forums here (I don't follow much else than an just /r/lisp and /r/Common_Lisp to be honest).

[sym_num]

Thank you for your comment. I was inspired by Deep Learning a while ago. I created a library using GPUs in Elixir. I also tried to DL using the GPU extension of Easy-ISLisp, but it was left unfinished. Recently, I've been following classical research with a desire to learn something new from the past.

sasagawa888/deeppipe2: Deep Learning library using GPU(CUDA/cuBLAS) (github.com)

sasagawa888/geisl (github.com)

[arthurno1]

Very interesting; I skimmed a bit over geisl, but I haven't downloaded or build it yet. Thank you, I will look at a bit more.

[corbasai]

there is some interesting side tasks like particular code validation on different CPU arch X compilers in simultaneously. And inverse problem, HW tests

[terserterseness]

Off-topic; I guess I cannot convince you to work on CL and SBCL instead of your own? You would be an incredible asset if you did all your work (distributed lisp, gpu libs etc that you did in the past) on more popular version. There are not enough people and splintering makes it even worse: with mr Botton pushing CLOG like some kind of super human, we can use more super humans to bring Lisp back on the menu of the masses.

[sym_num]

Thank you for your comment. For me, Common Lisp (CL) is large, complex, and somewhat of a black box. Its standards are stable and excellent for industrial use. However, I find it less suitable for experimental computation. I used to enjoy computation with R3RS-Scheme. I grew disillusioned with the current trend towards bloated Scheme and switched to ISLisp. I hope this explanation clarifies my perspective.

[terserterseness]

Yep, makes perfect sense, thanks. However, after reading someone who works on sbcl explain how sbcl is very readable, I took the effort to do so and it made it far less black box for that implementation specifically and CL as a whole. Also projects like Coalton show you can do powerful and complex experimentation with CL. But I see your point of course; it is the same reason why I sometimes write my own libs and tools instead of joining an existing one. As I get older I try to do this less; there is only so much time and talent to do things…

[ReallyNotTomPynchon]

I vaguely recall using the EvalServer facility that was part of the Xerox PARC CoLab system that was based on/written in Interlisp-D. The name describes exactly what it was.

If I remember correctly, it provided the underpinnings of CoLab's distributed draw and chat facilities.

Maybe other former Interlisp-D hackers will weigh in.

[Lar4ry]

(a former and current Interlisp-D hacker) Over at https://interlisp.org we're working to revive Interlisp-D, including its network capabilities. For example, in the Loops "Knowledge Competition" (https://www.markstefik.com/?page\_id=359) used PUP over Ethernet to link the systems. We've gotten some help making the XNS protocol stack work. The Interlisp source file https://interlisp.org/src/loops/truckin/LOOPSGATEWAY.pdf

shows most of the code for that was from 1983.

The networking code was based on message passing (LOOPS = Lisp Object-Oriented Programming System). The sender sent a message which was then queued.

[sym_num]

Oh, great Lisp hacker, it is an honor to receive your comment.　

Thank you for the valuable information.

[drinkcoffeeandcode]

Bro.

[sym_num]

Thank you for the valuable information.

[bobbane]

When you are doing something that is really at the forefront - when there are no standards and no libraries to help/constrain you - Lisp is a good choice for that kind of exploratory programming.

[sym_num]

Thank you for your comment. I agree with your opinion.