Hacker News Reader

Comment by pcwalton | Hacker News Reader

Switching to asynchronous I/O isn't going to magically result in better performance on HTTP workloads. I don't think most of what any performance difference you're seeing is due to that: I suspect instead that it's relatively "boring" optimization work that has yet to be done in Hyper.

The primary difference between async and synchronous I/O is (a) better memory usage due to not having a stack per connection; (b) you can avoid the overhead of context switches to wake up an I/O thread; (c) thread spawning performance is faster due to the kernel not having to be involved. Golang's advantages in (a) and (b) are much less than what is typically thought of as "async I/O", because it still semantically uses a thread-per-connection and so is performing the same operations that a synchronous I/O implementation performs, just with a different implementation strategy.

View on HN

Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io. Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve. It's not a silver bullet, and can be very difficult to implement at the application layer to avoid blocking, but it will give markedly better performance.

But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model. So you're not forced to store all the thread's stacks and you don't have expensive context switches.

As the parent illustrated, even with Go using nonblocking I/O, it's perceived benefits in that area isn't that great because Go still semantically has a thread-per-connection. So the performance characteristics of Go isn't simply async vs sync I/O.

>But one of the reasons you're able to process more with async I/O is bypassing the costs of the thread-per-connection model.

One reason, not the only, or the most important. The primary advantage of non blocking IO is that the CPU isn't sitting idle while waiting for an IO operation to complete. We aren't wasting an entire core to write the response.

That's not how blocking I/O works! Sitting in a busy loop on the CPU burning power polling the I/O device was, like, how the Apple II may have worked, but it hasn't worked like that on any major OS since at least 1990. Operating systems perform context switches on I/O.

> Operating systems perform context switches on I/O.

which are very cheap :)

And if you accept that (which I'm not sure I do, but anyhow) then you accept that there isn't much difference between userspace M:N and blocking 1:1 threading.

> Go's networking library actually does call epoll/kqueue/etc on the backend, so it is using nonblocking io.

I know, of course. If you reread my comment, you'll notice that it wasn't focusing on the particular syscall that the system uses.

> Using nonblocking IO will provide better performance because it will increase the number of concurrent requests it can serve.

Because of (a), (b), and/or (c), which I addressed in my comment above.

Right, so Hyper would be faster if it used true asynchronous I/O, right? That was my whole point. I just brought up Go so I had something to compare it to.

Hyper may very well be much faster, but it isn't. Which is the whole issue with the Rust vs Go debates: one is possibly much better, but the other one gets all the code written for it in 1/6th of the time (Rust came out the same time Go did, to great fanfare).

Are we willing to wait 6x longer for rust to catch up? Some people are, most people aren't.

I don't know whether you're talking about a 6x development speed differential or a 6x performance difference between Rust and Go HTTP stacks or what, but I am pretty sure that by making up numbers like that you're language warring for no reason.

yes, in this case i am language warring for no reason. i'm an unapologetic go devotee but i like rust just the same. i wish people would just get on with things and write software, rather than comment on minutiae on message boards.

That's nice and all, but unfortunately the real world tests I've seen (and done) show something like Netty completely trumping anything available for Rust.

1. Are you testing against mio? If so, have you filed bugs against it? At a high level, there is no fundamental design difference between Netty and mio.

2. Netty is worlds away from Golang, precisely for the reasons stated above. Go is a userspace, M:N implementation of per-thread, blocking I/O, while Netty is a truly asynchronous I/O framework. Of course truly async I/O can beat synchronous I/O, but the entire point is that Golang is not strictly async I/O.

Reply on news.ycombinator.com