

C# vs C++: The mythical "twice as efficient" application - skrebbel
http://www.neowin.net/forum/index.php?automodule=blog&blogid=460&showentry=3973

======
matthewinrw
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".

------
facorreia
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.

