You went too hardcore. This is what I'm assuming:

- generate EC starting pubkeys according to how many threads will run and the size of the range to scan
- copy them to GPU memory
- scan the range (one or more kernel calls), mark matching prefixes above XX bits (XX depends on range size)
- extract results after each run; maybe break earlier from finishing scanning the range if we are lucky (don't make all the kernel calls to finish the range)

Now, depending on the results, instead of continuing scanning the NEXT range, advance more or less, by skipping some number of ranges.

Generating the starting keys for some range is like 0.001% of the entire running time, it's not an issue. Also, it can be optimized with some constant jump offsets, if we always start with an aligned subrange (for example, aligned to 40 bits).

Just my 2 cents. Maybe WP scanned a lot and get lucky, he knows better why he did that.