Hacker News Reader

Comment by fear91 | Hacker News Reader

The nice thing about compiler optimizations is that you can improve performance of existing CPU's without physically touching them. Year by year. You squeeze more of the machine someone designed. It adds up.

Imagine what environmental impact you would have if you optimized Python's performance by 1%? How much CO2 are you removing from the atmosphere? It's likely to overshadow the environmental footprint of you, your family and all your friends combined. Hell, maybe it's the entire city you live in. All because someone spent time implementing a few bitwise tricks.

View on HN

> Imagine what environmental impact you would have if you optimized Python's performance by 1%?

I imagine this would also increase the complexity of the python intepreter by more than 1%, which in turn would increase the number of bugs in the interpreter by more than 1%. Which would burn both manpower and CPU-Cycles on a global scale.

(I assume that optimization, that reduce complexity are already exhausted, e.g. stuff like "removing redundant function calls". )

This is an assumption that a reasonable person naively comes up with.

Then if you actually go ahead and check, it turns out it's not true! It's quite a shocking revelation.

When you dig into the popular compilers/runtimes (with the exception of things like LLVM)

Many of them still have low hanging fruit of the form:

a = b + c - b

Yes, the above is still not fully optimized in the official implementations of some popular programming languages.

Also an optimization of "removing redundant function calls" isn't a binary on/off switch. You can do it better or worse. Sometimes you can remove them, sometimes not. If you improve your analysis, you can do more of that and improve performance. Same for DSE, CSE, etc...

In many languages, you can't just optimize + b - b willy-nilly, as there could be side effects and non-obvious interactions abound. For instance, in JavaScript, where everything is a 64-bit double, a + b - b is definitely not the same as a, given large enough or small enough a or b. In LLVM for floats as well, certainly.

It's an example of how trivial some of this low hanging fruit is, the above is a concrete case that I have personally implemented (arithmetic of in-register 64/32-bit integers). You can get into semantics and restrictions, but I think the point I'm raising is clear.

Reply on news.ycombinator.com