Does all that stuff really wind up costing meaningful performance?
If you say:
while (i++)
if ( notWhitespace(chars[i]) && isDigit(chars[i]) )
doWork(chars[i])
speculative execution will give you near full performance when the input is clean, as long as you didn't write it in a way that invites mispredicts. You'll only suffer the cost of checking when your input is not clean.
That’s more elaborate than BM_Naive from the article, which takes over 10 times the time of their last version.
Reason? the next to last iteration of the code grabs 8 characters in an unsigned long, parses them, grabs 8 more characters, parses them, multiplies the first number by 100,000,000, and adds it to the second.
So, it does 2 iterations per 16-digit number, not 16.
The last result further improves on that by grabbing all 16 digits in one go.
Absolutely. Even with no other considerations, you're spending more ALU operations per character in that validation than the naive solution does for parsing. That probably won't drastically affect latency for a single parse if you don't have branch mispredictions and whatnot, but I'd be shocked if it didn't reduce throughput by 2x even for validation as simple as that.
Yes, so an effort to write an optimized version and benchmark it should include such checks (plus, of course, checking for reaching the end of the input).
If you say:
speculative execution will give you near full performance when the input is clean, as long as you didn't write it in a way that invites mispredicts. You'll only suffer the cost of checking when your input is not clean.