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

141–149 of 149 posts

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

#141

Post by vidarh »

axod wrote: post #23
jakevoytko wrote: post #20

Earlier quoted context omitted.

"I need polling" => "Here are my options, which one is better?" => "They're good for different things" => "I'll pick the best one for the environment" is a reasonable design process. More so than some decisions that I make! Yes, there's a fixed time budget. But you're suggesting selectively ignoring evidence when designing a program, preferring random guessing and pattern matching to actual numbers. Should he have co…

"I need a filesystem" => "Here are my options, which one is better?" => "They're good for different things"... STOP For most things, it doesn't matter. A filesystem is a filesystem. You only need to make decisions like that when you properly measure and decide that X may be a bottleneck, or you need features that Y has but X doesn't.

In nearly every large system I've been involved in designing, a "filesystem is a filesystem" would give you a great chance of rendering the system non-functional or performing so bad it might as well be non-functional when making simple design decisions based on knowledge about the problem made it easy to avoid in the first place.

Premature optimization is a sin, but making design decisions you know from experience has a major impact is not, as long as you measure to confirm afterwards.

We don't design by throwing dice - most decisions we make are based on experience or assumptions about what works and what doesn't. Measurements are important to challenge those assumptions, but it doesn't take away the value of making use of experience to create a reasonable baseline.

Where "premature optimization" comes in is where you start expending unnecessary extra effort to implement a more complicated solution without evidence to back up the need for it.

Spending a little bit of time to think through the requirements for major aspects of your system is not extra effort.

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

#142

Post by kqueue »

FooBarWidget wrote: post #125
kqueue wrote: post #122

Earlier quoted context omitted.

When the kernel is executing a function call placed on the stack, all the addresses on the stack are assumed in the same vm space. It does not know that an address is actually a virtual memory address belonging to process X and tries to figure out the value in the physical memory.

Yeah but it's possible to look up things in userspace right? So just change poll() to assume that the pointer points to userspace. I don't see the need for copying.

When the kernel calls poll, poll will access memory in the kernel address space because that's where it is running. All the addresses accessed in any system call are in the kernel address space. They don't go back and forth and swap vm pointers to fetch data from other processes. That's not how kernels work. And no you cannot change poll().. You write epoll/kqueue

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

#143

Post by kunley »

silentbicycle wrote: post #52
kunley wrote: post #39

Earlier quoted context omitted.

I'm aware of it (you forgot to mention that kqueue is on the OS X as well). So what? There are probably hordes of people who will be willing to run Mongrel2 on *BSD platforms, precisely because of the performance reasons. And Zed is a famous tinkerer rather than a religious zealot, so very probably he could be interested in checking kqueue as well. "Why not" is also a good reason for a hacker when he's lacking other…

My point was that comparing something that only runs on Linux against something that only runs on (various) BSDs adds a lot of other noise to the comparison - it's no longer the same hardware, install, and tuning, with just a different kernel call.

