The BWT (Burrows Wheeler Transform) has long fascinated people for its ability to capture complex correlations with
a very simple inverse transform. Unfortunately despite that inverse transform being very simple, it is also slow.
I will briefly review the inverse BWT (i-BWT) and then look at ways to speed it up.
Jump to the end for the punch line : speed results and source code.
Let's briefly review the basic BWT to establish the baseline algorithm and notation.
Given an input string like "inputstring" add an EOF symbol so S = "inputstring|" then form all rotations :
inputstring|
nputstring|i
putstring|in
utstring|inp
tstring|inpu
string|input
tring|inputs
ring|inputst
ing|inputstr
ng|inputstri
g|inputstrin
|inputstring
Then sort all the rows, this gives the matrix M :
g|inputstrin
ing|inputstr
inputstring|
ng|inputstri
nputstring|i
putstring|in
ring|inputst
string|input
tring|inputs
tstring|inpu
utstring|inp
|inputstring
^ ^
F L
this is all the suffixes of the file, and we've sorted them all. We've labeled the first column F
and the last column L.
The last column L is the BWT, which is what we transmit. (typically we don't transmit the EOF character,
instead we transmit its location and leave it out of the BWT string that is sent).
In the matrix M each column is a permutation of the original string S (remember the rows are cyclic rotations).
The first column F is just the
alphabetic sort of S. F can obviously be reconstructed from a histogram of S, which can be counted from L.
The column L is the original characters of S in order of their following suffixes.
The inverse transform is simple conceptually. We transmit L, the BWT string (the last column), we need to
regenerate S the top row.
Because the rows are all just rotations of S, the character at F[i] on each row is the character that
follows L[i]. This gives you an answer to "what's the next character after this one?" which is all you
need :
Output decoded string D
Start with D=| the EOF character.
What's the next character?
L = nr|iinttsupg
F = giinnprsttu|
Find | in L , it's L[2]
so the next char is F[2] = i
D=|i
What's the next character?
Find i in L , it's L[4] (NOT L[3])
so the next char is F[4] = n
D=|in
Then find n at L[5] (not L[0])
the next char is p, so D=|inp
after p is u, etc.
So you can just read out the characters one by one like that.
When a character occured multiple times in L we had to find the right one (which corresponds to the
same location of that character in the original string S). eg. when finding 'i' we needed L[4] not L[3]
because L[4] is the i that follows | in "input", while L[3] is the i in "string".
The way to do that is to find the same occurance number of that character. If it's the 2nd "i" in F, we want
that to map to the 2nd "i" in L.
The reason is because L has the characters sorted by their suffixes, while F is sorted by the whole strings.
So when they are the same symbol in L, then the order they occur in L is the same as the order the occur in F.
For example the n's in F :
ng|inputstri
nputstring|i
are in this order because "ng" is less than "np"; in the last column L, the n's occur as :
g|inputstrin
putstring|in
they are sorted by their suffixes "g|" and "pu", so they are in the same order.
So the nth occurance of each character in L/F corresponds to the nth occurance of each character in L/F.
The main thing we need for inversion is this mapping between L and F for each character.
It turns out to be more convenient to go backwards and make the mapping from L to F (rather than F to L).
This is because the F array can just be implicit, we never need to make it in memory. F is just the "cum prob"
table. That is :
Each symbol has a histogram count[s]
start[s] = prefix sum of counts < s
cumulative probability range[s] = [ start[s] , start[s] + count[s] )
(closed interval on low end, open interval on high end)
F[] = fill s in range[s]
To find the nth occurance of s in F[] is just i = start[s] + n
This is the same array you would use in arithmetic coding or RANS.
We'll calling the mapping from L to F , LF[] and it is just constructed thusly :
scan L[]
s = L[i]
count C[s] as you go (start at zero)
find the C[s]th occurance of s in F[]
LF[i] = start[s] + C[s]
then C[s] ++
Now LF[i] takes us from the symbol at L[i] to the same symbol in F[] which will be at F[ LF[i] ], then from
there you can step to the prior symbol, which is at L[ LF[i] ].
Note that this is backwards from what we were doing before, so we are now reading at the stream in
reverse. To read out the i-BWT (backwards) is now : :
start at i = location of EOF in L[]
for N times :
{
find symbol L[i] in F[] ; this is i = LF[i]
then step to the prior symbol F -> L
output L[i]
}
that's it! A full BWT inverse transform is then :
L[] = the BWT string, we get this from the decoder
count[i] = histogram of L[]
start[i] = prefix sum of count[]
make LF :
C[] = 0
for i to N
{
s = L[i];
LF[i] = start[s] + C[s];
C[s]++;
}
read out :
i = index of EOF (transmitted)
// L[i] is EOF sym which we don't need to output
for N times
{
i = LF[i];
*ptr++ = L[i];
}
This produces the string backwards, which we usually handle by reversing in the encoder before doing the
BWT so that the decoder can just output forwards.
That's it!
I'm not going to talk about how the compressor transmits the BWT string L[] compactly. See the original BW94 paper
or the bzip code for the classic MTF + RLE + switching Huffmans encoding. See Fenwick for analysis of BWT
as a symbol ranker. In the modern world most people do BWT encoding without MTF; see Maniscalco M99,
context induction, BCM and BBB.
I'm also not talking about the forward transform at all. The forward transform also has interesting
efficiency issues, mainly also relating to cache misses for large buffers or to GPU implementations,
and there has been lots of good research on that; see the papers. In this blog I will assume you don't care much about forward
transform speed, so I'll push all the slow operations to the encoder side to make the decoder as fast as
possible.
I will also just briefly mention that BWT of long string recurrances can be sped up with an LZP pre-pass. We will
assume this has been done where appropriate so that there are no very long identical strings in our
source input (eg. perhaps suffixes are always unique after 16 symbols).
End of review and we'll dive into speeding up the i-BWT.
So the transform is delightfully simple, but it's slow. Why?
(and by "slow" I mean *really* slow; specifically 200-400 cycles per iteration on my Intel machine "beasty")
The problem is that each instruction of the i-BWT intrinsically depends on the previous instruction (instrinsically meaning
can't be removed with code reorganization), so no instruction-level-parallelism (ILP) can be used. On modern CPUs that
might be able to do 4 instructions per clock this is bad. What's worse is that there is an intrinsic cache miss in the
lookup step of the i-BWT.
The problem is the index of the next symbol in the sequence is semi-random and goes all over the BWT buffer. It cache misses
often (almost every single iteration). Now you can obviously fix this by making the BWT chunk smaller, which is what the old bzip does.
If the chunk is small enough to fit in cache, no problem. But that also kills compression and sort of ruins the whole point
of the BWT (if small chunk BWT compression is good enough for you, then you should just use an LZ like Kraken which better
fits that space-speed niche; high speed small cache is outside the operating range of where BWT makes sense vs alternatives).
In-cache BWT is not a Pareto optimal way to do a fast compressor; we are only interested in BWT in the high-compression domain.
So we want to use BWT chunk sizes that are bigger than the fast cache (16M chunks perhaps, which often fits in L3) and speed
things up.
The core of the i-BWT is just this :
for N times
{
i = LF[i];
*ptr++ = L[i];
}
The problem is the LF[i] are a near-random walk around the buffer.
They are in order of the sorted suffixes, which tend to be completely randomly
distributed in N, assuming the input array is not in some degenerate pre-sorted order.
You load at LF[i] and it cache misses, you can't do any more work, the loop completely stalls. As soon
as the cache miss returns, you immediately do i = LF[i] and look up at LF[i] again and stall again.
Now one obvious thing we can do is to first combine the L[] and LF[] arrays into a single merged array, so that we get
exactly 1 cache missing load per iteration instead of 2. But we still need fundamental improvements.
There are two big deficiencies we need to address :
1. Instruction sequence with sequential dependencies
2. Cache miss on looking up the next symbol
The most obvious approach to deal with these deficiencies is to use a technique we are now familiar with, which is
to do multiple streams at the same time.
Independent multiple streams allow you to keep more execution units busy, especially in a case like this where there
is a fundamental cache miss stall that you want to fill with useful CPU work during those cycles.
Say you have a single execution stream where every instruction is dependent on the last (c follows b follows a),
only 1 can execute per cycle, and if one cache misses you get unused cycles with no work to do :
clock tick on the left
"1" is the independent stream number
a,b,c indicate a sequence of dependent instructions
0: 1a
1: 1b
2: 1c (cache miss)
3: .
4: .
5: .
6: .
7: 1d
If you run 4 streams of independent work, each stream dependent on the last instruction within its stream but no
cross-stream dependencies, now the CPU can execute 2 instructions per cycle (say), and fill in during the cache miss :
0: 1a + 2a
1: 1b + 2b
2: 1c + 2c (both cache miss)
3: 3a + 4a
4: 3b + 4b
5: 3c + 4c (both cache miss)
6: .
7: 1d + 2d
It's a bit like what hyper-threading does for you, but we get it just by running more independent execution sequences
on our single thread to give the out-of-order execution a bigger selection of work to find instructions to fill the gaps.
In our case with heavy cache missing dependent work, in the 1-stream case you are waiting on the latency of
each cache miss with the processor doing nothing, so you get a full stall all that time. Going to more streams
at least lets us get multiple memory operations pending at once, rather than stall, wake up, stall again on one
load at a time.
In the case of i-BWT we can do this by taking the input data (before BWT) and think of it as T segments. We don't cut
the string into pieces (remember chunking hurts compression and we don't want to do that), we still do the forward BWT
on the whole string.
Like :
"inputstring|"
in 2 segments :
input+string|
do the BWT on the whole string "inputstring|"
then find the locations of the EOF symbol | in L[]
and the + segment boundary, by finding where "string|" starts
g|inputstrin
ing|inputstr
inputstring| <- EOF key
ng|inputstri
nputstring|i
putstring|in
ring|inputst
string|input <- segment key
tring|inputs
tstring|inpu
utstring|inp
|inputstring
^ ^
F L
EOF key = 2
segment key = 7
Then you would transmit the BWT string L[] and the EOF key (2) as usual, and also transmit the segment key (7).
The segment key lets you start the i-BWT core loop at that location and read out characters from there, in addition
to the stream from the EOF key.
In the i-BWT you can start output cursors for all T segments and you can read them out of the i-BWT simultaneously.
The i-BWT core loop just does "from this symbol, what's the next symbol?" so you can do T of those independently.
1->..+2->...|
cursor 1 starts at i=2 in L[]
cursor 2 starts at i=7 in L[]
decodes:
i....+s.....|
in...+st....|
etc..
input+string|
The N-stream decode is very simple, literally just doing the 1-stream process to N output pointers :
T segments
key[T] are the start indexes
i1,i2,etc. = key[]
ptr1 = start of output buffer
ptr2 = ptr1 + (N/T) , start of next segment, etc.
for N/T times
{
i1 = LF[i1];
*ptr1++ = L[i1];
i2 = LF[i2];
*ptr2++ = L[i2];
}
it just does the basic i-BWT loop on T segments in each iteration. Crucially these are independent, so when one of them
stalls on a cache miss, the others can still do work. If all of them were stalling on cache misses and the memory
system could service T cache line fetches simultaneously, we would be able to stall with all T requests in flight which
would give us factor of T speedup. In practice it appears to be somewhat less than that.
You can also cut into segments like this for parallel decoding on multiple threads for very large blocks (without doing any
chunking, which sacrifices compression). eg. you might find 16 segments to decode and give 4 segments each to 4 threads.
The threads have no cache contention because they are writing linearly to different output segments, and the shared memory
of the LF[] array is read-only in this loop.
Going to 4 streams provides around a 2.7X speedup, 8 streams gets us about 4X :
enwik7 :
ibwt_1x1 : seconds:0.7500 | cycles per: 299.330 | MB/s : 13.33
ibwt_1x4 : seconds:0.2801 | cycles per: 111.769 | MB/s : 35.71
ibwt_1x8 : seconds:0.1835 | cycles per: 73.218 | MB/s : 54.51
(see more speeds at end)
The next thing we can do is an idea from the paper "Cache Friendly Burrows-Wheeler Inversion".
We can make our basic i-BWT step output words or dwords instead of bytes.
This is a simple idea, but I think it's quite interesting *why* and *when* it works.
What we want to do is just do our core i-BWT to output words at a time instead of bytes, by outputting
a precomputed pair of one byte steps :
core i-BWT loop for words :
i = key (EOF location in L[])
for N/2 times
{
*word_ptr++ = LL[i];
i = LF2[i];
}
where LL = a word, two steps of L[] , and LF2[] = two steps of LF[],
that is LF2[i] = LF[LF[i]].
(reminder that in practice we put the LL[] and LF2[] into a single struct so that we get one cache miss
array lookup rather than two).
So to use that we just need to build the LL and LF2 arrays first. To do that we just need to precompute
each pair of steps in the byte-at-a-time BWT :
prep for word i-BWT :
first build LF[] as usual
for i = 0 to N
{
int i2 = LF[i];
LL[i] = L[i] | (L[i2]<<8);
LF2[i] = LF[i2];
}
At every index in L[] we precompute a two-character step by following LF[] once.
(side note : you could precompute a two-character step forward more simply; from L[i] the next character is just F[i],
which you could get from the cumulative probability table at i, but that would give you a step forward and what
we want is a step backward; L[i2] here is the character that precedes L[i]; it wouldn't help because we
need a lookup at i2 to make LF2[] anyway)
Now at first glance this might not seem helpful, what we have done is transform :
byte at-a-time BWT :
core i-BWT loop :
N times :
i <- LF[i]
output byte from i
word at-a-time BWT :
prep :
N times :
LF2[i] = LF[LF[i]]
word = L[i] + L[LF[i]]
N/2 times :
i <- LF2[i]
output word from i
We are actually doing more work; we now do 3/2 N iterations instead of N iterations.
But it is in fact much faster.
Why?
The reason is that the N-step "prep" loop to build LF2 does not have the two big problems of the
core loop. Remember the two big issues :
1. Instruction sequence with sequential dependencies
2. Cache miss on looking up the next symbol
these are what make the "core" i-BWT loop so slow.
First issue #1 : the "prep" loop naively allows for execution ahead, unlike the core loop. The reason
is that it is just doing i++ to iterate the loop, rather than chasing i = LF[i] around a data-dependent
serpentine walk through the arrays. This means that the processor can effectively unroll the loop to execute
ahead :
prep loop :
iter 1 :
LF2[i] = LF[LF[i]]
word = L[i] + L[LF[i]]
i++;
iter 2 :
LF2[i] = LF[LF[i]]
word = L[i] + L[LF[i]]
i++;
iter 1 and iter 2 can run at the same time because i++ can be precomputed.
If LF[LF[i]] stalls on a cache miss in iter 1, iter 2 can still proceed.
core loop :
iter 1 :
i = LF[i]
output byte/word from i
iter 2 :
i = LF[i]
output byte/word from i
iter 2 can't start until iter 1 is done because we don't know "i" until the
results of the lookup at LF[i] are done.
A modern processor will be able to execute ahead in the "prep" loop to fully saturate
execution, and we don't need to manually do the N-streams to get ILP because it just
naturally exists.
issue #2: cache misses. The "prep" loop cache misses far less than the "core" loop.
Again this is not naively obvious. The byte "core" loop does N lookups at LF[i]. The "prep" loop
also does N lookups at LF[i]. So they should cache miss the same, right?
Nope. The difference is because the "core" loop is doing i = LF[i] which takes you to a semi-random
place each time, whereas the "prep" loop is doing i++ for subsequent lookups, and that means the
lookups are often to nearby locations that stay in cache.
core loop does :
starting from i
i1 = LF[i]
lookup at i1
i2 = LF[i1]
lookup at i2
i3 = LF[i2]
lookup at i3
prep loop does :
starting from i
i1 = LF[i]
lookup at i1
i2 = LF[i+1]
lookup at i2
i3 = LF[i+2]
lookup at i3
The indexes i1,i2,i3 in the core loop are semi-random, in the prep loop they are not.
To understand, let's remember what LF[] is. It takes us from the symbol at L[i] to the location of
the preceding symbol in the BWT (we're outputting backwards).
So say you were currently at "ing|" (in "inputstring|"), it takes you to the location of "ring|" then
"tring|" ; those are i1,i2,i3 in the core loop.
In the "prep" loop you are taking the starting strings at i, i+1, i+2. These are subsequent in sorted
order. These might be something like :
"hella ..."
"hellish a.."
"hellish b.."
"hello a..."
"hello b..."
So the steps LF[] gives us to i1,i2,i3 will be to tack on the preceding character and look that up.
They might all be preceded by random characters, but in practice because these strings are similar
their preceding characters tend to be similar. That might be :
" hella ..."
" hellish a.."
"shellish b.."
" hello a..."
"shello b..."
then you look up those locations in the suffix sort. As long as you tacked on the same preceding
character, they will stay adjacent :
" hella ..." -> i =4000
" hellish a.." -> i = 4001
"shellish b.." -> i = 6078
" hello a..." -> i = 4002
"shello b..." -> i = 6079
The preceding character for the sorted suffixes is of course just the BWT string L[] itself. The
portion here would be " s s".
So as long as the BWT string has repeated characters, the indexes of the "prep" loop lookup will be
adjacent. If they are adjacent indexes, they will not cache miss because we already loaded their
neighbor which brought in that cache line (load at i=4001 won't cache miss because we just did a load at i=4000).
Well, getting repeated characters in L[] is exactly what the BWT gives us! If we think of it in terms of post-MTF
BWT strings, a 0 will be a load from the most likely location, 1 will be the second most likely, etc. so
there will tend to be a few cache lines that we already have that provide most of our loads for the "prep"
loop. Only rarely do you get unexpected characters that cause cache misses.
Note that this only works on *compressible* data where the BWT is giving the coherence we want. On random
data that doesn't compress this breaks down. (though even in that case, there are still at most 256 hot cache
lines = 16 KB that we need to read from, so it's still better than the "core" loop, and we still have property
#1 that each iteration is independent).
Actual load locations so you can see how this works in practice :
LF[i] = 8853
LF[i] = 8854
LF[i] = 8855
LF[i] = 8856
LF[i] = 10553
LF[i] = 8857
LF[i] = 10554
LF[i] = 48
LF[i] = 49
LF[i] = 50
LF[i] = 10555
LF[i] = 10556
LF[i] = 51
LF[i] = 52
LF[i] = 5070
LF[i] = 10557
LF[i] = 2477
LF[i] = 53
LF[i] = 54
Where you have 10553,10554,10555 that means the same character was preceding those suffixes, so they lookup
in adjacent places.
You can of course take this idea for word output and repeat it again to get dword (u32) output per iteration.
In practice what I see is that dword output is only faster for compressible data where the cache coherence
property above works well. On random input dword output gets a lot slower than word-at-a-time. Because of
this I think word output is best if you only choose one i-BWT,
but you can do even better by adaptively choosing the output algorithm by the compression ratio.
The dword (4x) variant does an N-loop to build LF2 which is quite coherent, the next N-loop to build LF4 is
slightly less coherent unless the data is compressible (we're relying on two-symbols-away correlation now
instead of neighbor correlation, which is less strong), then it does N/4 of the "core" loop which is still quite
cache missy. So the net is :
!
1x byte loop : N steps of "core" , cache mising
2x word loop : N steps of LF2 + (N/2) steps of core
4x word loop : N steps of LF2 + N steps of LF4 + (N/4) steps of core
The authors of "Cache Friendly Burrows-Wheeler Inversion" have another method that accelerates long repeated
substrings called "precopy". I think that a pre-pass with an LZP transform is probably a faster to way to accomplish the same
thing on data where that is helpful. "precopy" also makes N-stream interleaving much more complex. I have not
tested it.
Speeds measured on my Intel Core i7 3770 (locked at 3403 MHz) (Ivy Bridge)
ibwt 1x1 = classic byte at a time inverse BWT
ibwt 1x4 = byte x 4 streams
ibwt 2x4 = word x 4 streams
ibwt 4x4 = dword x 4 streams
ibwt 1x8 = byte x 8 streams
ibwt 2x8 = word x 8 streams
ibwt 4x8 = dword x 8 streams
cycles per byte for the ibwt :
| name | 1x1 | 1x4 | 2x4 | 4x4 |
| dickens | 350.6 | 123.7 | 70.0 | 47.9 |
| enwik7 | 301.2 | 116.0 | 66.8 | 47.0 |
| webster | 376.9 | 139.0 | 78.5 | 51.2 |
| lzt99 | 211.3 | 114.6 | 65.1 | 61.4 |
| rand_16M | 401.6 | 130.6 | 80.4 | 297.3 |
|
| name | 1x1 | 1x8 | 2x8 | 4x8 |
| dickens | 337.0 | 79.8 | 46.8 | 35.8 |
| enwik7 | 299.1 | 73.2 | 46.0 | 36.1 |
| webster | 376.5 | 98.0 | 57.5 | 40.3 |
| lzt99 | 208.6 | 77.9 | 48.1 | 53.7 |
| rand_16M | 401.3 | 84.1 | 55.0 | 273.4 |
|
We've improved the i-BWT speed from around 300 cycles/byte to 50 cycles/byte. That's still extremely slow. It's around the speed of Oodle LZNA (30 cycles/bytes) or 7z LZMA (70 cycles/byte).
It's an order of magnitude slower than Oodle Leviathan (5 cycles/byte). But in some cases, such as text, BWT on large blocks gets a lot more compression than those, so it
could be interesting on the right data types if you care about the very high compression domain.
All speeds single threaded.
The i-BWT on a small buffer that stays in cache is around 10 cycles/byte (and could probably be faster; we haven't looked
at all at micro-optimizing the actual instructions here, since if we're stalling on cache misses they don't matter),
so at 50 cycles/byte we're still spending 40 cycles/byte stalled on
the memory subsystem in our best algorithm, which is not great.
ADD : with MEM_LARGE_PAGES :
| name | 1x1 | 1x8 | 2x8 | 4x8 |
| dickens | 301.3 | 52.4 | 33.9 | 27.7 |
| enwik7 | 265.8 | 50.5 | 33.1 | 28.2 |
| webster | 319.6 | 54.5 | 34.8 | 29.0 |
| lzt99 | 177.5 | 50.6 | 32.5 | 35.6 |
| rand_16M | 336.6 | 53.5 | 41.4 | 154.1 |
|
Without large pages, the bottleneck appears to be in TLB/page mapping. With large pages it seems to be limited by the rate that cache missing reads can be retired (assuming the latency of that is fixed, this is the number of different cache lines that can have in-flight reads simultaneously). eg. if latency is 300 cycles, with 10 simultaneous reads we could get to 30 cycles/byte.
Downloads :
fast_ibwt_test.cpp
fast_ibwt_test exe (Win x64)
The source code is public domain.
The ibwt routines are standard C. The test driver uses
cblib