3 ms·
Oh microbenchmarks. All of this is going to be optimized away by a sufficiently smart compiler or a compiler you tell you want to spend lots of time optimizing
by DannyBee 11y ago
Oh microbenchmarks.
All of this is going to be optimized away by a sufficiently smart compiler or a compiler you tell you want to spend lots of time optimizing.
In general: don't write microbenchmarks where the results can be easily statically evaluated by the compiler, unless you are testing whether the compiler can statically evaluate it (this is a reasonable thing to want to know of course, but it's not a test of the language).
There are also languages which will pretty much not bother to do a lot of the the actual work, like haskell.
(Note: In this case, the the C++ compiler being used actually knows all the recurrences involved, but decides it's too expensive to statically calculate the final result of sum. GCC would do the same.)
- 21 11y agoDoesn't the std::vector calls mess things up? Now the compiler has to track those as well, they involve the allocator which calls into the OS. So for the compiler to be able to statically compute the result it would need to know that the std::vector stuff doesn't have side effects. Of course, the compiler could have special knowledge of std::vector, like for example in general it has about memcpy.
- DannyBee 11y ago"So for the compiler to be able to statically compute the result it would need to know that the std::vector stuff doesn't have side effects. " It can know this the same way it knows about memcpy. Most of them have library call info for things that have standardized guarantees. Even if it didn't, it knows what malloc does, it knows this variable never escapes, and ...
- pjmlp 11y agoNot only that, usually all the ones applied via gut feeling instead of a profiler are meaninglessness. Additionally, depending on the application domain, it might not even matter.