Amos Jeffries wrote:
On 6/04/20 12:57 pm, Stephen R. van den Berg wrote:
You mean because it will cost an extra clockcycle on decode per character? That will only be relevant for very large sequences of base64 characters.
How are you defining "large" here?
Base64 data inputs can be any size. Megabytes are not uncommon in network messaging.
That's what I meant.
And the sequences are that large, the speed to decode becomes RAM-access bound; in which case there will be plenty of spare CPU cycles. This essentially makes the extra "if" cost-free.
For this type of situation we should expect the L1/L2 cache lines to be loaded by the time they are needed. Delays will most likely be from interruptions to the decode thread, or less likely; code or table size causing swapouts from the L1/L2 caches.
Ok, I stand corrected. I just checked the RAM subsystem speeds of current systems, and I find that 250GB/s is not uncommon. In that case, every extra clockcycle will hurt. I'll retract the tablesize optimisation.