Plans for ARM Support?

[pettyalex]

Hi, thanks for making such a useful tool! I noticed that STAR has ARM support by dropping SIMDE into Opal. That's a great place to start, but there's room for a lot of improvement.

Are there any plans for ARM support in the future? I noticed that the README still mentions explicitly that only x86 is supported, but it looks like the Debian Med team has been patching SIMDE in for ages to get STAR working on more platforms.

I'm seeing some exploration to bring NEON support to Opal: Martinsos/opal#32 but Opal looks like a fully dead project, so maybe with STAR as its primary consumer the changes could just be made here?

AVX512 also exists too now, and it's very likely that updating Opal / STAR to support AVX512 could accomplish huge increases in performance without changing the existing behavior / algorithms at all. AVX512 performance isn't awesome on Skylake or Cascade Lake Xeons, but it looks outstanding on Ice Lake and newer. Thoughts?

[pettyalex]

For a tiny bit more context: NEON is basically ARM SSE, and SVE is ARM AVX2 or 512, it's actually width generic so the same instructions can apply to vectors of varying sizes.

The cloud vendors are starting to offer ARM compute capacity for significantly cheaper than x86, to where even un-optimized ARM ports can be cost effective. If STAR were updated to support NEON or SVE, Amazon Graviton 3 would become significantly more cost effective vs any other options.

[alexdobin]

Hi Alex,

At present, the only feature in STAR that uses SIMDE is the CellRanger-like trimming of the adapter for STARsolo runs
(option --clipAdapterType CellRanger4).
Opal was easy to use and gave results most similar to CellRanger.
I am not sure if it's worth it to explore other options at this moment.

[daz10000]

Just to clarify - that's very helpful. If I'm running a pipeline and not using that particular option, it would be fine to compile and run on an ARM processor (no performance penalty due to lack of SIMDE operations). Would I still run into problems getting STAR to compile in that environment (I was about to try, so I can work it out experimentally I guess, but any tips appreciated).

[alexdobin]

As long as you can compile it, there will be no performance penalty. There may be some compilations issues with g++ flags. I think you will need make CXXFLAGS_SIMD="" to get rid of the SIMD-specific flag.

[daz10000]

Just to confirm, that worked beautifully to build on an ARM system just now. Still need to test, but thanks for the tip

[BenjaminDEMAILLE]

For anyone landing here: native ARM64 / Apple Silicon support now works end to end on a clean 2.7.11b base. I have opened a set of focused PRs:

• feat: native ARM64 / Apple Silicon and macOS clang build support #2694 — build: arch detection (drop -mavx2 on ARM, NEON via SIMDe), macOS Apple-clang OpenMP (Homebrew libomp), and a native make STARforMac CXX=clang++ target. Closes Error building docker image when compiling STAR on Mac M2 chip : error g++: error: unrecognized command-line option '-mavx2' #2104, error: unrecognized command-line option '-mavx2' #1754, error in make STARforMacStatic with M1 mac #1901, Installing STARsolo on M1 mac #2108 and supersedes the stale fix: build under aarch64 #1863.
• fix(macOS): 0 mapped reads on Apple Silicon (libc++ stringbuf::setbuf is a no-op) #2691 — runtime fix for "0 mapped reads" on Apple Silicon (libc++ ignores stringbuf::pubsetbuf). Closes STAR returns 0 mapped reads (installed via Homebrew & Conda) #2632.
• fix(macOS): spawn readFilesCommand via shell (posix_spawnp) so gzipped input works #2693 — fix --readFilesCommand (gzcat/gunzip -c) on macOS via posix_spawnp. Closes GA fails on macOS due to Failed spawning readFilesCommand #2663.
• fix(build): avoid parallel-make (-j) race on generated parametersDefault.xxd #2692 — fix a parallel-make (-j) race on the generated parametersDefault.xxd. Closes make fail star.cpp #2672.

All verified on a native arm64 build (genome generation + alignment, plain and gzipped input). Review and feedback welcome.

[daz10000]

nice! - we have been running it for years on AWS graviton instances without problems - just needing to tweak the build flags a little. Does this take advantage of any ARM specific instruction sets to improve performance or just tweak the flags to switch off the parallel intel ops? Rereading @alexdobin 's comments from 3 years ago, it looks like it would only impact cellranger features anyway, so maybe this is a moot point.