3 ms·
Go is perfect for almost every kind of server! Though handling DNS requests over UDP is pretty easy and fast in almost any language. TCP connections are much m
by staunch 13y ago
Go is perfect for almost every kind of server!
Though handling DNS requests over UDP is pretty easy and fast in almost any language. TCP connections are much more pleasant to handle by spawning a goroutine per connection. I do assume using goroutines is slower than multiplexing though, but still plenty fast.
- pmjordan 13y agoI do assume using goroutines is slower than multiplexing though, but still plenty fast. Surely, the goroutine model is just an abstraction built on multiplexing? As in, it uses the exact same syscalls that a multiplexing server written in C would use, except instead of storing state explicitly in a connection structure, it's stored implicitly in the goroutine's stack. The main (only?) real difference is code structure and thus the dispatch mechanism to where in the connection handling code processing should resume: In the goroutine, you're literally storing the instruction pointer and jumping straight to it. In the hand-written case, you'll probably go through some buffering code and an explicit state machine. Basically, Go and its goroutines save you reinventing the connection state capture and resuming code for every single protocol you implement - it comes for free as part of the language. (you can make C do similar things with makecontext/swapcontext plus some extra plumbing code of course) Performance wise it should be a pretty close call: resuming a goroutine will presumably cause a branch prediction miss (due to the change in function return pointer), whereas the multiplexed code will need to wind its way through the state machine logic - almost certainly also a branch prediction miss. CPU cache behaviour should likewise be similar (you're storing the same state either way).
- pcwalton 13y ago> Performance wise it should be a pretty close call: resuming a goroutine will presumably cause a branch prediction miss (due to the change in function return pointer), Also you have to reload the register file when the goroutine scheduler wakes the goroutine up, and save it when the goroutine goes back to sleep.
- staunch 13y agoThis is true, but I'd be very surprised if you could beat the memory usage and performance of a while loop with epoll using goroutines. At least in the role of a DNS server. Now I want to test this...
- pmjordan 13y agoYeah, stateless datagram protocols are pretty much the optimal problem for unadorned async I/O.
- mietek 13y agoA language perfect for almost every kind of server would not allow a single connection handler disrupt every other connection handler. A single goroutine can corrupt the heap shared by every other goroutine.
- seunosewa 13y agoHow? Go apps generally don't manipulate memory in an unsafe way.