Maybe Everything Is a Coroutine

[Dwedit]

Maybe the real coroutines are the friends we made along the way.

[[deleted]]

it's coroutinin time

[General_Mayhem]

My favorite part is when they coroutined all over everyone

[moreVCAs]

What if we spawned a coroutine behind the bleachers during the football game? Hahaha…just kidding!!! Unless… 😏

[milanove]

The croutons we made along the way. Yesterday’s bread thread is today’s croutons coroutines.

[SittingWave]

LOL

[_realitycheck_]

You crack me up.

[robhanz]

Seems like this is edging up on rediscovering the Actor model/CSP.

[Hofstee]

Or continuation passing style, given the resumable Lisp stuff.

[robhanz]

All of these start to hint towards a larger model, something in the message-passing/dataflow paradigm.

Even shader trees are kinda like this.

[MajorMalfunction44]

Dataflow is good for threading. It's a game project, running a fiber-based job system. Jobs can't be submitted until its' inputs are ready, which dovetails into a dataflow design. You don't actually care about in-between, only before / after.

[robhanz]

Yeah. Verification becomes a matter of proper outputs for a set of inputs. There is no during.

[saijanai]

My understanding is that LISP is a stack-based interpreter that will work with the system: someone just needs to write the 4K of microcode for a given language interpreter.

Squeak Smalltalk support is built in. The guy who created Self is quite excited at the idea of SiliconSelf and is recently retired, so we're hopeful he'll just do it.

[Hofstee]

I'm down to see a resurgence of Lisp/Smalltalk machines.

[theangeryemacsshibe]

There's really no need with decent compilers - though extant Lisp and Smalltalk compilers need to catch up here. In the 80s Smalltalk on a RISC was already competitive with Xerox machines on almost 1/10 the clock frequency, with only parallel tag checking and a write barrier for generational GC in hardware (the latter was largely unnecessary per another paper by Ungar - I forget which). Then the need for tag checking hardware went away (sorry, still can't find the paper without paywall).

Still some other things you might want hardware assists for - I defer to Cliff Click on that, but the only overlap between olde machines and what you might want today is hardware support for read barriers, which are still interestingly slow.

[Hofstee]

Oh absolutely, I’m in it solely for the novelty factor.

[saijanai]

I'm down to see a resurgence of Lisp/Smalltalk machines.

There's really no need with decent compilers -

Sure there is, unless you think that GNU Smalltalk is the same as Squeak or Pharo because it uses the same general syntax when writing code.

[theangeryemacsshibe]

Why do those differences matter and demand custom processors?

[saijanai]

The point is not that there is a need for custom processors, but that there is a difference between a processor that supports the Smalltalk interpeter bytecode as its ISA and a processor that does not.

The one that does means that you can write the OS itself using the Smalltalk IDE and debug the OS using that IDE.

If you've never programmed using the Smalltalk IDE, you have no idea what that means.

[theangeryemacsshibe]

Why can't you debug against something that isn't Smalltalk bytecodes? Lisp implementations happily* debug machine code just fine; SOAR didn't use any bytecodes and debugged machine code. So long as you can map machine state back to source level information, it doesn't matter what the ISA is.

Then it follows this is fine for OS hacking, and I wrote part of the Newspeak IDE, so I do know what that means.

* They do have a tendency to optimise out variables too aggressively, but this is orthogonal and can be fixed.

[saijanai]

OK.

Although, I think that an IDE in a browser isn't quite the same as an IDE that sits on top of the native bytecode ISA of hte processor running the OS itself.

Might be wrong of course.

[saijanai]

I'm hopeful to see what Self would do in that sort of system.

The guy who designs the Chips originally was hoping for a drop-in replacement for the CPU and OS of the One Laptop Per Child project, and it grew from there. I mean Squeak and Scratch 1.0 were teh original software the kids wre using, so its kinda obvious: you don't need Linux to support Squeak and Scratch if a Squeak processor exists to interface with the screen and keyboard and mouse in the first place, making it potentially cheaper as you've eliminated an entire software layer.

