It's obvious the author doesn't work with market data. Those "mythical" applications are all running wall street. You won't find a single matching engine written in C# these days.
The short answer is that SRAM is faster than DRAM, and you can be a lot stingier with memory in C++ and hence fit more into the fast type of RAM.
Stack-based allocation is not by any means an "advanced" technique, and is the absolute fastest form of memory management, full stop. It can deallocate an arbitrary number of objects in a single assembly instruction. Good C++ makes extensive use of the stack for this reason.
Stack allocated objects are densely packed into the L1 cache, making them faster than objects from an allocator which might spray them over the address space in suboptimal scenarios.
This absolute control over how memory is being used, (_when_ done well) is the difference between "gee that's pretty fast" and "wow".
One of Sutter's argument is that C++ is more cost-efficient in a data center due to lower energy costs. Yet, I haven't heard of many SaaS applications developed in C++. The Rails-style "just throw more servers at it" way is still very popular (which Sutter mentions as optimizing for programmer productivity).
I suppose for startups the answer is to eschew premature optimization (for cost) and get the MVP done as quickly as possible (optimizing for programmer productivity). And, if and when demand requires, invest enough to optimize the bottlenecks.
2 comments
[ 5.7 ms ] story [ 15.5 ms ] threadThe short answer is that SRAM is faster than DRAM, and you can be a lot stingier with memory in C++ and hence fit more into the fast type of RAM.
Stack-based allocation is not by any means an "advanced" technique, and is the absolute fastest form of memory management, full stop. It can deallocate an arbitrary number of objects in a single assembly instruction. Good C++ makes extensive use of the stack for this reason.
Stack allocated objects are densely packed into the L1 cache, making them faster than objects from an allocator which might spray them over the address space in suboptimal scenarios.
This absolute control over how memory is being used, (_when_ done well) is the difference between "gee that's pretty fast" and "wow".
I suppose for startups the answer is to eschew premature optimization (for cost) and get the MVP done as quickly as possible (optimizing for programmer productivity). And, if and when demand requires, invest enough to optimize the bottlenecks.