←back to thread

Branchless UTF-8 Encoding

(cceckman.com)
103 points vortex_ape | 1 comments | 17 Jan 25 19:20 UTC | HN request time: 0s | source
Show context
ThatGuyRaion ◴[17 Jan 25 19:40 UTC] No.42742391[source]▶
So is this potentially performance improving?.
replies(2): >>42742494 #>>42742719 #
PhilipRoman ◴[17 Jan 25 19:49 UTC] No.42742494[source]▶
Last time I tested branchless UTF-8 algorithms, I came to the conclusion that they only perform [slightly] better for text consisting of foreign multibyte characters. Unless you expect lots of such inputs on the hot path, just go with traditional algorithms instead. Even in the worst case the difference isn't that big.

Sometimes people fail to appreciate how insanely fast a predictable branch really is.

replies(1): >>42744257 #
1. dbcurtis ◴[17 Jan 25 23:16 UTC] No.42744257[source]▶
Pretty much. A strongly predicted branch is as fast as straight-line code, for most practical purposes (in modern processors). It is the mis-predicted branch that causes a pipeline flush and a re-fetch and so forth. The whole point of instructions like CMOV is to replace "flakey" branches with a CMOV so that you can execute both code paths and the test condition path all in parallel and grab the right answer at the end. This avoids paying the mis-predict penalty, and gives more time to compute the test condition, which for a branch is almost always only available awkwardly late in the pipeline. So as long as the compiler can do a decent job of identifying "flakey" branches up front for replacement with CMOV, it is a win. And many branches are easy for the compiler to classify. For instance -- if(SomeRareExceptionCondition) handle_exception(); -- for bonus points, move the exception handling code way the heck out to a different text page so that it isn't hanging around taking up I-cache space for no good reason.