4 ms·
> Goroutines are threads. So the idea the "Go has eliminated the distinction between synchronous and asynchronous code" is only vacuously true, because in Go, e
by weberc2 8y ago
> Goroutines are threads. So the idea the "Go has eliminated the distinction between synchronous and asynchronous code" is only vacuously true, because in Go, everything is synchronous.
Abstractly, I agree, but practically the distinction is important. In Go you don't have to use a frustrating async interface to get decent performance. You don't have to manage a threadpool or other tricks. You pretty much get the threadlike interface you want to use without the difficulty.
- pcwalton 8y agoLet's be clear: the one-OS-thread-per-connection model does yield decent performance. We used to call async I/O "solving the C10K problem"—i.e. serving 10,000 clients simultaneously. I'm speaking from experience here, having tried to implement M:N and abandoning it in favor of 1:1, which yielded better performance. Can M:N yield better performance than 1:1? Sure, in some circumstances. But I think that, ideally, we should be striving for 1:1 everywhere.
- dboreham 8y agoAll true. But I have been waiting nearly 30 years for a 1:1 implementation that scaled to the #threads I want to have. Still waiting... The point of M:N schemes isn't to achieve better performance but rather to achieve higher scaling.
- pcwalton 8y agoHow many threads do you want?
- toast0 8y agoI'm not the person you're asking, but I want one thread per connection, and I want one million connections per host.
- zzzcpan 8y agoBut then with a million of threads either M:N or 1:1 you have other problems, namely the whole shared memory multithreading model breaks and you can forget about all the locks/channels if you want to actually do something useful with that.
- dboreham 8y agoI believe there are boxes in production with 1E6 live connections.
- marcosdumay 8y agoIf they exist, they are running software written on either C or Rust, that can avoid memory efficiency traps and can schedule their workers on a more optimum way than a general purpose language. That said, I'm not sure such thing exists. Just the memory overhead some common libraries impose on connections is enough to fill some 32GB.
- toast0 8y agoErlang works just fine for that many connections (depending on how much CPU you spend doing real work per connection). Socket buffers are tunable. 32GB isn't that much ram for a server, Android phones are shipping with 6gb, you can get 6TB into a server without getting too exotic.
- NightlyDev 8y ago3 million connections: https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb https://medium.freecodecamp.org/million-websockets-and-go-cc... Heck, you can probably handle a million connections using PHP(with swoole).
- zzzcpan 8y agoIn the article they got rid of goroutines to get to 3 million connections.