41–46 of 46 posts
On the general topic of how much we can rely on compilers, even using old and well-understood languages (C++), consult Mike Acton: http://www.slideshare.net/cellperformance/gdc15-code-clinic https://www.youtube.com/watch?v=rX0ItVEVjHc
C++ is well-understood? I don't get that impression from people who know it.
Note that the Python code is not limited to 32 bits and will automatically promote to bignum (aka long in py27). >>> l=[0xffffffff, 17] >>> sum(l) 4294967312 C based code will silently overflow/truncate, giving 16 in the example above. The author handwaved all this away, but it does show the usual tradeoffs between right/robust answers and fast answers.
Signed integer behaviour is undefined on overflow in C.
> What's the point of micro-optimizing a 3ms function call when each request spends 8 or 9 seconds inside the SQLAlchemy ORM? Well, sometimes it's nice to practice those optimizion skills anyway I have a different opinion on those 3ms optimizations: "It all adds up" Stopping at one 3ms optimization is not going to move mountains. But doing that 10 times is already 30ms. Imagine that you found 100 micro optimizations.…
300ms still doesn't put a dent in 8 or 9 seconds.
> So keep calm, optimize on. This is how compilers get better over time.
So work with the compiler rather than against it. As others have pointed out, with the correct -march setting you get code that's just as good as this hand-tuned assembly - and much more maintainable, and the correct compiler setting will improve the rest of your code as well.
Earlier quoted context omitted.
Signed integer behaviour is undefined on overflow in C.
But not on specific compilers with specific settings on specific machines like were used for the benchmarks results. Execution time is also undefined by the C standard.
Undefined behavior allows for aggressive optimizations where the compiler assumes the integer overflow can never happen, leading to such wonderful bugs as this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
Some compilers may offer specific settings, such as fwrapv, which give you a way to define the behavior of integer overflow. (Although last I read fwrapv was broken.) I see no mention of any such specific setting in the article. If you've spotted one I've missed, please call it out more specifically.
What if my list is: [2000000000, 2000000000, -2000000000, -2000000000]
"Our problem will be a very simple one: sum a list of n integers. To make this fair, we will assume that the integers all fit in a 32-bit signed int, and that their sum fits in a 32-bit signed int." What if my list is: [2000000000, 2000000000, -2000000000, -2000000000]
But it won't work for {2000000000, 2000000000}, as stated in the article.