Re: GETF Speedup?

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 fo
 lks). 

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