Asynchronous IO: the next billion-dollar mistake?

7 points by YorickPeterse 10 months ago | 5 comments
  • nyrikki 10 months ago
    > More specifically, what if instead of spending 20 years developing various approaches to dealing with asynchronous IO (e.g. async/await), we had instead spent that time making OS threads more efficient, such that one wouldn't need asynchronous IO in the first place?

    1) Moore's law for single cores has been over for a while 2) We are necessarily in a distributed world 3) Amdahl's law still applies 4) Concurrent operations would still be needed.

    • YorickPeterse 10 months ago
      I'm not sure how any of this is relevant to what you're quoting? I'm specifically arguing that if creating and switching between threads was as efficient as say Goroutines, you wouldn't need epoll/kqueue/async await/etc, because you'd be able to just spawn more OS threads. In such a setup, your unit of concurrency is an OS thread, not a green thread coupled with some sort of IO scheduler.
      • nyrikki 10 months ago
        Green threads, await, and coroutines are all different animals, and all three have had significant investments.

        Even OS threads have had a lot of work, with glibc clone() even being used for goroutines in some systems.

        Green threads are cooperative multi threading and the traditional style doesn't support multiple cores well but are nice if core local context switching is what you hit.

        Coroutines are often about allowing programmers to use familiar loop constructs, while await often allows familiar blocking style programming.

        They all have tradeoffs.

        Modern COBOL compilers with Concurrent loops often uses polyhedral compilation, which tends to have better cache locality and can often be much faster than any of the above even using pthreads.

        The epoll(2) API was created because poll(2) performance problems. Traditional polling system calls such as poll(2) and select(2) simply didn't scale.

        Event queue dramatically improved performance when they were introduced, and really have nothing to do with userland treading.

        It is all horses for courses, and while cooperative multi threading has a use case, it wasn't wasted effort to move from polling to event queuing.

        • nyrikki 10 months ago
          Anyways, as you are using llvm, look into polly, auto parallelization is hard but auto localization is even harder for me personally.

          https://polly.llvm.org/

          And perhaps look into the deincrementing index registers of the IBM 705. The modern explanation is that Fortran indexes start at one, but historically they were limits, not starting address IMHO.

          I am not sure that flang found a way to free local memory when it went out of scope, But if you think about the implications it may help.

          GFORTRAN uses cray pointers, which also track a pointee

          Good luck with your language.

    • wmf 10 months ago
      Linux has already optimized threads extensively; AFAIK the overhead is mostly in the CPU at this point (fortunately Intel/AMD continue to reduce system call and context switch overhead).

      Using raw threads also has its own footguns but fortunately we have libraries like j.u.c and TBB to provide safer abstractions over threads. Unfortunately these libraries matured after async so most programmers aren't familiar with concepts like fork/join.

      • 10 months ago
        • 10 months ago