Faster Base64 Encoding and Decoding Using AVX2 Instructions · HackerPapers discussions

Faster Base64 Encoding and Decoding Using AVX2 Instructions — mentioned by boomlinde

Wed, 06 Nov 2019 09:29:21 GMT

> Why is that an achievement? There are tables in the paper comparing its speed to other implementations. This is more than an order of magnitude faster than the implementation used in Chrome, and for small data more than twice as fast as their previous AVX2 based implementation (https://arxiv.org/abs/1704.00605). The paper even notes that in some cases, for large inputs, it's decoding base64 faster than you could memcpy the data for the simple reason that it needs only write 6/8ths of the bytes. In their tests, it's only when the data fits in the tiny L1 cache that memcpy is consistently…

Paper and discussion history. A mention is not an endorsement.

Faster Base64 Encoding and Decoding Using AVX2 Instructions — mentioned by taspeotis

Wed, 06 Nov 2019 06:50:27 GMT

The authors have been doing good work in this area for a while: https://arxiv.org/abs/1704.00605

Paper and discussion history. A mention is not an endorsement.

Faster Base64 Encoding and Decoding Using AVX2 Instructions — mentioned by dragontamer

Wed, 17 Jan 2018 22:04:11 GMT

https://arxiv.org/abs/1704.00605 In short, they spend roughly (EDIT: Herp-derp) 1/5th a cycle per byte of base64 through the use of AVX2 instructions to encode / decode base64. So one-cycle every 5 bytes. This includes robust error checking (allegedly) --------- Because SIMD-based execution was so successful in this example, I do wonder if a GPGPU implementation would be worthwhile. If some very big data were Base64-encoded / decoded (like MBs worth), then would it be worthwhile to spend a costly PCIe Transaction to transfer the data to the GPU and back? Something like an email-attachment is…

Paper and discussion history. A mention is not an endorsement.