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

cmd/asm: add neon, vector instructions for arm #7300

gopherbot opened this issue Feb 10, 2014 · 11 comments

cmd/asm: add neon, vector instructions for arm #7300

gopherbot opened this issue Feb 10, 2014 · 11 comments


Copy link

@gopherbot gopherbot commented Feb 10, 2014

by byron.rakitzis:


In contrast to the amd64 port, the arm port of the Go assembler does not recognize SIMD
instructions ("V…") or vector registers (D or Q).

It would be useful for us (we are writing custom speedups for a project using Intel SSE,
and would care to do the same for ARM), but it would also be useful for the Go library
itself if the library functions which have SIMD speedups in xxx_amd64.s had analogous
speedups in xxx_arm.s

Thank you,

Byron Rakitzis.
Copy link

@davecheney davecheney commented Feb 10, 2014

Comment 1:

Could you please list the complete set of instructions you need.

Status changed to WaitingForReply.

Copy link

@gopherbot gopherbot commented Feb 11, 2014

Comment 2 by byron.rakitzis:

These include:
load, store, move, table lookup, shift, xor:
This is highly selective, of course. We also use the D and Q register set
(I hope that is self-evident).

Copy link

@robpike robpike commented Feb 13, 2014

Comment 3:

Marking 1.3Maybe. This is a minor, non-breaking change that could open up some
significant performance improvements.

Labels changed: added repo-main, release-go1.3maybe.

Status changed to Accepted.

Copy link

@rsc rsc commented Apr 3, 2014

Comment 4:

Labels changed: added release-go1.4, removed release-go1.3maybe.

Copy link

@rsc rsc commented Sep 15, 2014

Comment 5:

I'd like to see this happen but it's going to have to wait for the next release.

Labels changed: added release-go1.5, removed release-go1.4.

@bradfitz bradfitz added this to the Go1.5 milestone Dec 16, 2014
@bradfitz bradfitz added this to the Go1.5 milestone Dec 16, 2014
@rsc rsc removed accepted labels Apr 14, 2015
@davecheney davecheney added this to the Go1.6 milestone May 10, 2015
@davecheney davecheney removed this from the Go1.5 milestone May 10, 2015
Copy link

@davecheney davecheney commented May 10, 2015

This will not happen for the 1.5 release

@rsc rsc changed the title cmd/5a: no support for NEON instructions or vector register set in ARM assembler cmd/asm: add neon, vector instructions for arm Jun 8, 2015
Copy link

@rsc rsc commented Nov 4, 2015

I agree this would be useful, and I apologize that we haven't had a chance to do it yet. Note that if you really need the instructions you can figure out what the encodings are (for example using the GNU assembler) and then use WORD directives to insert them in your assembly. I know that's less than ideal, but it's a workaround.

Right now there's more we'd like to do than we have bandwidth for, so the reality is that this one is unplanned.

@rsc rsc added this to the Unplanned milestone Nov 4, 2015
@rsc rsc removed this from the Go1.6 milestone Nov 4, 2015
rkusa added a commit to rkusa/gm that referenced this issue Jan 10, 2016
... however, 'implementation' in this case just means, to fallback to the
pure Go implementation, because go assembly does not yet support arm
neon instructions (which are the equivalent of SSE).
See golang/go#7300
agl referenced this issue in golang/crypto Oct 14, 2016
This change adds a package, chacha20poly1305, which implements the
ChaCha20-Poly1305 AEAD from RFC 7539. This AEAD has several attractive
   1. It's naturally constant time. AES-GCM needs either dedicated
      hardware or extreme effort to be fast and constant-time, while
      this design is easy to make constant-time.
   2. It's fast on modern processors: it runs at 1GB/s on my IvyBrige
   3. It's seeing significant use in TLS. (A change for crypto/tls is

This change merges two CLs:

I took the amd64-optimised AEAD implementation from the former because
it was significantly faster. But the structure of the change is taken
from the latter.

This version will be checked into x/crypto. This package will then be
vendored into the stdlib so that it can be used from crypto/tls.

Change-Id: I5a60587958b7afeec81ca1091e603a7e8517000b
Reviewed-by: Brad Fitzpatrick <>
Run-TryBot: Brad Fitzpatrick <>
TryBot-Result: Gobot Gobot <>
stapelberg added a commit to stapelberg/scan2drive that referenced this issue May 5, 2017
This conversion used to take about 3s (for 4960x7016 RGB pixels).
With the new code it takes about 300ms.

More potential for improvement: we could run this code while reading
pixels via USB.

I haven’t looked at the USB timing in detail, but my guess is that we
could squeeze in this post-processing into the time between requesting
data from the device and receiving the data from the kernel.

If that doesn’t work out, we could parallelize and post-process the
previous buffer while reading the current buffer.

Note that we need to use the WORD instruction because the Go assembler
is lacking support for the NEON instructions, see

related to issue #7
Copy link

@kriskwiatkowski kriskwiatkowski commented Mar 7, 2018

Any clue how much effort is needed to implement support for NEON? The "quick guide to Go's assembler" says that updating go's assembler is "straightforward" - I'm looking for some more details. May someone point me to some PR/diff with some similar implementation that was already done (for example SIMD for intel)?
Many thanks

@andybons andybons added the NeedsFix label Mar 7, 2018
Copy link

@ALTree ALTree commented Mar 7, 2018

@henrydcase a change adding SSE4:

Copy link

@smasher164 smasher164 commented Jul 24, 2019

Specialized code also has to feature-detect for NEON, so a flag needs to be added to internal/cpu (and correspondingly x/sys/cpu) for HasNEON. On linux the flag is hwcap_NEON = 1 << 12.

Copy link

@shibukawa shibukawa commented Dec 3, 2020

I did benchmark with M1 and 10th Gen Core i5, Ryzen 9 on I got interesting result.

  • M1 is much faster than Core i5/Ryzen (basically, took 50%-33% less time to complete)
  • CRC32, SHA1, SHA256 test took much time than other CPUs and Rosetta2 translation

I think M1 native Go implementation doesn't use NEON, but Rosetta2 translate SSE instructions into NEON. I read hash/crc32 code, only amd64.s uses SIMD instructions. So I suppose this issue is important for improving benchmark result of ARM.

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

No branches or pull requests

10 participants