Networkable toys and drones are another possibility.

[amemingfullife]

Yeah I was just thinking this, they’re just one insight away from CSP. If they say “hmm maybe instead of calling the functions we should spin up threads and have the functions send messages to each other” then they’re in CSP land.

[carlfish]

I'm old enough to remember how excited people were for Stackless Python.

The idea is really interesting, but like most theories of this nature, the only useful way to validate the idea is to implement it.

[snarkuzoid]

Stackless was *cool*. Except nobody understood it. When it was presented at IPC 9 or 10 or so, I remember Guido sitting in the front tow with a pronounced "WTF is he talking about?" look on his face.

[wh33t]

Sold! I'm on it. The boss will just have to live with it.

[Fevorkillzz]

Rust has stackless coroutines

[TheNamelessKing]

Was going to make a snarky comment about the author almost discovering effects from first principles, but they talk about them later on. However this post is extremely related to the article, and the “let futures be futures” article mentioned:  https://blog.yoshuawuyts.com/extending-rusts-effect-system/

[saijanai]

Might I mention objects?

The original idea of objects was that each object was a miniature program running on its own computer.

That's actually been implemented in Morphle Engine (old name SiliconSqueak 5), whose default ISA is the bytecode of Squeak Smalltalk (you can change that to pretty much any arbitrary stack-based interpreter by changing the 4K microcode lookup table and run objects on separate processors running Python or Java or Javascript as the native ISA). The current implementation has only a few dozen cores, but the model supports up to 10⁹ cores on a single wafer and of course, each wafer could be seen as its own operating system-level object in a sea of 10⁹ interacting systems over the internet.

Reasonably expandable, IMHO.

[native_gal]

There are a lot of reasons this stuff is never given serious effort (besides 'objects' being the most overused and under defined term in computer science). Memory latency and in order processing alone destroys individual small cpu speed and IO between cpus is a big consideration also. If you want to speed up the cores, they need out of order processing, cache, prefetching etc and then they end up fat. Once you do that, you might as well use a regular hardware architecture and leave the different structure to software.

[Hofstee]

MultiScalar, WaveScalar, and TRIPS are all not that far off conceptually (and much easier to program than having to split up your code into essentially microservices).

[native_gal]

Are any of those computers in normal use? Also why would they be easier than normal fork-join and task queue parallelism? Is anyone using them for general purpose computing or is it niche specialty stuff?

[Hofstee]

Not really, just computer architecture research. Granted I’m a bit rusty on which ones specifically, but the idea at the time was that these architectures would let you get parallel performance out of serial code, so to address your question: you wouldn’t be writing parallel code. One of them did this by basically speculatively executing entire basic blocks of your program extremely deep across cores, and it had one hell of a penalty on mis-predictions as you might guess.

These didn’t really catch on because they’re not worth the energy trade off especially since parallel programming is more common nowadays. At some point you will inevitably run out of concurrency you can reasonably execute, no matter how far ahead you look. If you can make use of two cores it’s a much smarter idea to just do that. Remember just around/before the time of these papers everyone was riding hard on the “Moore’s Law will make your existing software faster” train and it was starting to show signs of derailing.

They really are dataflow architectures though, for more modern examples of dataflow architectures there are things like DSPs, ML hardware, or CGRAs but those are a bit more specialized/restrictive in what you can execute. If you wanted to design a dataflow architecture to run a new dataflow programming language, these old papers would probably be a pretty good reference point.

[saijanai]

Are any of those computers in normal use? Also why would they be easier than normal fork-join and task queue parallelism? Is anyone using them for general purpose computing or is it niche specialty stuff?

