Turbo-Base64
streamvbyte
Turbo-Base64 | streamvbyte | |
---|---|---|
4 | 2 | |
253 | 357 | |
- | - | |
8.6 | 5.5 | |
9 months ago | about 1 month ago | |
C | C | |
GNU General Public License v3.0 only | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Turbo-Base64
-
Show HN: The fastest Turbo-Base64 now for Python
** Cython bindings for Turbo Base64 [1] **
- 20-30x faster than the standard library
- Benchmarks faster than any other C base64 library
- Fastest implementation of AVX, AVX2, and AVX512 base64 encoding
- No other dependencies
[1] - https://github.com/powturbo/Turbo-Base64
- Show HN: Turbo Base64 library. AVX512 Faster than memcpy and any other base64
- Iguana: fast SIMD-optimized decompression
- Show HN: Turbo Base64 the fastest base64 now more faster
streamvbyte
-
XZ: A Microcosm of the interactions in Open Source projects
Be direct and put the onus on the reporter/contributor to do more work before you will engage.
e.g., here is Daniel Lemire responding to a very open-ended bug report: https://github.com/lemire/streamvbyte/issues/72
There is something similar in customer service for my SaaS. Customers give horribly vague bug reports. I used to try to divine what they wanted. That way leads burnout. Instead, make them do more of the work.
-
Compress-a-Palooza: Unpacking 5 Billion Varints in only 4 Billion CPU Cycles
You're right, I used a lot of unsafe. I started with the implementation from the C source and then my main goal was to add a bounds-check without sacrificing performance. I got there by manually unrolling the inner loop a few times and then bounds checking only once per iteration of the outer loop. So instead of 1 bounds check for every 4 inputs, I have one every 16 or 32 inputs (with a correspondingly more conservative bounds check).
What are some alternatives?
sneller - World's fastest log analysis: λ + SQL + JSON + S3
sleef - SIMD Library for Evaluating Elementary Functions, vectorized libm and DFT
qs - Quick serialization of R objects
simde - Implementations of SIMD instruction sets for systems which don't natively support them.
aports - [MIRROR] Alpine packages build scripts
LittleIntPacker - C library to pack and unpack short arrays of integers as fast as possible
turbobase64 - Cython bindings for Turbo Base64
TurboPFor - Fastest Integer Compression
Turbo-Range-Coder - TurboRC - Fastest Range Coder + Arithmetic Coding / Fastest Asymmetric Numeral Systems
LZSSE - LZ77/LZSS designed for SSE based decompression
ClickHouse - ClickHouse® is a free analytics DBMS for big data