Hacker News Reader

Comment by ars | Hacker News Reader

Except that this is intended to make things faster, but actually makes things slower.

If it had some other purpose, and a slight slowness was a side effect, then OK. But when the entire purpose is reversed that's a problem.

View on HN

I agree that it's a bug and should be fixed. I just don't agree with the implication of the title that it's a super huge deal. I mean, all we're doing is swapping out mov for push and leave. The functionality is completely unaffected, and the slowdown is so minor that no one would ever notice without running a ridiculous microbenchmark.

Fix the bug, but don't make a mountain out of a mole hill.

Where does it say anything about functionality? It just says fatter and slower, and that's exactly correct.

I don't see any mountain either. Are you reading some emotional context I'm missing?

In most cases it should make it faster. Any type of optimization is kind of a tricky thing because you can't predict what the user is going to do in the field. Take sorting algorithms, for example. Quicksort can degenerate to O(n^2) if you lay your elements to be sorted out in a specific order which will always have bad pivots. I'm not sure if you are familiar with C and x86 assembly, but the test harness code was linked to in the article. It is a contrived example specifically designed to beat gcc's optimization.

I take it you've not been around for very long, yeah?

GCC has had way worse than this before. You should've been there for the great 2.95 -> 3.0 switch.

That was comical.

This is a pretty minor flub compared to the other non-optimizing "optimizations" that GCC has.

Reply on news.ycombinator.com