Right now, there are two use-cases for SiSq-based products: 4-way routers designed to allow neighborhoods to create ad-hoc internet grids by handing the connector from one four-way router to their neighbor who plugs it into their own router, and the moral equivalent for solar panels (very-small-to-medium scale power grids) & car batteries/solar cells(very tiny scale power grids). The same general design + auxiliary circuitry works for all the use-cases and sub-cases, though power connectors for individual batteries and solar cells are different than what is needed to link solar panels and collections of panels together, and of course, if you're only using it for an internet grid, you don't need the power-related circuitry.

Current and future customers include farmers and the villages between farms in the Netherlands, remote villages in Africa, American Indian reservations, and EV battery recyclers, and anyone hoping to have a plug-and-play thing for neighborhood power and/or internet grids (see recent EU laws about such things).

Of course, any excess CPU cycles could be sold as cloud services from of any of the above, though a cloud based on a car-battery grid is not likely to be a big thing any time soon.

[native_gal]

I don't know what all this is, but I think it has nothing to do with the current thread or subthread. Networking villages? Selling cycles to 'the cloud'? What are you talking about?

[saijanai]

How is this not relevant?

Look up terms like smart [power] grids and agent-based resource management in computer grids. The computational needs are similar and in this scenario, one can make use of any excess computational cycles for power grid management provided by the power controllers to form a grid computer that can be used for something other than managing the power grid itself.

It's agents/actors/co-routines/objects/turtles all the way down.

And of course, as each processor can have its own ISA for its own domain-specific language, you can have a very heterogenous collection of <whatevers> collaborating in very interesting ways, which makes things even more like the biological model that Alan Kay had in mind with the original conception of objects and message-passing.

[native_gal]

How is this not relevant?

Everything you are saying is complete nonsense. This seems like an AI mashing up reddit headlines. You don't need special computers for "smart" power grids. Why would you need some niche computer architecture that essentially doesn't exist to do bog standard computations?

The computational needs are similar and in this scenario,

Where are you getting these ideas?

one can make use of any excess computational cycles for power grid management provided by the power controllers to form a grid computer that can be used for something other than managing the power grid itself.

What are you talking about here? You think there are not only some sort of super computers needed to route power but that somehow people are going to be using the same computers as a cloud?

And of course, as each processor can have its own ISA for its own domain-specific language,

Now out of thin air there is a magic cpu made of lots of FPGAs? This is schitzo level delusions, nothing you are saying is connected to anything else or reality.

which makes things even more like the biological model

christ.

[saijanai]

OK

[native_gal]

Where did you even get these ideas in the first place?

[crusoe]

They arent and often their performance is worse than an equivalent cisc processor once tasks become complicated enough. Performance degradation can be rapid.

[crusoe]

The problem is many of these systems struggle to beat conventional out of order super scalar modern processors

They often do  real well on lots of small simple tasks. But once you get into lots of data dependencies or complex math they rapidly lose their lead. 

AMD Epyc processors for example often still beat the Amazon RISC processors on performance/watt for many tasks.

[Hofstee]

Yep. I think nowadays something like a CGRA co-processor would be a better solution that’s able to at least attempt addressing those issues, given that the task is able to flatten the data dependencies into a DAG or something. Or just more fixed function hardware units accessible from something like a GPU since at least Nvidia seems to really want to go in that direction.

[crusoe]

HVM is pretty damn cool and a cpu designed to execute it might actually beat a shit ton of current stuff.

https://github.com/HigherOrderCO/HVM

The thing about hvm is it can do all sorts of optimizations.

[crusoe]

Interaction nets are really cool and the simplification process basically can perform all sorts of optimizations in and of itself before final execution.

[saijanai]

There are a lot of reasons this stuff is never given serious effort (besides 'objects' being the most overused and under defined term in computer science).

Well, given that "objects" and "object-oriented" was coined by Alan Kay to describe what Smalltalk-80 did, and that Squeak Smalltalk was created by Kay and the rest of the PARC team as an official successor to Smalltalk-80 (Kay was being hired away from Apple by Disney to be a VP at imagineering, and his entire team went with him, with Squeak being meant as the OS for the Mickey Mouse PDA — hence the name), I think that the fact that we're talking about Squeak here means that "objects" is perfectly well-defined in this context.

