Quadrupling code performance with a "useless" if

mcv 2 hours ago | parent | next [-]

Interesting. I thought modern CPU optimisation required avoiding branches, but here adding the branch allows the branch pediction to parallelise what it otherwise couldn't.

	▲	zipy124 2 hours ago \| parent [-]
		It does and the key here is that adding the if is akin to avoiding a branch, since getting data then doing something with it is a hidden branch if you already have the data. All this code does is formalise the hidden branch so that it can be avoided when possible.

▲

throawayonthe 2 hours ago | parent | prev | next [-]

lobsters comment points out [[unlikely]] works here for clang

https://clang.godbolt.org/z/r4xYWfPfe

edit: oh the article also mentions it now :)

▲

anematode 4 hours ago | parent | prev | next [-]

Brilliant! Hadn't seen this technique before.

▲

anthonj 3 hours ago | parent | prev | next [-]

I think this call for something similar to "__builtin_expect" or linux' likely()/unlikely().

Not very clean, but better than inserting obscure optimisations in the source.

	▲	gblargg 3 hours ago \| parent \| next [-]
		Assuming compilers are smart enough to insert an unnecessary branch to break the dependency.
	▲	purplesyringa 3 hours ago \| parent \| prev \| next [-]
		That would be great, if only it worked as intended! From the perspective of an optimizing compiler, `a == b ? a : b` is worse than `b` regardless of the probability you assign to `a == b`. ETA: someone on Lobsters (https://lobste.rs/s/1an425/quadrupling_code_performance_with...) noticed that `[[unlikely]]` actually works on LLVM (not on GCC, and with worse codegen on LLVM, but it's still good to know) -- updated the post.
	▲	MaxBarraclough 3 hours ago \| parent \| prev [-]
		I was wondering the same thing. Also, could profile-guided optimisation help here?

▲

anirudhak47 4 hours ago | parent | prev | next [-]

latency optimization is a skill. I liked how you went till CSE pass. I myself wrote several passes to go to lowest latency possible

▲

akoboldfrying 4 hours ago | parent | prev | next [-]

This is really surprising! I've never considered the possibility that using an equality test to skip a write that would be a no-op could break a dependency and thus lead to higher perf overall if the "equal" outcome occurs often enough. This might be applicable in many situations where you "edit" some data in-place, but most of the time there are few or no changes.

▲

6510 an hour ago | parent | prev [-]

my js brain keeps thinking encoding[i] = next_j[i][j];