Frequent cache misses (?) in decompression

[iam28th]

Currently decompression can be up to 2 times longer than compression, which is quite different from other tools - see Results.md

A typical fqcomp28 decompression flamegraph (obtained via vtune) looks like this:

...that is, almost all time is occupied by an FSE library function. Here is its call site:

fqcomp28/src/fse_sequence.cpp

Line 131 in 6bbc94b

const unsigned sym = FSE_decodeSymbol(states_.data() + ctx, &bitStream_);

The function is called inside the loop, which iterates over sequence positions, decodes a base at position i, then uses this base to update the context for decoding of the following base.

Source and assembly view of "FSE_decodeSymbol":

So according to vtune, most time is spent on the instruction movzx r9d, word ptr [rax], which is a memory access - which seem to suggest cache misses?

Intuitively it looks plausible, because we need to access a different "state" depending on which symbol was decoded, so the access pattern is complicated...
However, not sure why this issue is more dire in sequence decoding than in quality decoding.

I'll take a look at decompression profiles of other tools, and then on sequence algorithm used in fqzcomp5 -3 to maybe adapt it instead.

Any other suggestions are welcome.