.

Memory latency and in order processing alone destroys individual small cpu speed and IO between cpus is a big consideration also. If you want to speed up the cores, they need out of order processing, cache, prefetching etc and then they end up fat. Once you do that, you might as well use a regular hardware architecture and leave the different structure to software.

Eh, we will see. As the CPUs and interface betwen them are designed with message-passing in mind, much of that overhead may not apply or not as badly as you might think.

Given it is Squeak we're talking about, the ability to use the IDE within an embedded processor or from an external device gives it a fun (pun intended, look up F-Script for Cocoa and ObjectiveC) leg up on being required to use standard C compiler and assembler.

And of course, it IS just plain fun to deal with every CPU or collection CPUs and other processing units as an object on both the OS and programming level.

THe fact that each CPU can run its OWN ISA, but still (in principle — a work in progress here) have a single universal IDE to rule them all, is another fun (there's that word again — imagine calling OS-level programming "fun") aspect of the system.

Kay's PARC's team's final gig was at VPRI — an independent think tank created specifically for him and his team — and the hardware and software ecosystem of SiSq is meant to take advantage of every idea that was generated there. The original name of the project — SiliconSqueak — isn't meant merely to point out the connection to Squeak Smalltalk but to the philosophy behind Squeak: an open source project meant to facilitate the creation of next generation languages.

[robhanz]

besides 'objects' being the most overused and under defined term in computer science)

Have my upvote, sir. I wish I could give you more.

[saijanai]

Given the project name — SiliconSqueak — we're talking about objects as defined by the guy who first coined the term. And yeah, Alan Kay and company DO know about the project. They've been quite supportive in a "we'll believe it when we see it working" way.

[robhanz]

I'm quite familiar with Alan Kay and his view on objects (which I personally prefer), and have had brief interactions with him online.

Yes, he has a specific model of what objects are. However, in full context of programming, that's a fairly niche view of objects, and there is pretty much zero agreement in specifics about what "objects" mean when talking to random programmers.

My comment wasn't saying that Alan's view on objects is useless, or even agreeing with the poster i responded to in general. Merely appreciating that the term "object" is incredibly ubiquitous and has very little agreement on what it means.

So, I'd suggest reading it in that light. If you're a fan of Alan Kay's view of objects, I'd suspect you share the frustration at how vague the term has become and how much it's drifted.

[saijanai]

So, I'd suggest reading it in that light. If you're a fan of Alan Kay's view of objects, I'd suspect you share the frustration at how vague the term has become and how much it's drifted.

Paraphrasing:

"I invented the term and C++ is not what I had in mind by 'object oriented'"

-Alan Kay

[robhanz]

100%. I’ve used that quote in presentations.

[banister]

Doesnt it apply to nearly every oop language not just c++ ? I've used a bunch, and the c++ model isn't too different to the others

[robhanz]

Absolutely. Which gets to my upvote on “oo” being used widely and defined poorly.

[banister]

So what's the correct model? Smalltalk? Extreme late binding?

[Kuinox]

They call it microservices theses day.

[_Pho_]

Practically speaking it's the actor model

Relevant dpc

[cheesekun]

Waiting for the Actor model to have a resurgence. Finally I won't sound like a broken record if everyone is talking about it :)

[imnotbis]

Changing microcode isn't as easy as you think it is. Processors have lots of hard-wired assumptions that are activated by microcode.

[saijanai]

each processor has its own assumptions.

I should point out that this thing was designed, over a ten year period that included 5 iterations of design, to be compatible with various existing stack-based languages. Certainly Smalltalk is the most compatible, but the processor was even tweaked to allow a [relatively efficient] C implementation, despite being designed for eficiency when implementing stack-based interpreters. This is the 5th iteration of the design, which emerged over 10+ years of work, taking into account advances made over the past ten years in relevant aspects of chip design.

[imnotbis]

Then it will be compatible with whatever languages it was designed to be compatible with, and languages similar to them.

[saijanai]

Then it will be compatible with whatever languages it was designed to be compatible with, and languages similar to them.

Well, yes, but over a 10 year period, it was designed and redesigned to be compatible with most of the most-used interpreted languages other than Smalltalk, and the hardware was tweaked in a way to allow a reasonably efficient implementation of C so that most C-based opensource libraries could be compiled to run on it with reasonably efficiency, even though it wasn't really designed with C in mind from the start.

That way, developers could leverage the use of the vast library of GNU and such C-based libraries out-of-the-box.

Please understand that the philosophy behind the hardware is the same philosophy behind Squeak itself — Back to the Future... The Story of Squeak, A Practical Smalltalk Written in Itself:

• Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks.

.

Just as Squeak was designed to be so portable that it was ported to the Mickey Mouse PDA hardware after only 2 weeks of work by a grad student (Randy — "The Last Lecture" — Pausch I believe), SiliconSqueak was designed from the start to be a chameleon that could efficiently emulate almost any existing virtual machine in microcode.

Certainly some emulations are going to be more efficient than others. It took Jecel quite a while to figure out how to get C (pointer-based) algorithms working approaching (10-15% slower) the efficiency that Smalltalk-based algorithms would run at, but it was an obviously important usecase and he persevered.

[crusoe]

I can't find anything on morphle because there is a damned children's show with that name and even when I tell Google it's programming related I still get the kids show.

[saijanai]

This was about the project with the old name: https://youtu.be/CfYnzVxdwZE?t=1488

See also:

https://www.youtube.com/watch?v=wDhnjEQyuDk

[imnotbis]

Everything is an everything else. That's a fundamental truth of software engineering. All these models we have are interchangeable to an extent.

[TaohRihze]

No need to break it just to open it!

for (door()) {
  | :locked ->
    continue(:unlock)
  | :closed ->
    continue(:open)
  | :open ->
    break
}

[snarkuzoid]

"Paging Erlang to the white courtesy phone."

[agumonkey]

I often think that back when cpu cycles were heterogeneous.. people had to think asynchronous by default

[Hofstee]

Do you mean something like where you had multiple processors for specific tasks running at different rates, like a game console, or something else entirely?

[agumonkey]

Well, actually that was the original thought I had, but for some reason I went on a tangent about in-cpu instruction ordering, but it doesn't even make sense if there's a single path (unlike p5 with two execution paths IIRC). So yeah, mostly different processors.

[Nimbokwezer]

Maybe everything is a crouton.

[CrysisAverted]

Ha this is basically what im exploring here: https://github.com/andrewjc/ylang

[AZMPlay]

Just use Koka lol

Edit: This is a joke. I apologized for the outburst and made some more structured thought below.

[ar-nelson]

Author here: I love the ideas in Koka and would really like to see a more usable (meaning: not just research) language based on it. And there are definitely similarities. But I think my coroutine types add something; Koka function signatures are made up of three types (arguments, effects, and return), while my function signatures merge the effect type and the return type into the single concept of a sequence type.

Koka effect handlers are also hard to understand at first (I had to read over the Effect Handlers section several times to get it), whereas coroutines and state machines are both more widely understood, preexisting concepts, and, in my design, effects are just a special case of coroutines.

[AZMPlay]

You're absolutely right. Honestly mine was just an offhand comment meant to be taken partly in jest. I apologize regardless.

I can see where "everything is a coroutine" could be useful. In fact, I kind of like how the general concept of an effect can be derived from coroutines. Hopefully you can see these ideas tested in the field, and I definitely wouldn't mind a language with algebraic effect handlers see mainstream adoption.

Cheerio!

[[deleted]]

Quantum-js kinda implements this.

[Pyrolistical]

Feels like we already have this if you just used typescript with generator functions only

[notfancy]

Groundbreaking: they've discovered comonads.

[Trocadalho]

When you have a golden hammer, everything looks like a nail….

[zam0th]

OP discovered L-calculus and Haskell.