Hacker News new | ask | show | jobs
by hermanhermitage 5132 days ago
I'm kind of playing in the same space, although I tend to be more a hardware/assembler guy. Im currently prototyping with nodejs and C/C++ with inline assembler for AVX crunching.

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.