Hacker News Reader

Comment by gamegoblin | Hacker News Reader

I'm currently hacking on a toy webserver in Haskell, and from my point of view, I spin off a thread for each request, but Haskell's runtime environment manages all of these as a group of green threads doing aynch IO behind the scenes. Best of both worlds as far as I'm concerned.

I just change

    serve request

    forkIO (serve request)

And magically I have multithreaded aynch IO that seems to be extremely performant.

View on HN

Yes, if you have light-weight threads, there's no question that threaded programming is better than async programming. But we are talking about heavy Java thread, and whether its cost is so high that we need to avoid threaded programming. I think the answer is no, generally.

Also, the discussion is in the context of imperative programming.

Funnily, Java's original threads (back in 1997) were green threads, but they got dropped in favor of native threads.

Rust supports both native and green threads, but defaults to native threads.

IIRC, Java's original threads were N:1 green threads, while the lightweight threads in Haskell discussed above are M:N green threads. N:1 is easier to implement, and fine for single core systems, but doesn't give you real parallelism. M:N, like 1:1 native threading, gives you real parallelism, but also, like N:1, cheap concurrency (at the expense of being the hardest to implement well.)

Multicore processors and the fact that single-threaded performance basically hit a wall explains why an N:1 threading models in something with the use cases of Java fell out of favor. M:N, while still "green threads", has a somewhat different set of trade-offs versus 1:1 native threads than N:1 does, though.

But there's no reason Java threads have to be heavy. Flip the question around: suppose you had a good syntax for nonblocking logic, and a library ecosystem where everything was async by default. In such a context (and we're getting there), why would you ever want to use traditional 4k threads? The only answers I can think of are for heavy number crunching and just maybe I/O on very fast dedicated devices.

So I think that's the future we're looking at: most code async, with the likes of LAPACK and some ultra-low-latency I/O libraries (hedge funds and the like) being the only users of traditional heavy threads.

See my blog post about a benchmark comparing the performance of heavyweight vs. lightweight Java threads in a web server: http://blog.paralleluniverse.co/2014/05/29/cascading-failure...

Reply on news.ycombinator.com