Evio – Fast event-loop networking for Go
github.com
Evio – Fast event-loop networking for Go
1–10 of 67 posts
Re: Evio – Fast event-loop networking for Go
#2The Go network stack already makes use of epoll and kqueue: https://golang.org/src/runtime/netpoll_epoll.go
So I'm not quiet sure why this would be faster since almost all I/O in Go is event driven, including the networking stack.
Re: Evio – Fast event-loop networking for Go
#3The Go network stack already makes use of epoll and kqueue: https://golang.org/src/runtime/netpoll_epoll.go So I'm not quiet sure why this would be faster since almost all I/O in Go is event driven, including the networking stack.
Well, I guess because the runtime has to do a bunch of work to dispatch the events to the appropriate goroutine that is blocked waiting for that event. Switching and synchronization between goroutines is cheap, not free.
Re: Evio – Fast event-loop networking for Go
#4The Go network stack already makes use of epoll and kqueue: https://golang.org/src/runtime/netpoll_epoll.go So I'm not quiet sure why this would be faster since almost all I/O in Go is event driven, including the networking stack.
Well, I guess because the runtime has to do a bunch of work to dispatch the events to the appropriate goroutine that is blocked waiting for that event. Switching and synchronization between goroutines is cheap, not free.
And this solution does somehow not switch between goroutines?
Re: Evio – Fast event-loop networking for Go
#5The Go network stack already makes use of epoll and kqueue: https://golang.org/src/runtime/netpoll_epoll.go So I'm not quiet sure why this would be faster since almost all I/O in Go is event driven, including the networking stack.
The benchmarks at the bottom of the readme show quite an improvement (with a single thread it seems).
I would speculate the performance win is because there is no stack switching and less channels.
I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state etc is all hard work and easy to mess up.
I am reminded of this post I saw on HN a while ago https://www.mappingthejourney.com/single-post/2017/08/31/epi... Ryan Dahl, creator of node.js, would just use Go today ;)
Re: Evio – Fast event-loop networking for Go
#6Earlier quoted context omitted.
Well, I guess because the runtime has to do a bunch of work to dispatch the events to the appropriate goroutine that is blocked waiting for that event. Switching and synchronization between goroutines is cheap, not free.
And this solution does somehow not switch between goroutines?
No, the event loop is just one big goroutine that calls all the handlers directly.
Re: Evio – Fast event-loop networking for Go
#7I love Go because I never had to write asynchronous, callback driven programs in this language. I hope it won't become the norm in Go, too.
Re: Evio – Fast event-loop networking for Go
#8One of my favorite things about Go is that it cuts through the "threads vs. events" debate by offering thread-style programming with event-style scaling using what you might call green threads (compiler assisted cooperative multitasking that has the programming semantics of preemptive multitasking).
That is, I can write simple blocking code, and my server still scales.
Using event loop programming in Go would take away one of my favorite things about the language, so I won't be using this. However I do appreciate the work, as it makes an excellent bug report against the Go runtime. It gives us a standard to hold the standard library's net package to.
Re: Evio – Fast event-loop networking for Go
#9Not sure i understand what the use case is. As soon as you start doing something on the event loop , you need some kind of way to perform the operation in another "thread" ( or goroutine or whatever).
And then you start to need some kind of concurrency mechanism, and pay the price.
Stripping those mechanism to pretend the event handling is faster only works if you never intend to have some real computation performed. That's never true in practice... Or am i missing something ?
Re: Evio – Fast event-loop networking for Go
#10The Go network stack already makes use of epoll and kqueue: https://golang.org/src/runtime/netpoll_epoll.go So I'm not quiet sure why this would be faster since almost all I/O in Go is event driven, including the networking stack.
The benchmarks at the bottom of the readme show quite an improvement (with a single thread it seems). I would speculate the performance win is because there is no stack switching and less channels. I've done lots of event loops in the past (eg hellepoll in c++) and think that the cost of that is on the programmer - keeping track of things, callbacks, state machines and things and avoiding using the stack for state et…
Yeah, but that's with 1 maximum thread. The whole point of Go is to use green threading to your advantage.