Thinking about CPUs from first principles, and, towards asynchronous programming

[Paul Tarvydas]

Maybe of interest to this group:
https://programmingsimplicity.substack.com/p/de-spaghettifying-control-flow?r=1egdky
https://programmingsimplicity.substack.com/p/towards-asynchronous-programming?r=1egdky
https://programmingsimplicity.substack.com/p/diversifying-programming-workflow?r=1egdky
https://programmingsimplicity.substack.com/p/growing-system-size?r=1egdky

pt

[Raoul Duke]

iiuc clockless chips have been hard to achieve in history, had a friend at Centaur/VIA, they tried and gave up back in the day. metaphorically like ice vs wankel engines? theory vs. practice. 

[Raoul Duke]

apologies for being out of the loop, how do you rate Actor-esque approaches?

[David Barbour]

The most direct way to extend procedural code with concurrent interaction is to introduce coroutines. 

Coroutines are non-preemptive. They voluntarily yield and conditionally continue, expressing concurrency without parallelism. Sufficient for producer-consumer patterns, for example. 

Though, we can run coroutines in parallel if doing so is consistent with running the same steps sequentially. But this is impossible to prove at the machine code level. Only in context of higher level encodings, such as dataflow models, can we conveniently prove isolation.

Anyhow, I feel discussion of this subject, the transition from procedural to dataflow, calls for a mention of coroutines.

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pilud/BD31C537-EBD8-48AD-8897-99CDD5EDC7BB%40gmail.com.

[Paul Tarvydas]

I didn't think that I was suggesting clockless CPU chips. Clock-based synchrony is needed (internally), but is not needed /everywhere/. Over-use of this single technique is the problem. I don't think of internet / robotics / IoT / bigger desktop machines / games / etc. as things that need to be clocked. Clocking is one form of synchronization. Clocking, as I understand it, is an over-generalization of synchronization that takes design decisions out of designers' hands.

pt

[Paul Tarvydas]

