Ask HN: Event loop vs. Threads

I would view Node.js as an effective tool for leveraging js/v8. What's attractive for me when prototyping is throwing js/HTML UI over the top without having to switch gears. Look at raw node as an IO multiplexer and dispatcher but not a compute capable platform. The GC is weak for large data sets and the CPU efficiency is extremely poor for any heavy processing - very hard to manage your cache lines efficiently. Node sweet spot is packet and stream switching in webby stacks where the solid http, ssl and so forth are invaluable. Check out fabric (I forget the name) if you want to look at extracting more from JavaScript.

Suggest you check out LMAX and kx systems. And think how close you can get to a pure event sourced or stream processing model.

You will need the equivalent of one thread per (hyper)core to maximise effective instructions per clock - whether you need to do that will depend on your sustained memory bandwidth. So there a few C/C++ threads is not necessarily a bad thing.

Its possible to build a world class system in erlang with custom DSP, FPGA logic or using a GPU farm if you have the budget. This is the approach I would use if you have millions of decision sources.

If you want to maximise performance on x86 with a simple code base - and leverage SIMD it's hard to beat a combination of intel fortran and intel C/C++ compiler. You can roll your own messaging layer and put the compute node code in fortran - where you'll get great AVX throughput out of ifort.

Poll usually is run with threads on incoming connections/work, while epoll is keeping conections sleeping and wake up on incoming work. So in which way does this have "nothing to do with threads vs events at all"?

For sure the ratio of sleeping vs. active connections is important in the discussion on node.js model vs. a thread pool with a thread-per-connection setup. If you have very few active connections, poll and a thread-per-connection setup is more efficient (which does say nothing about the ratio of threads per CPU, context switches etc.), if you have a high number of inactive connections, say server-push or chat scenarios, event based connections are more efficient. The OP asked for efficiency.

I don't think the node.js is in any way relevant or efficient for event queues / single thread setups in high throughput scenarios like LMAX where poll/epoll is not relevant. But for node.js, poll vs. epoll setups are highly relevant as they show e.g. node.js vs. standard thread based behaviour.

They have incoming work, I/O for incoming and outgoing work is done multi threaded while work on events is single threaded.

The architecture is quite clever as more than one event processor can work on the data structure and event processors can have dependencies on each other. Independent processors can race past each other.

It was written for trading and might be portable to C++, but if you consider switching to JS it might also be ok for you to switch to Java. Their framework is called Disruptor and open source

http://code.google.com/p/disruptor/

"LMAX aims to be the fastest trading platform in the world. Clearly, in order to achieve this we needed to do something special to achieve very low-latency and high-throughput with our Java platform. Performance testing showed that using queues to pass data between stages of the system was introducing latency, so we focused on optimising this area."

Poll and epoll are trivial implementation details in both cases. Nobody is going to be choosing threads vs event loops based on poll vs epoll, you are using one or the other in both cases, and it is no more relevant to the decision than what you had for breakfast in either case.