Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should ARM64 use be avoided? #84

Open
farski opened this issue Feb 15, 2022 · 4 comments
Open

Should ARM64 use be avoided? #84

farski opened this issue Feb 15, 2022 · 4 comments

Comments

@farski
Copy link

farski commented Feb 15, 2022

The Overview doc says "I suspect [frawk] would run much slower on a 64-bit non-x86 architecture." Does that mean it frawk would be slower on ARM than frawk on x84, or that frawk would be slower than gawk/mawk/etc? In other words, would frawk still be faster, or should it be avoided on ARM if performance is a goal?

@ezrosent
Copy link
Owner

The short answer is I don't know. I haven't had the chance to test frawk on ARM. Some of frawk's optimizations are x86-specific, so I'd expect any baseline advantage frawk might have over another utility to be lower on a different architecture, but I do not know that for sure.

While I have some ideas for how to optimize frawk on ARM, I do not believe I'll make much headway until I have access to an ARM machine on which I can run some tests and benchmarks. I do genuinely plan to get around to this eventually, but it won't be for a little while yet.

@farski
Copy link
Author

farski commented Feb 16, 2022

Got it, thanks for the info!

@pothos
Copy link

pothos commented Apr 27, 2022

It does not compile at the moment:

#56 1587.3 error: This macro cannot be used on the current target.
#56 1587.3                                    You can prevent it from being used in other architectures by
#56 1587.3                                    guarding it behind a cfg(any(target_arch = "x86", target_arch = "x86_64")).
#56 1587.3    --> src/runtime/splitter/batch.rs:675:22
#56 1587.3     |
#56 1587.3 675 |     if ALLOW_AVX2 && is_x86_feature_detected!("avx2") && is_x86_feature_detected!("pclmulqdq") {
#56 1587.3     |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#56 1587.3     |
#56 1587.3     = note: this error originates in the macro `is_x86_feature_detected` (in Nightly builds, run with -Z macro-backtrace for more info)
#56 1587.3 
[…]

This didn't use cross compilation but you can do the same with rustup target add aarch64-unknown-linux-musl ; RUSTFLAGS="-C target-feature=+crt-static" cargo build --target aarch64-unknown-linux-musl I guess.
You can try running (or compiling if you don't use cross-compilation) the binary with qemu-user-static installed and running docker run --rm -ti docker.io/arm64v8/debian (or other common dockerhub images)
Edit: or actually you don't need a docker environment to run it since it's a static binary and can be started directly despite being another architecture.

@ezrosent
Copy link
Owner

ezrosent commented Jul 9, 2022

Update here: I've got my hands on a MacOS Arm machine and I've gotten frawk compiling in the arm_support branch.

I'm going to look into porting the SIMD code to Arm next. I've made some progress here, but there are definitely some concepts that don't map precisely between Arm NEON and SSE2/AVX2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants