StringZilla

64 KB is a pretty significant budget for such a small operation. I've had a variant that uses 768 bytes with some extra logic, but will deprecate that kernel soon. https://github.com/ashvardanian/StringZilla/blob/0d47be212c5...

Aside from the NULL-termination requirements there is arguably another big design issue with libc strings. I believe the interfaces that may allocate memory - must give you an opportunity to override the allocator. Aside from the SIMD implementation quality and throughput on Arm, that was one of the key reasons to start a new library: https://github.com/ashvardanian/StringZilla/blob/91d0a1a02fa... Also not a huge fan of locale controls and wchar APIs :)

In the context of State Machines and Automatas - Intel HyperScan might be a better reference point. But the idea is the same. With a trivial PoC using Python wrappers over SIMD libraries one can get a 3x boost over the native `wc` CLI on a modern CPU, memory-mapping a very average SSD: https://github.com/ashvardanian/StringZilla/tree/main/cli

stringzilla[1] has 10x perf on some string operations - maybe they don't suck, but there's definitely room for improvement [1] - https://github.com/ashvardanian/StringZilla?tab=readme-ov-fi...

The 3.5x energy-efficiency gap between serial and SIMD code becomes even larger when A. you do byte-level processing instead of float words; B. you use embedded, IoT, and other low-energy devices. A few years ago I've compared Nvidia Jetson Xavier (long before the Orin release), Intel-based MacBook Pro with Core i9, and AVX-512 capable CPUs on substring search benchmarks. On Xavier one can quite easily disable/enable cores and reconfigure power usage. At peak I got to 4.2 GB/J which was an 8.3x improvement in inefficiency over LibC in substring search operations. The comparison table is still available in the older README: https://github.com/ashvardanian/StringZilla/tree/v2.0.2?tab=...

Thank you! There are still a lot of good first issues: https://github.com/ashvardanian/StringZilla/issues?q=is%3Ais...

Hi HN! I've spent the last few weeks optimizing the string operations in StringZilla. You'd be surprised how much performance GLibc and the Standard Templates Library of C++ are leaving on the table, especially on Arm and, likely, on RISC-V. I've significantly increased the number of implemented algorithms for different workloads. Searching across English texts on Arm, for example: - is 4.4x faster than STL, - and 16.8x faster in reverse order. The new version of the library now includes a C++ binding largely compatible with the C++ Standard, featuring all 17 overloads of the `replace` function. It also gained bindings for Rust and Swift. On the functionality side, it can now compute Levenshtein distances and Needleman-Wunsch alignment scores using AVX-512. It can generate random strings with a fair, uniform distribution without integer d

This is extremely timely! I was working on SIMD variants for collision-resistant rolling-hash variants in the last few weeks for the v3 release of the StringZilla library [1]. I have tried several 4-way and 8-way parallel variants using AVX-512 DQ instructions for 64-bit integer multiplications [2] as well as using integer FMA instructions on Arm NEON with 32-bit multiplications [3]. The latter needs a better mixing approach to be collision-resistant. So far I couldn't exceed 1 GB/s/core [4], so more research is needed. If you have any ideas - I am all ears! [1]: https://github.com/ashvardanian/StringZilla/blob/bc1869a8529... [2]: https://github.com/ashvardanian/StringZilla/blob/bc1869a8529... [3]: https://github.com/ashvardanian/StringZilla/blob/bc1869a8529... [4]: https://github.com/ashvardanian/StringZilla/tree/main-dev?ta...

The author is also responsible for the StringZilla library that includes levenstein distance: https://github.com/ashvardanian/StringZilla

A few things: Disk access can certainly be parallelized, and NVMe is blazing fast, so the bottleneck is more the CPU than disk. There are systems that are built around around modern hardware that realize this (redpanda.com, where I work is one such example) Parsing is a lot of the compute time and some SIMD tricks like SWAR for finding delimiters can be helpful. Stringzilla is a cool library if you want to see a clean implementation of these algorithms: https://github.com/ashvardanian/StringZilla See my reply here about the file being cached completely in memory after the first run: https://news.ycombinator.com/item?id=38864034