6 ms·

why would anyone still be using threads or processes these days? :/ hardly scalable or efficient.

• lttlrck 13y ago
  To take advantage of multiple cores?
  • gargoiler00 13y ago
    Yeah because I have as many cores as I have concurrent HTTP requests, and obviously it's CPU bound...
    • erichurkman 13y ago
      Sockets are used for a lot more than just serving HTTP requests.
      • gargoiler00 13y ago
        They certainly are. But my point is that if you're only servicing the same number of IO connections as you have cores, it's not extremely scalable. Most networking servers should be dealing with hundreds or thousands of concurrent connections.
        • bdarnell 13y ago
          The linked article didn't make this clear, but this feature is mainly designed for process-per-core models, not process-per-connection. The problem you run into with most existing process-per-core systems is that you can't ensure an even distribution of load across the processes without introducing extra overhead. SO_REUSEPORT offers some convenience when changing the number of processes, but the real benefit is that in this mode the kernel uses a better load-balancing scheme.
• jerf 13y ago
  You know, this [1] really ought to permanently put away the idea I think you're trying to reference, which is that only "event based" systems can be performant. There's plenty of "thread" or "process" based approaches that do quite well, including I believe the uppermost tier of every benchmark on that site. The idea that threads or processes are intrinsically slow was sheer unmitigated propaganda, and probably not only failed to contain a grain of truth, but are actively false. (Some thread implementations were slower than others, but that turns out to have been the implementations rather than the idea.) Event based systems inevitably have a lot of function calls in them, and that will probably in the end be slower than properly done threads or continuation-based approaches, always, because of that overhead. [1]: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/
  • gargoiler00 13y ago
    > The idea that threads or processes are intrinsically slow was sheer unmitigated propaganda, and probably not only failed to contain a grain of truth, but are actively false. Threads / processes: * Run some code from A * Save state, context switch * Run some code from B * Save state, context switch * Deal with locking, synchronisation, etc vs * Run some code. There is absolutely no instances where [num threads] > [num cores] is as efficient as not using more threads than cores.
    • jerf 13y ago
      Funny, then, you'd think the benchmarks would show that, if it's so obvious, instead of showing the opposite. The problem is that once you understand what lies behind your glib "run some code", you understand what the problem is. I mean, for one thing, the idea that in a busy server switching to a different event handler which has neither its code nor its data in any processor cache is not itself a "context switch" is a use of the term not necessarily connected to any reality, even if one might pass Computer Science 302 with that answer. Alas, we can not convince our CPUs or RAM to go any faster by arguing at them that they aren't making a "context switch". But, you know, it's an open benchmark, and the benchmarks themselves aren't all that complicated. Do feel free to submit your event-based handlers that blow the socks off the competition. Bearing in mind that is the standard you've set here. Merely competitive means you've still lost. Nor do I see any "but benchmarks don't mean anything" wiggle room in your statements, because what you're talking about is exactly what is being benchmarked.
• colanderman 13y ago
  To hide I/O latency. You cannot do this effectively without threads without implementing your own scheduler, unless your I/O delays are constant and known a priori.