4 ms·

Spot on. It seems completely against some of the higher level philosophies of optimization presented in the article. For example, the 90/10 "rule". You should

by emcq 10y ago

Spot on. It seems completely against some of the higher level philosophies of optimization presented in the article. For example, the 90/10 "rule". You should focus your optimizations on things that matter. If applying the pre-increment operator vs post-increment operate makes any substantive difference, then it warrants better solutions such as: * Don't use STL. If you're running into overhead problems here you can almost certainly build faster custom data structures more specific to your usecases. * Use inline assembly for creating the tightest inner loops. If the overhead for an increment is significant, then that suggests the total number of operations in a loop is small. There may be some gains to be had by optimizing the assembly for the specific architecture and usage constraints. * While not all folks get to use C++11, you should also be using range based for loops in general which makes the number of cases where you see a manual increment on an object very small these days.

amaks 10y ago
STL is not inherently slow per se, some data structures are just not fast on modern CPUs, so they have to be chosen wisely. Here is good talk: https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs.
- emcq 10y ago
  Nice link! It's not that the algorithms are slow in some Big-O notation; it's that the utilization of hardware resources is typically poor. It's the general problem of balancing a general purpose solution versus an optimized high performance one. When you have more domain knowledge you can do better. A handful of examples: * A STL vector is typically at least 3 * sizeof(void * ) for the begin, end, and allocated size to be a general purpose solution [0]. You can trivially trim down space if you assume your memory is contiguous and then store deltas rather than pointers for the vector; which can be a nice win for 64-bit pointers. * A std::function blossoms to 48 bytes to support all the various usecases from lambdas to functors to function pointers. Using a template for lambda functions can allow inlining and be a win here, or writing your own that doesn't support all the usecases. * The lifetime of a std::string can involve a lot of allocations and deallocations. Fixed size char arrays can be a win. You can address all these with your own library functions. This is very consistent with the rest of the post's content, and in fact they suggest some of these approaches themselves. While these don't directly attack some fictitious ++i vs i++ performance bottleneck example, they will improve cache utilization and probably actually improve performance of your application :) [0] http://info.prelert.com/blog/stl-container-memory-usage http://info.prelert.com/blog/stl-container-memory-usage

by emcq 10y ago

amaks 10y ago

STL is not inherently slow per se, some data structures are just not fast on modern CPUs, so they have to be chosen wisely. Here is good talk: https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs.

emcq 10y ago
Nice link! It's not that the algorithms are slow in some Big-O notation; it's that the utilization of hardware resources is typically poor. It's the general problem of balancing a general purpose solution versus an optimized high performance one. When you have more domain knowledge you can do better. A handful of examples: * A STL vector is typically at least 3 * sizeof(void * ) for the begin, end, and allocated size to be a general purpose solution [0]. You can trivially trim down space if you assume your memory is contiguous and then store deltas rather than pointers for the vector; which can be a nice win for 64-bit pointers. * A std::function blossoms to 48 bytes to support all the various usecases from lambdas to functors to function pointers. Using a template for lambda functions can allow inlining and be a win here, or writing your own that doesn't support all the usecases. * The lifetime of a std::string can involve a lot of allocations and deallocations. Fixed size char arrays can be a win. You can address all these with your own library functions. This is very consistent with the rest of the post's content, and in fact they suggest some of these approaches themselves. While these don't directly attack some fictitious ++i vs i++ performance bottleneck example, they will improve cache utilization and probably actually improve performance of your application :) [0] http://info.prelert.com/blog/stl-container-memory-usage http://info.prelert.com/blog/stl-container-memory-usage