Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed Shaw: "poll, epoll, science, and superpoll" with R

sheddingbikes.com

Post reply on HN
Print view View original

71–80 of 149 posts

Re: Zed Shaw: "poll, epoll, science, and superpoll" with R

#71

Post by zedshaw »

kqueue wrote: post #46

Lets assume we have 20k opened FDs. In case of poll(), you have to transfer this array of FDs from the userland vm to the kernel vm each time you call poll(). Now compare this with epoll() (let's assume we are using EPOLLET trigger), when you only have to transfer the file descriptors once. You might say the copying won't matter, but it will matter when you have a lot of events coming on the 20k FDs which eventually…

Yep, that's what I thought too, that at least epoll would be as fast. Turns out it's not though, but then I could be wrong.

Also, your assumption of EPOLLET is potentially wrong. I think (unproven) that the extra overhead and complexity of using edge trigger right makes EPOLLET pointless.

Re: Zed Shaw: "poll, epoll, science, and superpoll" with R

#72

Post by zedshaw »

kunley wrote: post #26

Cool experiment Mr Zed, but what about kqueue? It seems superior to both *poll minions. Would be great if you proved/falsified this thesis as well.

Well, I haven't tried kqueue, but IIRC it has its own set of problems. Mainly that you can't kqueue certain types of file descriptors like ptys. I'd have to look into that, but I'm sure I'll have some kind of thing going about it soon.

Re: Zed Shaw: "poll, epoll, science, and superpoll" with R

#74

Post by zedshaw »

bdr wrote: post #69
zedshaw wrote: post #58

Earlier quoted context omitted.

So let's take your assertions and take them apart: > the ones on dial up and on congested lines will get you every time. Do you have numbers on the dial-up users for your server? My understanding is that there's far fewer, so this is bogus. Show evidence of high dial-up penetration first. > They keep the processes busy far longer than you'd want and you have to hit the 'poll' cycle far more frequently Again, you have…

Read "on dial-up" as "slow". The argument depends only on there being a certain distribution of client speeds. It's not about dial-up in particular.

And, if there's a distribution of speeds then you can measure the distribution and see what works best. Again, my challenge still stands:

Measure it or STFU.

Re: Zed Shaw: "poll, epoll, science, and superpoll" with R

#75

Post by jacquesm »

zedshaw wrote: post #64
jacquesm wrote: post #13

Earlier quoted context omitted.

> A conclusion reached by measurement is not premature. That's just plain wrong. Premature optimisation does not refer to having to measure before you optimise, it refers to optimising things that in practice may have little or no effect on the actual performance of the program. By doing these tests in isolation instead of while running on a profiling kernel under production load it is very well possible that the bot…

Again with this idea that Mongrel2 isn't working. You sir have no freaking idea what you're talking about. "That's just plain wrong. Premature optimisation does not refer to having to measure before you optimise, it refers to optimising things that in practice may have little or no effect on the actual performance of the program." No, that's just plain wrong. Premature optimisation is actually implementing something…

So, if it's working why not throw a load of real world traffic at it in stead of this 'science' that you're performing here ?

After all, that is where the rubber meets the road and it would be a very easy way to determine if your hunch is right or not.

Epoll was specifically created with that sort of workloads in mind, your 'surprising' conclusion is not rooted in the fact that epoll is somehow behaving in a way that is contrary to expectation, in fact it behaves exactly as it is designed to do.

Benchmarking it like this is nothing like the real world, and that's where epoll shines, not when you test it the way you just did.

As for the numbers, we're serving about 10Gbps continuously using a combination of varnish and java code to several million uniques daily, html, images, video. Poll over epoll is a run race, as far as I'm concerned you're wasting your time with this.

But by all means, ignore all this and do what you have to, those are the lessons learned best anyway, and it's your time, not mine.

If you feel like getting another view on this I'd suggest to contact the author of Varnish, he really knows his stuff and he might be able to convince you where I can not.

Re: Zed Shaw: "poll, epoll, science, and superpoll" with R

#76

Post by rbanffy »

zedshaw wrote: post #68
rbanffy wrote: post #29

Earlier quoted context omitted.

> it's not clear what exactly your complaint is. Any complexity introduced in the code increases its long term maintenance cost. I strongly suspect this is one of those cases where the performance gain will not justify the long-term effort of maintaining a more complex architecture. I remember having a similar discussion circa 1992 about advantages and disadvantages of using ODBC versus native MS SQL/Sybase libraries…

So, you're comparing my track record with writing simple maintainable well documented code to something you did in 1992 with ODBC? That's your experience that's causing all the paranoia? The worst two things that afflict programmers today is: 1. They never update their information, even after 18 years (18! You realize that right!? Things change man!) 2. They have an irrational paranoia about trying new things, as if…

1) Will you maintain Mongrel forever? It's not your track record that's the question, but the one of all future maintainers of Mongrel that will have to deal with the added complexity this change creates.

2) The experience from 1992 still seems current. Adding complexity to any software project adds cost to maintain it in the future. My experience in 1992 showed how added complexity for a marginal performance gain did not pay off then and still won't pay off today (unless you are programming a computer so expensive even a marginal increase in performance means lots of money).

3) It's your project and you may do with it whatever pleases you. What I wrote was intended as friendly advice from someone who is in this business for a long time. You are, of course, free not to accept the advice.

4) I encourage you to try new things and I am usually the first to propose workload-adaptable solutions. I, however, had my share of extremely clever optimizations that bit me back later when things as subtle as processor caches changed and it's not very funny (albeit it is fun to dig deep in the system to find out why X runs 33% slower on the 50% faster box). Nowadays, I consider every program line not written a line gained.

Re: Zed Shaw: "poll, epoll, science, and superpoll" with R

#78

Post by FooBarWidget »

kqueue wrote: post #54
FooBarWidget wrote: post #53

Earlier quoted context omitted.

Why would there by any copying? The kernel can directly read userspace memory.

For the kernel to execute a system call, it has to place the arguments on its stack. a system call doesn't execute in the userland.

Yes but the argument to poll is a pointer. The pointer would be copied but the kernel can still follow the pointer to userspace, right?

Re: Zed Shaw: "poll, epoll, science, and superpoll" with R

#79

Post by phintjens »

Zed, whats with all the premature optimization? Surely Mongrel2 should first be able to make coffee, build you an island and f@!in transform into a jet and fly you there, before you start to make it faster!

Just kidding. It's always nice to see science in action. Great work! I suspect there's an impact on ZeroMQ's own poll/epoll strategy.

Post reply on HN