678
STOP DOING ASYNC
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Jan 2024
678 points (94.8% liked)
Programmer Humor
32481 readers
239 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
Why do you say this?
Not if your stacks per thread are small.
These data structures must exist either in userland or the kernel. Moving them to the kernel won't help anything. Also, many of these data structures scale at log(n). Splitting have the elements to userland and keeping the other half gives you two structures with log(n/2) so 2log(n/2) = log(n^2/4). Clearly that's worse.
If signals were the reason async worked better, then the correct solution is to enable threads that opt-out of signals. Anything that slows down threads that isn't present in an async design should be opt-out-able. The state-machines that async compiles to, do not appear inherently superior to multiple less stateful threads managed by a fast scheduler.
As described here you would still need to do a switch to kernel mode and back for the syscalls. The extra work required from assuming processes are hostile to each other should be easy to avoid among threads known to have a common process as they are obviously not hostile to each other and share memory space anyway. The synchronization required to handle multiple tasks should be the same regardless if they are being run on the same thread by a user land scheduler or if they are running on multiple threads with an os scheduler.
I'm not interested in saying that async is the best because it appears to work well currently. That's not the right way to decide the future of how to do things. That's just a statement of how things are. I agree, if your only goal is get the fastest thing now with no critical thought, then it does appear that async is faster. I am unconvinced it must fundamentally be the case.
Have you tried?
Page size is 4k it doesn't get smaller. The kernel can't give out memory in more fine-grained amounts, at least not without requiring a syscall on every access which would be prohibitively expensive.
That's what async does. It opts out of all the things, including having to do context switches when doing IO.
No, you don't: You can poll the data structure and the kernel can poll the data structure. No syscalls required. Kernel can do it on one core, the application on another, so in the extreme you don't even need to invoke the scheduler.
You can e.g. have a look at whether you can change the hardware to allow for arbitrarily small page sizes. The reaction of hardware designers will be first "are you crazy", then, upon explaining your issue, they'll tell you "well then just use async what's the problem".