Hm, I assume that if it were longer strings such that the branch is always predicted taken, that yeah it wouldn't speculate to the next string until the mispred

Hm, I assume that if it were longer strings such that the branch is always predicted taken, that yeah it wouldn't speculate to the next string until the mispredict is found, which won't happen until the data gets into registers. If, on the other hand, you had Pascal-style strings with a known length up front instead of null-terminated strings, then the mispredict could be resolved independently of loading every byte of the string, and it could have outstanding loads for two strings simultaneously. But only for strings that span more than one cacheline. The only limit for speculation is the OoOE buffers. I abbreviated it, but the inner loop is a minimum of 5 µops, so you actually end up hitting the ROB limit at 39 iterations before the store buffer is full. Though some architectures could reduce it to 4 with a compare+branch instruction. (x86 fuses this sequence to one µop but I'm not sure if it reduces the ROB entries) If you don't hit the ROB limit, then even after you hit the store buffer limit, the load buffer can take some loads. So assuming 4 µops, 42 stores and 48 loads would be actively buffered while their cache misses are resolved. There's no public documentation on what modern CPUs actually do for branch prediction; that's why I said "likely" - I'm not claiming that any specific CPU does precisely what I described. Just that it's likely to be better than "predict the branch as always taken." The more general "hash pc history as input to branch prediction" is a better way to look at it. How it's hashed and used is a trade secret. Actually, thinking about it again, for truly random data the only prediction improvement over "always taken" is predicting the 32nd consecutive inner branch as not taken. Predicting not taken before that increases the mispredict rate...