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. -- Stephen. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
