Re: GETF Speedup?

On the Security front… I have my Actors systems operating across the LAN in the lab here, and I offer an :EVAL Service on all of them. Actors from any node can send requests to another node to evaluate the code being sent.

But, of course, that is a huge security hole. 

Except..., my systems all use encrypted marshaling of Lisp objects across the network, with double-ratchet evolving keying. Initial contact is by way of X3DH key exchange. And all of the comms are refutable - as soon as a packet arrives and is authenticated, the authentication keying is broadcast in the clear.

No public keys are sent across the network. Only those people already vetted are permitted to play, and their public keys are held in encrypted databases, with keys always referenced by UUID.

But in a laboratory environment, which thrives on experimentation, it would be a sin to not have a remote EVAL service.

> On Oct 16, 2025, at 06:54, Bradford Miller (as bradford dot w dot miller at gmail dot com) <[email protected]> wrote:
> 
> David: Absolutely. Which is why I’m focused on resource management in PIM based architecture. I imagine you’d be able to take some advantage of advances in that area too, since it’s very much a Hewitt type of approach. (He taught one of my undergrad classes and the concepts stuck with me; in particular as an alternative basis for theoretical CS replacing Turing machines (outside of basic atemporal questions of, say, decidability or complexity) where real-time (by which I mean latency) matters as we can model physics as a type of communicating process). For me, it’s more a matter of modeling what brains (funcitonally) do; I'm very unhappy with current NN models which oversimplify neurons (I’m not trying to build a better neuron though, I’ll leave that to the biological CogSci 
 folks). 
> 
> Yuri: I’ll get back to you later when I have more time, since I doubt you’d be satisfied with one line answers. Let’s just say for now that the code=data paradigm of Lisp is not well supported by current machine architecture. (Partly) because, you know, security. So how do we (e.g.) prevent bad/dangerous memes from entering “brains"? Harvard architecture isn’t going to help with that, something *much* more holistic is required. 
> 
> Tim: LOL, yes perhaps I am a romantic. However, what I’m trying to (gently) point out is that there are different evaluation criteria of what makes a good architecture and/or development environment, and those can change depending on one’s more-or-less immediate goals. And even then, we may differ on the weights given to those criteria. That’s OK; I’m a pluralist. 
> 
>> On Oct 16, 2025, at 8:34 AM, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> I am keenly interested in these same questions. 
>> 
>> I can imagine that Cache vs number of cores becomes a losing battle, as cache coherency mechanisms slow down all processor on the CPU. 
>> 
>> But there are other possibilities for parallelism beyond shared memory. Each processor could have its own unshared address space and use a different mechanism for intentional sharing.
>> 
>> 
>> 
>>> On Oct 16, 2025, at 03:04, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>>> 
>>> 
>>> 
>>>> On 15 Oct 2025, at 20:27, Bradford Miller (as bradford dot w dot miller at gmail dot com) <[email protected]> wrote:
>>>> 
>>>> Yes, RISC v CISC. And they pushed caching. But that doesn’t help with GUPS (if anything, caching hurts). If all you are interested in is making your existing imperative codebase faster, then yes, you are probably better off investing in “sufficiently smart compilers”. If you are instead interested in alternative architecture and algorithms to avoid von Neumann bottlenecks, compilers won’t help as much as more control over the hardware.
>>> 
>>> I have a lot of questions about this (I am kinda with Bradshaw on this one for once) as I have little reason to doubt that modern machines are substantially better than what we had, say, 40 years ago in every respect. So the questions are:
>>> 
>>> 1. What is GUPS?
>>> 2. In which ways caching can hurt (especially given the current speed gap between CPU and RAM in modern machines)?
>>> 3. Why does Common Lisp code benefit less from smart compilers than imperative languages (I assume C is meant here as an imperative language)?
>>> 4. What are the von Neumann bottlenecks that need to be avoided and why alternative architectures are need for that?
>>> 5. In which way control over hardware is superior to control over compilers? (I am not sure the phrasing is connect as it feels similar to saying “in what ways water melons are superior to vacuum cleaners” but that is what the quoted text kinda says, it seems.)
>>> 
>>> I feel like we are lacking a huge amount of backstory behind the terse email so I want to unpack it a little.
> 
> 
> _______________________________________________
> 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