Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/asm: add neon, vector instructions for arm #7300
go1.2 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.
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.
This change adds a package, chacha20poly1305, which implements the ChaCha20-Poly1305 AEAD from RFC 7539. This AEAD has several attractive features: 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 system. 3. It's seeing significant use in TLS. (A change for crypto/tls is forthcoming.) This change merges two CLs: https://go-review.googlesource.com/#/c/24717 https://go-review.googlesource.com/#/c/26691 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-on: https://go-review.googlesource.com/30728 Reviewed-by: Brad Fitzpatrick <firstname.lastname@example.org> Run-TryBot: Brad Fitzpatrick <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org>
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 golang/go#7300 related to issue #7
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)?