Re: Performance assistance / advice

Quick example here in a remote telemetry viewer for an audio plugin:




This is the top folder, including all supporting code:



and this is the specific version of Actors most used here. You can see good examples of its use in the Secure Channel folder - an implementation for a transparent, on demand, connection between Actor systems on separate machines. Remote Actors implemented in Actors. Uses fully encrypted links, secure key exchange, double-ratchet roving encryption.

https://github.com/dbmcclain/Lisp-Actors/tree/main/xTActors
Lisp-Actors/xTActors at main · dbmcclain/Lisp-Actors
github.com

> On Mar 12, 2025, at 19:04, Tahoma Toelkes <[email protected]> wrote:
> 
> I'd thoroughly appreciate references to good examples (or links to such) of how this kind of code looks at source level, if you'd be so kind.  Cheers!
> 
>> On Mar 12, 2025, at 6:09 PM, David McClain <[email protected]> wrote:
>> 
>> But these inconveniences become massive features in a multi-machine network. You can’t discern, except by the passage of time, whether a message is directed to a local Actor, or one on some remote machine in the network.
>> 
>> You can’t use UNWIND-PROTECT in a cross-platform execution. Instead you have to resort to timeouts. 
>> 
>> And so even on local Actor graphs you have to use timeouts. Only execute irreversible actions in edge Actors which avoids the risk of message retry from failed BECOME ops.
>> 
>> This inconvenience is uniform across a huge scaling of complex execution environments.  A simple, uniform, Actor topology no matter how it is distributed.
>> 
>>> On Mar 12, 2025, at 18:02, David McClain <[email protected]> wrote:
>>> 
>>> Actor code looks quite different from typical call/return Lisp. There is zero dynamic depth in the call stack for every Actor activation. No chance to have UNWIND-PROTECT around anything. No messages are sent until the Actor exits successfully. You would have to stack up all function calls until exit, and then figure out how to execute all of them at the same time.
>>> 
>>>> On Mar 12, 2025, at 17:58, David McClain <[email protected]> wrote:
>>>> 
>>>> … apart from the lack of concurrency and transactional behavior, you could use continuations to specify the target in a message. That is more general than call/return. But it has the overhead of forming a continuation, which is far more costly than simply delivering a message to a passive functional closure contained in an envelope.
>>>> 
>>>> Note that the envelope merely allows the behavior of an Actor to change without also changing its external identity. If we could dig inside of functional closures we could do the same thing and use function jumps (not calls) as in CPS style.
>>>> 
>>>> 
>>>> 
>>>>> On Mar 12, 2025, at 17:51, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>>>>> 
>>>>> Finally, in Call/Return or continuation based behavior, the results of a function execution are returned either to the caller, or else to the known continuation.
>>>>> 
>>>>> But Actors never reply directly to any sent messages. They don’t even know who the sender was. But they can be told to send a result to some specified Actor in the message. This is much more general than call/return or even continuation calling. It is a dynamic dispatch capability.
>>>>> 
>>>>>> On Mar 12, 2025, at 17:47, David McClain <[email protected]> wrote:
>>>>>> 
>>>>>> What seems to be missing is concurrency in the function calls, as well as transactional behavior.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Mar 12, 2025, at 17:44, Tahoma Toelkes (as tahoma_toelkes at yahoo dot com) <[email protected]> wrote:
>>>>>>> 
>>>>>>> Shouldn't every continuation call provide a context switch opportunity since they carry along a copy of relevant dynamic stack?  What am I missing?
>>>>>>> 
>>>>>>>> On Mar 12, 2025, at 5:39 PM, David McClain <[email protected]> wrote:
>>>>>>>> 
>>>>>>>> But this would obviate (parallel for sure) concurrency. It would tie up a machine thread indefinitely and offer no chance to switch threads in the middle of the execution.
>>>>>>>> 
>>>>>>>>> On Mar 12, 2025, at 17:33, Tahoma Toelkes <[email protected]> wrote:
>>>>>>>>> 
>>>>>>>>> Not necessarily, I believe.  One of the reasons that I referenced the Chez Scheme compiler earlier is that, if I recall correctly, it works (or at least, it did a few decades ago) in part by applying a source-to-source continuation-passing-style transformation to the full call graph, implying to me that a fully continuation-based semantics as a superset is possible, even if it might not be very comfortable to actually write in practice.  Actually, it's for this reason alone I suspect that the red-vs-blue call graph problem isn't unavoidable.
>>>>>>>>> 
>>>>>>>>> -- Tahoma
>>>>>>>>> 
>>>>>>>>>> On Mar 12, 2025, at 5:00 PM, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>>>>>>>>>> 
>>>>>>>>>> .. and so once you move the indirection up a level into a wrapper, we lose the equivalence between function calls and Actor message sends.
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Mar 12, 2025, at 16:59, David McClain <[email protected]> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Yes, I am aware of Steele’s comments about Actors.
>>>>>>>>>>> 
>>>>>>>>>>> However, Hewitt’s Actors require the ability to perform a BECOME - to become a different “function” on succeeding messages. I fail to see how a simple lambda expression could do this. But a closure could do so.
>>>>>>>>>>> 
>>>>>>>>>>> But lacking any visibility into functional closures in either Lisp or Scheme, we are left with encapsulating a closure (for private data + function) into a wrapper envelope for the indirection needed to perform a BECOME.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 12, 2025, at 16:52, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> On 12 Mar 2025, at 22:16, David McClain <[email protected]> wrote:
>>>>>>>>>>>>> I believe Scheme was an outgrowth in the late 80s for the Connection Machine??
>>>>>>>>>>>> 
>>>>>>>>>>>> Almost.  There was Planner, which I don't think ever really existed, and then Conniver which I think was an implementation of something with incoherent semantics.  Then Hewitt invented Actors, and ?Steele and Sussman? wanted to implement Actors in terms of lambda calculus on top of maclisp, and at some point had the blinding realisation that actors and functions (ie lambda expressiona) which never returned but just called another function (their continuation) were the same thing.  The resulting unified language was called 'Schemer'.  But ITS had six-character filenames.
>>>>>>>>>>>> 
>>>>>>>>>>>> The connection machine thing was *Lisp which I think was built on Genera (or perhaps its predecessors).  *Lisp would be a good thing to look at for ideas for vectorisation, probably (I only ever played with the simulator and I have no idea if it would run in a modern CL).
>>>>>>>>>>>> 
>>>>>>>>>>>> --tim
>>>>>>>>>>>> 
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Lisp Hug - the mailing list for LispWorks users
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Lisp Hug - the mailing list for LispWorks users
>>>>>>>>>> [email protected]
>>>>>>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Lisp Hug - the mailing list for LispWorks users
>>>>>>> [email protected]
>>>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Lisp Hug - the mailing list for LispWorks users
>>>>> [email protected]
>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>> 
>>> 
>> 
>