On Mon, Nov 5, 2012 at 11:30 AM, Sam Rushing <span dir="ltr"><<a href="mailto:sam-pydeas@rushing.nightmare.com" target="_blank">sam-pydeas@rushing.nightmare.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/4/12 8:11 AM, Ben Darnell wrote:<br>
><br>
> The extra system calls add up.  The interface of Tornado's IOLoop was<br>
> based on epoll (where the internal state is roughly a mapping {fd:<br>
> event_set}), so it requires more register/unregister operations when<br>
> running on kqueue (where the internal state is roughly a set of (fd,<br>
> event) pairs).  This shows up in benchmarks of the HTTPServer; it's<br>
> faster on platforms with epoll than platforms with kqueue.  In<br>
> low-concurrency scenarios it's actually faster to use select() even<br>
> when kqueue is available (or maybe that's a mac-specific quirk).<br>
><br>
><br>
</div>Just so I have this right, you're saying that HTTPServer is slower on<br>
kqueue because of the IOLoop design, yes?<br></blockquote><div><br></div><div>Yes.  When the server processes a request and switches from listening for readability to listening for writability, with epoll it's one call directly into the C module to set the event mask for the socket.  With kqueue something in the IOLoop must store the previous state and generate the two separate actions to remove the read listener and add a write listener.  I misspoke when I mentioned system call; the difference is actually the amount of python code that must be run to call the right C functions.  This would get a lot better if more of the IOLoop were written in C.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I've just looked over the epoll interface and I see at least one huge<br>
difference compared to kqueue: it requires a system call for each fd<br>
registration event.  With kevent() you can accumulate thousands of<br>
registrations, shove them into a single kevent() call and get thousands<br>
of events out.  It's a little all-singing-all-dancing, but it's hard to<br>
imagine a way to do it using fewer system calls. 8^)<br></blockquote><div><br></div><div>True, although whenever I've tried to be clever and batch up kevent calls I haven't gotten the performance I'd hoped for because system calls aren't actually that expensive in comparison to python opcodes.  Also at least some versions of Mac OS have a bug where you can only pass one event at a time.</div>

<div><br></div><div>-Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Sam<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div>