-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
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. |
Got it, thanks for the info! |
It does not compile at the moment:
This didn't use cross compilation but you can do the same with |
Update here: I've got my hands on a MacOS Arm machine and I've gotten frawk compiling in the 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 |
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?
The text was updated successfully, but these errors were encountered: