a good computer system would allow the application programmer to write their code in a synchronous and single threaded manner and all performance optimizations with respect to multiprocessing (and associated resource sharing) would be handled automatically.
I'm not sure providing that level of complex logic and scheduling is really a proper task for OS kernels. It's essentially what you get from green threads / coroutines which are provided by numerous runtimes and frameworks, but those have to be translated to the various different async IO facilities in order to be portable between OSes.
Disagree. Scheduling is exactly the type of thing the OS should be doing. It’s (a) extremely easy to get wrong and cause starvation and other problems (b) very complex and large in general and most importantly (c) the OS is the only component with birds-eye view across all processes and hardware (like Numa cores). Every major OS is already doing it, but not for async IO. So it’s absolutely reasonable to maintain this responsibility during the transition to async IO.
This goes back to my initial point. We should not need a team of PhDs and kernel hackers to do hello world. The old sync syscalls have largely uniformity across platforms, but the async ones don’t. This means, in practice, that most applications, runtimes and thus users, don’t get to enjoy the benefits.
Counterpoint: the OS should indeed do its job of scheduling, but applications sometimes know better (the ones specifically implemented by programmers who know better). The OS and application must cooperate to do big jobs like scheduling. See Linux's clunky NUMA lack-of-awareness and transparent huge pages blunder for examples of how sole OS control is lacking. This is not fundamentally a Linux implementation issue: the OS does not always know best. The other extreme, giving applications control, is obviously wrong too, like cooperative scheduling being infeasible for general purpose systems. The OS should have strong defaults but also empower applications (or rather, their programmers) to try their utmost if they want. The OS is not the end all, be all. It is the platform on top of which applications gain valuable power, and constraints. That is basically by definition.
> but applications sometimes know better (the ones specifically implemented by programmers who know better)
Sure, and I don’t mind it. But right now to get basic modern performance you need that knowledge. That’s my objection. I just want more projects to be able to benefit.
> See Linux's clunky NUMA lack-of-awareness and transparent huge pages blunder for examples of how sole OS control is lacking. This is not fundamentally a Linux implementation issue: the OS does not always know best.
I’m not familiar. But, I have a question. Do you think it’s possible to create a middle ground, where applications can specify a small (ideally simple) params in order to allow the OS to make meaningfully better scheduling decisions (as opposed to relinquishing responsibility entirely)?
The biggest roadblock is, as always, backwards compatibility. The second biggest is getting people to agree to standardization and documentation, solidifying the expected base of knowledge. All in all, I don't have much hope for mainstream OSes to get these improvements. But in theory it could be done. For certain workloads, applications could even just make minor adjustments like your suggestion of scheduling policy hints for great gains. This is especially about being more sympathethic about context switches, which can embody better core/NUMA socket locality, better awareness for interactivity or batch processing, better performance/efficiency core allocation, etc.. So in general I would say we could get quite far without much application programmer or user intervention.
This is wishful thinking. It would be nice, I agree, but. Even "guaranteed lower bound of optimization" for general purpose programs is off the table. Our tools for programming should be such that easy problems are easy to solve, and hard problems are possible to solve. There will always be hard problems. Single-threaded, synchronous code is not congruent with actual hardware constraints, and this has been the case for decades. And to the people advocating for async/await or green threads or similar, they are necessary, but even green threads don't compare to the ergonomics of single-threaded and synchronous code.
This is almost what we have in UNIX. The resource sharing and multithreading happens automatically if you start shelling out to programs to do work, or have a simple multi process architecture like NGINX, Postgres, and web app
