And while your comments on DEC-10 and 6-bit bytes might be interesting, there are very few people still working in CS who have seen a DEC-10 outside a museum. I find it always interesting to learn about computers that were obsolete before I wrote my first program, but their performance characteristics were vastly different than what we have today. And current college grads have always lived in a world with 64-bit SIMD machines that can do a scalar multiply in 3-4 cycles.
If you need to parse integers so quickly, why are you storing them as decimal strings?
If you're dealing with a massive CSV why not just compile to a more easily parsable format ahead of time?
The article mentions 0.8gb/s to 1.8gb/s throughput.
If youre downloading something off the internet, the bottleneck isn't going to be converting the strings to ints.
Further if you're downloading that much data, it suggests even more that you should be using a more space efficient representation.
We cannot really accomplish much by telling a bunch of other companies to change the format they use to send data to all of their customers.
I don't know this is faster than simply doing the "mutiply by ten and add" sequence. I'd have to understand modern ALU behaviour, parallelism, shortcuts, chip cache dynamics you-name-it.
It would all have been so much simpler if we'd made decimal be hex instead. Octal doesn't work as well for me, no idea why. That said, it's much easier to ignore thumbs and count on 4 fingers of each hand than grow another 6
(I read the article. It descended into arcanum of instruction sets and assumptions which post date my DEC-10 ISA lessons, although I recall Digital had BCD instruction handling and a 6 bit byte model in a 36 bit word accordingly. DEC-10 instructions could take many, many clock cycles and have 5 components of from, to, via, because, maybe attached to them)