StringZilla
is-even
StringZilla | is-even | |
---|---|---|
14 | 27 | |
1,811 | 96 | |
- | - | |
9.8 | 0.0 | |
15 days ago | about 6 years ago | |
C++ | JavaScript | |
Apache License 2.0 | MIT License |
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.
StringZilla
-
Measuring energy usage: regular code vs. SIMD code
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=...
- Show HN: StringZilla v3 with C++, Rust, and Swift bindings, and AVX-512 and NEON
-
How fast is rolling Karp-Rabin hashing?
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...
-
4B If Statements
Jokes aside, lookup tables are a common technique to avoid costly operations. I was recently implementing one to avoid integer division. In my case I knew that the nominator and denominator were 8 bit unsigned integers, so I've replaced the division with 2 table lookups and 6 shifts and arithmetic operations [1]. The well known `libdivide` [2] does that for arbitrary 16, 32, and 64 bit integers, and it has precomputed magic numbers and lookup tables for all 16-bit integers in the same repo.
[1]: https://github.com/ashvardanian/StringZilla/blob/9f6ca3c6d3c...
-
Python, C, Assembly – Faster Cosine Similarity
That matches my experience, and goes beyond GCC and Clang. Between 2018 and 2020 I was giving a lot of lectures on this topic and we did a bunch of case studies with Intel on their older ICC and what later became the OneAPI.
Short story, unless you are doing trivial data-parallel operations, like in SimSIMD, compilers are practically useless. As a proof, I wrote what is now the StringZilla library (https://github.com/ashvardanian/stringzilla) and we've spent weeks with an Intel team, tuning the compiler, no result. So if you are processing a lot of strings, or variable-length coded data, like compression/decompression, hand-written SIMD kernels are pretty much unbeatable.
- Stringzilla: 10x Faster SIMD-accelerated String Class
-
Stringzilla: 10x faster SIMD-accelerated Python `str` class
Blog post
-
Stringzilla: Fastest string sort, search, split, and shuffle using SIMD
Copying my feedback from reddit[1], where I discussed it in the context of the `memchr` crate.[2]
I took a quick look at your library implementation and have some notes:
* It doesn't appear to query CPUID, so I imagine the only way it uses AVX2 on x86-64 is if the user compiles with that feature enabled explicitly. (Or uses something like [`x86-64-v3`](https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...).) The `memchr` crate doesn't need that. It will use AVX2 even if the program isn't compiled with AVX2 enabled so long as the current CPU supports it.
* Your substring routines have multiplicative worst case (that is, `O(m * n)`) running time. The `memchr` crate only uses SIMD for substring search for smallish needles. Otherwise it flips over to Two-Way with a SIMD prefilter. You'll be fine for short needles, but things could go very very badly for longer needles.
* It seems quite likely that your [confirmation step](https://github.com/ashvardanian/Stringzilla/blob/fab854dc4fd...) is going to absolutely kill performance for even semi-frequently occurring candidates. The [`memchr` crate utilizes information from the vector step to limit where and when it calls `memcmp`](https://github.com/BurntSushi/memchr/blob/46620054ff25b16d22...). Your code might do well in cases where matches are very rare. I took a quick peek at your benchmarks and don't see anything that obviously stresses this particular case. For substring search, the `memchr` crate uses a variant of the "[generic SIMD](http://0x80.pl/articles/simd-strfind.html#first-and-last)" algorithm. Basically, it takes two bytes from the needle, looks for positions where those occur and then attempts to check whether that position corresponds to a match. It looks like your technique uses the first 4 bytes. I suspect that might be overkill. (I did try using 3 bytes from the needle and found that it was a bit slower in some cases.) That is, two bytes is usually enough predictive power to lower the false positive rate enough. Of course, one can write pathological inputs that cause either one to do better than the other. (The `memchr` crat benchmark suite has a [collection of pathological inputs](https://github.com/BurntSushi/memchr/blob/46620054ff25b16d22...).)
It would actually be possible to hook Stringzilla up to `memchr`'s benchmark suite if you were interested. :-)
[1]: https://old.reddit.com/r/rust/comments/163ph8r/memchr_26_now...
[2]: https://github.com/BurntSushi/memchr
-
Show HN: Faking SIMD to Search and Sort Strings 5x Faster
I took a look at Stringzilla (https://github.com/ashvardanian/stringzilla), and in addition to the impressive benchmarks, the API looks pretty straightforward. It's a new star in my collection!
Thanks for open-sourcing this project!
is-even
-
4B If Statements
The actual implementation of this package is even better.
https://github.com/i-voted-for-trump/is-even/blob/master/ind...
- Hello World com 80mb
-
Oh no
But have you seen is-even?
- do not follow others
-
Hey devs , I am just learning React and I am facing an issue After Downloading And installing Nodejs I just made a react app by using npx create-react-app my-app in and it took 250mb in the project alone , Did I made a mistake as a result it downloaded extra files which took this much space
This has to be a joke, right?
-
Javascript libraries be like
Most funny thing is that it is using the: isOdd library (https://github.com/i-voted-for-trump/is-even/blob/master/index.js). Another miracle of human engineering.
- My college professors be like...
-
Why all the hate?
Micro-dependencies. There is no excuse for a module as tiny as left-pad, or any of the hundreds of modules spammed into NPM by this asshat ever. It's just fucking stupid.
-
When you spend hours coding something only to realize it already exists.
IsEven = !IsOdd
- Feel pain ye true mortals.
What are some alternatives?
usearch - Fast Open-Source Search & Clustering engine × for Vectors & 🔜 Strings × in C++, C, Python, JavaScript, Rust, Java, Objective-C, Swift, C#, GoLang, and Wolfram 🔍
npm-force-resolutions - Force npm to install a specific transitive dependency version
Simd - C++ image processing and machine learning library with using of SIMD: SSE, AVX, AVX-512, AMX for x86/x64, VMX(Altivec) and VSX(Power7) for PowerPC, NEON for ARM.
micromatch - Highly optimized wildcard and glob matching library. Faster, drop-in replacement to minimatch and multimatch. Used by square, webpack, babel core, yarn, jest, ract-native, taro, bulma, browser-sync, stylelint, nyc, ava, and many others! Follow micromatch's author: https://github.com/jonschlinkert
aho-corasick - A fast implementation of Aho-Corasick in Rust.
is-odd - I created this in 2014, the year I learned how to program. All of the downloads are from an old version of https://github.com/micromatch/micromatch. I've done a few other things since: https://github.com/jonschlinkert.
rust-memchr - Optimized string search routines for Rust.
enquirer - Stylish, intuitive and user-friendly prompts, for Node.js. Used by eslint, webpack, yarn, pm2, pnpm, RedwoodJS, FactorJS, salesforce, Cypress, Google Lighthouse, Generate, tencent cloudbase, lint-staged, gluegun, hygen, hardhat, AWS Amplify, GitHub Actions Toolkit, @airbnb/nimbus, and many others! Please follow Enquirer's author: https://github.com/jonschlinkert
popular-baby-names - 1, 000 most popular names for baby boys and girls in CSV and JSON formats. Generator written in Python.
isEvenAPI - :seven: API Wrapper for isEven. Check is a integer is even or odd.
rebar - A biased barometer for gauging the relative speed of some regex engines on a curated set of tasks.
cache-base - Basic object store with methods like get/set/extend/omit