Comments (5)
Unfortunately it seems the situation with this library is rather limited on non-x86 anyway
That's why I asked. I figured you might be asking for something that probably doesn't solve your actual problem all on its own. But yes, this is mentioned in the README. The README only discusses x86.
I guess this is yet another crate I will have to roll my own of.
There are SWAR oriented routines of memchr2
in this crate that are platform independent. Those aren't going to be as fast as vector algorithms, but they're going to be faster than your naive haystack.iter().position(|&b| b == b'a' || b == b'z')
.
But I mean, yeah... memchr
exists for exactly the same reason. I wrote it because it was yet another crate I had to roll on my own. It happens.
There are also open questions about how to adapt some of the algorithms in this crate (notably the movemask
aspects), that IIRC, aren't obviously available on ARM. But I am way out of my depth on ARM. I don't have any ARM hardware, and Rust's standard library has principally focused on the x86 platform for these sorts of things.
Speaking personally, once I get the time, my own priority is probably going to be getting some new mac hardware and getting this crate working there to the extent possible. IIRC, the main blocking concern was that the stuff needed was either not stable yet or too recently stable.
I do expect the situation to improve in the longer term, but probably not in the short term. I had been holding out hope for the portable higher level SIMD work, aka std::simd
, but it hasn't landed yet.
I'll leave this open for now.
from memchr.
There is definitely no way I'm depending on another crate for what us critical and core functionality in this crate. So the only way this happens is if CPU feature detection is added to core and/or alloc, or if the feature detection is added to this crate itself. Neither seem particularly likely to me.
Could you please elaborate on your use case?
from memchr.
from memchr.
I'm working on a no-std library that can make use of alloc still. The library will be used in an upcoming personal hobby project in both a no-std environment (embedded ARM32 with alloc) as well as std environments (Linux user space on x86-64 as well as ARM32 and AArch64). I have a need for a fast memchr2
across all of those. (For embedded I would obviously not use runtime detection though, but select it at compile time, as I know exactly what I'm targeting.)
The reason I wanted no-std CPU feature detection was primarily to simplify dependency management, avoiding unneeded feature matrix combinations. It would also leave the possibility open for using my library in more situations down the line (though on x86 dealing with FPU/SIMD state in no-std environments can be a bit interesting).
Unfortunately it seems the situation with this library is rather limited on non-x86 anyway, and even the crate I suggested does not support ARM32 feature detection (as I discovered after posting this issue). I guess this is yet another crate I will have to roll my own of.
from memchr.
I don't have any plans to add this in the near future. It's a big maintenance ask IMO. I'm not 100% opposed, but I'd need a very compelling reason to do it.
from memchr.
Related Issues (20)
- Use of `AtomicPtr` in `unsafe_ifunc` prevents memchr from being inlined when compiled with avx enabled HOT 4
- Error building for arm64 on a am64 with docker HOT 2
- Provide const implementation HOT 4
- Poor performance on Zen 1/Threadripper due to loop unrolling HOT 4
- Build script flagged as Virus by Kaspersky Endpoint Security HOT 1
- memchr 2.5.0 fails to compile on Android HOT 3
- Runtime configuration of byte frequency table used to classify rare bytes HOT 10
- Feature request: no-std + alloc HOT 3
- failed to compile `memchr 2.5.0` on macos-12 and macos-11 HOT 2
- `Memchr<'_>` is no longer `Sync` from v2.6 HOT 2
- consider semver-checks HOT 8
- New SIMD improvements break MSRV for aarch64 targets HOT 2
- Update Cargo.toml `package.description` HOT 1
- `x86` performance regression `2.5.0` -> `2.6.0` HOT 16
- The force-enabling of SIMD128 feature can lead to unloadable WASMs in some browsers HOT 9
- Cannot compile with thin-lto on MinGW HOT 1
- Alternate API ordering suggestion HOT 2
- Error when building `memchr` with custom rustflags `-static` HOT 2
- [Windows 10] Failed to run custom build command for 'memchr v2.4.1' HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from memchr.