Actors ... super-encapsulation, aka "isolation", is good. Data, and only data, can leak into and outof ports. Preventing control flow leakage is vital (think, also, UNIX pipelines). Lack of hierarchy: bad. Yet, as soon as you achieve isolation, you can implement hierarchy with ease. IMM, you need 2 kinds of components: Leaf components, Container components (nano-routers, hierarchical, recursively-defined). Actors == Leaf components. Actors with more-restricted roles (for recursive, inter-component routing of mevents) == Containers. PBP (aka 0D) is basically Actors split into these 2 roles. This can be done /right now/ in programs and software and games by simply creating sync units of software with mevent queues between them (mevent == message treated as an event that triggers a reaction) (which reminds me, I shoulda included a reference to https://github.com/guitarvydas/raw-pbp in the "Towards ..." article (doing so now)) (in fact Kagi.com <http://kagi.com/> is using these concepts in production software). I don't believe that I've ever seen an implementation of Actors that gets the isolation part right (most current PLs make you use functions for everything, which encourages control flow leakage, you have to implement Send() and Handle() routines by hand instead of having these built into the language (kinda like using GOTO in restricted ways in the 1960s)).

pt

> On Aug 11, 2025, at 1:27 AM, Raoul Duke <rao...@gmail.com> wrote:
>
> apologies for being out of the loop, how do you rate Actor-esque approaches?
>

> --
> You received this message because you are subscribed to the Google Groups "PiLuD" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/pilud/CAJ7XQb7c3CNzgfgC1szVd6y6JkceEEssX9cD5EoBPpyJrDdeMg%40mail.gmail.com.

[David Barbour]

Feels like fighting the actors model to make them route messages within a container. Their default mode is freely receiving messages from anyone and sending messages to anyone the actor hears about.

There are process models where inputs and outputs are specified on local "ports" instead. Makes it trivial and robust to wire processes together into larger, hierarchical processes.

To view this discussion visit https://groups.google.com/d/msgid/pilud/D55040F5-5502-4EC6-A609-6B13BA757670%40gmail.com.

[Paul Tarvydas]

(Sorry, I missed this because gmail decided that it was spam. I am trying to remedy the situation... sigh)

I agree with the most of the statements about coroutines,,, but, I quibble with the word "concurrency". https://programmingsimplicity.substack.com/p/the-illusion-of-concurrency?r=1egdky

pt

[Paul Tarvydas]

Interesting comment, thanks. "Wiring processes together...hierarchical..." sounds like what I advocate. I would be interested in any pointers to these models.

thanks
pt

> To view this discussion visit https://groups.google.com/d/msgid/pilud/CAAOQMSvUe12vedjpvwmPnHXsGG42jPDHumQ-Qbw2Ekw5TAmqtA%40mail.gmail.com.

[David Barbour]

In my understanding, concurrency is about *interaction of components*. That is, if we express a program as two or more components that interact to progress or achieve some goal, it meets the definition of concurrency. In contrast, parallelism is about *execution of a computation*. Insofar as a computation can simultaneously utilize multiple processors, that's parallelism.

Parallelism doesn't imply concurrency. For example, we could parallelize evaluation of a large spreadsheet, or of multiplying large matrices, without modeling any interactions. Nor does concurrency imply parallelism. Coroutines are concurrent but difficult to parallelize, but even actors model - trivial to parallelize - doesn't guarantee an application will do more than one thing at a time.

[Paul Tarvydas]

The Illusion of Concurrency II https://open.substack.com/pub/programmingsimplicity/p/the-illusion-of-concurrency-ii?r=1egdky&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

pt

[David Barbour]

Multitasking, time sharing, parallelism, etc. don't imply concurrency. Not unless there is also some relevant interaction between those tasks.

Concurrency is a semantic property. Parallelism is an implementation property.

We know two processes are concurrent only insofar as they observably interact. This interaction demonstrates that the processes have overlapping lifespan, i.e. they exist concurrently and progress together, and it is meaningful that they do so.

If there is no interaction, then the processes aren't logically concurrent even if you run them in parallel or with multitasking. You could implement them sequentially and, modulo performance, have the same outcome. 

Concurrency is a useful concept and semantic property, especially with regards to composing or decomposing software and escaping the restrictions of call-return. 

But you're a bit too focused on the implementation layer, on parallelism vs time sharing instead of concurrent composition vs sequential composition. 

--
You received this message because you are subscribed to the Google Groups "PiLuD" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pilud/CC8EA94B-FF74-4D22-8B9A-3B12183AF1D3%40gmail.com.

[Raoul Duke]

(huh, my connotations are €0.02

concurrent means doing more than one thing at a time during an arbitrary but suitable defined interval of time. could be anything from SIMD to multi core to hyper threading to preemptive scheduling to cooperative scheduling...

parallel is a subset of concurrent and means the code between "par begin" and "par end" can (resources permitting) truly run multiple calculations at the same time.)

[Paul Tarvydas]

> But you're a bit too focused on the implementation layer, on parallelism vs time sharing instead of concurrent composition vs sequential composition.

Actually, I'm /very/ focused on the implementation layer. There seem to be two extremes of thought here: (1) notation worship, (2) implementation worship. How would MOAD (Engelbart) be cubby-holed? How would famous game designer Muratori be cubby-holed (https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.youtube.com/watch%3Fv%3Dwo84LFzx5nI&ved=2ahUKEwj-1PSlooWPAxUzwskDHWmjHdAQkPEHegQIFRAG&usg=AOvVaw1f8B4u79GS-NMwq_N-Byhn)?

pt

> To view this discussion visit https://groups.google.com/d/msgid/pilud/CAAOQMSuYX33K0NcJM0HUkJg%2BYcVD%2BSosH_GpUXYJB4R%2BHg95Sw%40mail.gmail.com.

[Paul Tarvydas]

> … concurrent means doing more than one thing at a time during an arbitrary but suitable defined interval of time ...

I like this definition.

> … the code between "par begin" and "par end” ...

I don't like this definition. It's too implementation-specific. Implementation of a 400-year old technology called Gutenberg type-setting. Written notation was different before the Gutenberg press became popular (https://programmingsimplicity.substack.com/p/how-gutenberg-harmed-math?r=1egdky). In 2025, we can do better.

pt

> --
> You received this message because you are subscribed to the Google Groups "PiLuD" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pilud+un...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/pilud/CAJ7XQb6NeBvrh%2BGZnjsu%3DKP1LLUP3hwJh_nxXV7C8v1V2UJ7Xg%40mail.gmail.com.

[Raoul Duke]

the "par begin"/"end" was metaphorical :-)

[David Barbour]

On Tue, Aug 12, 2025, 7:33 AM Paul Tarvydas <paulta...@gmail.com> wrote:

> But you're a bit too focused on the implementation layer, on parallelism vs time sharing instead of concurrent composition vs sequential composition.

Actually, I'm /very/ focused on the implementation layer. There seem to be two extremes of thought here: (1) notation worship, (2) implementation worship.

I'd suggest avoiding those extremes. No need to worship implementation (parallelism) to the extent of even denying notation a jargon.

It is very useful to have both words, to be able to discuss the properties of notations such as Kahn process networks or Lafont interaction nets and contrast them with coroutines or the non-concurrent parallelism you get out of SIMD or Haskell's sparks or CPU pipelining.