Ragnar {Groot Koerkamp} @curiouscoding.nl · Dec 21 Screenshot from movi2 paper. Size-wise ropebwt is already competitive, but I don't really get why it's _this_ much slower? Traversing a Btree ought to only be a bit slower than reading the relevant cacheline directly. Looks like the diff is more than just batching.
1 likes 3 replies
Replies
4000reads/s * 2.6kbp reads = 10Mbp/s => 100ns/bp / (1.3 cache miss/bp) = 77ns/cache miss. That's exactly the *latency* of a cache miss, but movi2 is already supposed to do batching (multiple 'strands'), which should be able to get around 7.5ns/cache line throughput, ie 10x more. Is it CPU bound???
Side note: space/time axes have no business not starting at 0. We care about relative improvements and those can only be judged with proper axes. If this makes the speedup appear to be insignificant, then that's probably the case anyway. 1/
This plot compares SMEM from ropebwt3 and PML from movi. Ropebwt3 and movi don't support the same query type. It is hard to do an apple-to-apple comparison, but movi is indeed a lot faster.