Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upencoding/base64: decoding is slow #19636
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gopherbot
commented
Mar 21, 2017
|
CL https://golang.org/cl/34950 mentions this issue. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
dgryski
Mar 21, 2017
Contributor
Also https://github.com/powturbo/TurboBase64 for a fast encoder/decoder that doesn't need assembly.
|
Also https://github.com/powturbo/TurboBase64 for a fast encoder/decoder that doesn't need assembly. |
ALTree
changed the title from
encoding/base64 decoding is slow
to
encoding/base64: decoding is slow
Mar 21, 2017
ALTree
added
the
Performance
label
Mar 21, 2017
bradfitz
added this to the Go1.9Maybe milestone
Mar 21, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gopherbot
commented
Mar 24, 2017
|
CL https://golang.org/cl/38632 mentions this issue. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
josselin-c
Mar 24, 2017
Contributor
@dgryski I saw such LUT based and I'm wondering if it's acceptable. What's go philosophy about embedding "large" LUT? Won't such tables trash the L1 when used and penalize the rest of the application?
I have an SSE implementation in the pipe that will be another improvement to CL 38632 but it's limited to amd64.
|
@dgryski I saw such LUT based and I'm wondering if it's acceptable. What's go philosophy about embedding "large" LUT? Won't such tables trash the L1 when used and penalize the rest of the application? |
pushed a commit
that referenced
this issue
Apr 24, 2017
bradfitz
modified the milestones:
Go1.10,
Go1.9Maybe
May 24, 2017
pushed a commit
that referenced
this issue
Oct 9, 2017
bradfitz
modified the milestones:
Go1.10,
Go1.11
Nov 15, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
powturbo
Feb 6, 2018
@josselin-c: I saw such LUT based and I'm wondering if it's acceptable.
Strange rumours, but the short scalar "turbob64encs" encoding uses 64 bytes and the "turbob64decs" decoding function just uses 80 bytes (from 256 bytes LUT) delivering 2 GB/s in practical szenarios, This is less memory than other SIMD/AVX2 base64 functions. The fast "turbob64dec" function needs in fact less than 1k and is decoding faster than other scalar/SSE functions. See benchmark: TurboBabse64
powturbo
commented
Feb 6, 2018
•
Strange rumours, but the short scalar "turbob64encs" encoding uses 64 bytes and the "turbob64decs" decoding function just uses 80 bytes (from 256 bytes LUT) delivering 2 GB/s in practical szenarios, This is less memory than other SIMD/AVX2 base64 functions. The fast "turbob64dec" function needs in fact less than 1k and is decoding faster than other scalar/SSE functions. See benchmark: TurboBabse64 |
added a commit
to Quasilyte/kfu-go-2018
that referenced
this issue
Apr 1, 2018
bradfitz
modified the milestones:
Go1.11,
Unplanned
May 18, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
gopherbot
May 18, 2018
Change https://golang.org/cl/113776 mentions this issue: encoding/base64: slight decoding speed-up
gopherbot
commented
May 18, 2018
|
Change https://golang.org/cl/113776 mentions this issue: |
josselin-c commentedMar 21, 2017
What version of Go are you using (
go version)?Go 1.8
What operating system and processor architecture are you using (
go env)?amd64
What did you do?
On my slow computer, using encoding/base64, I can decode data at ~100MB/s.
It should be much faster as shown by https://github.com/aklomp/base64
I'm planning to work on this in my spare time. This issue tracks this effort.