I see your point. Still it would be useful to see some typical BSD/kqueue in action compared to typical Linux/*poll. I bet Zed is not doing a big sysctl tuning at this stage. Just leaving default system settings as they are still is some starting point for further investigations.

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

#144

Post by pphaneuf »

zedshaw wrote: post #71
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.

Why would there be extra overhead when using edge triggered? There's definitely extra complexity on the client side, but it's close to what you're trying to do with super-poll (the extra complexity is basically to find out when an fd isn't busy anymore).

I think it might even be faster, kernel-side. From what I remember of the implementation, both modes have to walk the same list of ready fds, but that list is shorter in edge triggered mode, because they get removed from the list as it goes.

Edge triggered might have more overhead if many fds change between ready/not-ready quickly, but that's quite the wacky situation (and if it has an even distribution, would ensure your ATR is about 0.5, so probably still winning).

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

#145

Post by Confusion »

zedshaw wrote: post #132
jacquesm wrote: post #113

Earlier quoted context omitted.

> I'm a scientist I've never come across a scientist that took criticism of their work the way you do and that responded in the way you do. Shouting down, deriding, insulting and in general being a jerk to those that don't agree with you because 'you're a scientist' is not the way of science.

I'm shouting you down because you're a FUD slinging troll. Very first thing you did was immediately reply to every branch of the comments with your agenda. I actually have no idea what your problem is, since I'm just presenting some information and working on my own software with it, but you've got some weird "epoll religion" you like to spread. So, consider me the Richard Dawkins of epoll.

  Very first thing you did was immediately reply to every branch of the
  comments with your agenda.
You're suffering from paranoia. If you post an article about security, you can bet tptacek is all over the comments, informing and correcting people. In this case, the article was about something jacquesm happens to know a bit about, so he participates actively in the comments. To suggest he is pushing an 'agenda' is ridiculous: there's nothing at stake for him. The only thing he tries to do is help you, by noting that he thinks you have overlooked something.

  I actually have no idea what your problem is [..]
That's because he doesn't have a problem: it's your mind that's filling in the blanks. It suggests that while writing the article, you were already sure people would challenge you based on 'religious conviction' instead of on fact. jacquesm's point was a simple, critical question: what are actual real-world ATR's for the servers that Mongrel2 should be able to replace?

Allow me to make an observation of a psychological nature: you are thoroughly miffed that it was so easy for someone to provide possibly devastating criticism to an idea about which you started caring WAY to much. What you should realize it nobody thinks lesser of you because of that criticism: the article is still interesting and provides a sound basis. There is no reason to react in such a aggressive way; it's even counterproductive.

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

#146

Post by Confusion »

zedshaw wrote: post #134
jacquesm wrote: post #117

Earlier quoted context omitted.

The tests are perfectly valid, it's the conclusion that is wrong. Of course there is a trade-off, of course you'll find a cross-over point because there is a trade off. The fact that the crossover point is at roughly 60% for your kernel config and machine setup is essentially meaningless, other than that it it at least falls within the expected range (50 to 80% or so). Your hypothesis is that web servers have the maj…

"Your hypothesis is that web servers have the majority of their fds active most of the time," Aha! Totally wrong. My hypothesis has not been that at all . You totally didn't even understand the hypothesis, and I stated it very clearly. My hypothesis has always been: epoll is faster than poll when the active/total FD ratio is 0.6. Nowhere in there do I say that all web servers have the majority of their FDs active. NO…

  My hypothesis has always been:

  epoll is faster than poll when the active/total FD ratio is  0.6.
That wasn't your hypothesis: that was your intermediate conclusion after the first tests. Your hypothesis was: the common knowledge that epoll yields better performance, and that I should obviously use epoll for Mongrel2, is wrong. [1]

It's obvious he didn't mean 'hypothesis', but 'implicit assumption'. If you implement superpoll, you implicitly assume it will be useful. It will only be useful if actually deployed Mongrel2 servers will have an ATR > 0.6 at least some of the time.

[1] You can replace 'is' by 'may be', if you feel the strong version puts words in your mouth. It doesn't, because the hypothesis for an experiment may also be "The half life of protons is shorter than a trillion years", when I expect to reject that hypothesis. It's not an assertion of your opinion, but a statement of a fact you intend to accept or reject based on the outcome of the experiment.

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

#147

Post by Confusion »

mfukar wrote: post #37
jacquesm wrote: post #11

Earlier quoted context omitted.

I highly doubt that in production it will make any difference at all. In the end it is not the poll/epoll overhead that determines your overall throughput. If you call poll/epoll more frequently than you should then it starts to add up but in reality one call per several thousand file system operations doing real IO is not going to make a big difference. Of course all the little bits help and I'm happy to see someone…

I keep seeing this...misconception? I don't know what to call it, over most comments. The article doesn't talk about optimizations. It talks about design decisions . Someone actually took the time to sit down, ponder what kind of workloads will be handled by his application, came across an interesting dilemma, measured and tested them both, and finally reached an educated conclusion. That right there is how you corre…

  Someone actually took the time to sit down, ponder what kind of
  workloads will be handled by his application
The most important point made in this thread is that Zed actually didn't do that, but did benchmarks for a range of workloads, suggesting he intends Mongrel2 to be able to handle all of them. The question is whether that is necessary. If ATR > 0.6 never happens in practice, it will only unnecessarily complicate Mongrel2.

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

#148

Post by Confusion »

blueben wrote: post #106
jacquesm wrote: post #75

Earlier quoted context omitted.

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…

Because "real world traffic" is a bullshit test. Who's real world traffic? Mine? Yours? Google's? Yahoo's? Science is repeatable, which means you can replicate the same inputs to the test every time. The lab experiments involved in science are often highly sanitized and not "real world" at all. Determining what the results mean in the real world comes later. If you're going to complain about science, at least underst…

  Because "real world traffic" is a bullshit test [..]
The hell it is. A statistically significant sample of 'real world ...' is the foundation for most engineering decisions. When you build a bridge, you take the actual loads it has to support into account. Intel bases their chipbaking on the actual purity of the silicon their suppliers can provide.

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

#149

Post by jacquesm »

zedshaw wrote: post #61
FooBarWidget wrote: post #6

Earlier quoted context omitted.

An active file descriptor is one that you can read from or write to without blocking or getting EAGAIN as error. The whole point of poll/epoll/kqueue/select is to figure out which file descriptors are in such a state. The difference between poll and epoll is that, given an input of N file descriptors, poll returns all N file descriptors and you need to loop through each one of them to check whether the 'active' flag…

I totally absolutely agree they should fix epoll, but the way they've designed I don't see it happening. Of course they could fix the call for doing the actual select and make it at least as fast as poll, but the fact that you have to do a syscall for every file descriptor is idiotic.

Some people actually did fix epoll, benchmarked the results and concluded it wasn't worth it.

http://www.linuxinsight.com/ols2004_comparing_and_evaluating...

Post reply on HN