3 ms·

If any of this is interesting to you, but you would like some deeper content to bite into, perhaps start here: https://lmax-exchange.github.io/disruptor/disrup

If any of this is interesting to you, but you would like some deeper content to bite into, perhaps start here: https://lmax-exchange.github.io/disruptor/disruptor.html https://lmax-exchange.github.io/disruptor/disruptor.html This technical paper sent me on a multi-year journey regarding one simple question: "If this stuff is fast enough for fintech, why can't we make everything work this way?" Handling millions of requests per second on 1 thread is well beyond the required performance envelope for most public "webscale" products.

smabie 4y ago
HFT architecture tends to be grossly inefficient from a throughput perspective: i.e you'll usually be busy waiting for new data.
intelVISA 4y ago
That's like asking why a motorbike isn't a car - they have the same goal: get from A to B but quite different considerations. Most webscale products aren't written in performant languages and are, instead, optimized around fast feature generation and being easy (cheap) to hire for. There's a reason laggy Electron apps are the norm $$.
boshalfoshal 4y ago
The thing is, some tech companies do optimize to this degree (fb, google) - except it only really makes a lot of sense for companies that have A. Capital (human and money) B. Bespoke internal tools from the server up C. Insane scale Google and meta put in lots of effort to have fast C++ code for their core infra, and they have several teams contributing to the LLVM project. Even places like Figma optimize to some extent because part of their business alpha is being performant and smooth. When you are at the scale of FB or G, optimizing the small things can lead to massive aggregate gains, and they have the eng talent/time to justify it. At smaller companies though, as others have mentioned, iteration time and efficient dev spend are paramount. Optimizing for microsecond latency with on your B2B SaaS product written in Python/React is most likely not part of your business case, and it is a waste of engineering time and effort to do this when you could be putting that time and money into new and better features. Most of the time, these very niche performance considerations are taken care of to a decent degree with off the shelf tools, maybe with a bit of tuning.

smabie 4y ago

HFT architecture tends to be grossly inefficient from a throughput perspective: i.e you'll usually be busy waiting for new data.

intelVISA 4y ago

That's like asking why a motorbike isn't a car - they have the same goal: get from A to B but quite different considerations. Most webscale products aren't written in performant languages and are, instead, optimized around fast feature generation and being easy (cheap) to hire for. There's a reason laggy Electron apps are the norm $$.

boshalfoshal 4y ago

The thing is, some tech companies do optimize to this degree (fb, google) - except it only really makes a lot of sense for companies that have A. Capital (human and money) B. Bespoke internal tools from the server up C. Insane scale Google and meta put in lots of effort to have fast C++ code for their core infra, and they have several teams contributing to the LLVM project. Even places like Figma optimize to some extent because part of their business alpha is being performant and smooth. When you are at the scale of FB or G, optimizing the small things can lead to massive aggregate gains, and they have the eng talent/time to justify it. At smaller companies though, as others have mentioned, iteration time and efficient dev spend are paramount. Optimizing for microsecond latency with on your B2B SaaS product written in Python/React is most likely not part of your business case, and it is a waste of engineering time and effort to do this when you could be putting that time and money into new and better features. Most of the time, these very niche performance considerations are taken care of to a decent degree with off the shelf tools, maybe with a bit of tuning.