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

runtime: swiss map SIMD implementation for non-amd64 #71255

Open
prattmic opened this issue Jan 13, 2025 · 4 comments
Open

runtime: swiss map SIMD implementation for non-amd64 #71255

prattmic opened this issue Jan 13, 2025 · 4 comments
Assignees
Labels
arch-arm64 compiler/runtime Issues related to the Go compiler and/or runtime. Implementation Issues describing a semantics-preserving change to the Go implementation. NeedsFix The path to resolution is known, but the work has not been done. Performance
Milestone

Comments

@prattmic
Copy link
Member

https://go.dev/cl/626277 (in 1.24) added SIMD implementations for swissmap (still 8-byte) control word operations for amd64. We could do similar for other architectures, if the SIMD implementations improve performance. ARM64 is the obvious target here given its wide use.

@prattmic prattmic added arch-arm64 compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done. Performance labels Jan 13, 2025
@prattmic prattmic added this to the Backlog milestone Jan 13, 2025
@gabyhelp gabyhelp added the Implementation Issues describing a semantics-preserving change to the Go implementation. label Jan 13, 2025
@Clement-Jean
Copy link

I'm interested in helping on this. I'll dig in the AMD64 implementation and try to come up with the ARM64 one

@Clement-Jean
Copy link

I poked around a little bit today, but I can seem to make the intrinsics work...

First of all, I'm surprised that I cannot simply set this alias to work on ARM64 (add sys.ArchARM64):

alias("internal/runtime/maps", "bitsetFirst", "internal/runtime/sys", "TrailingZeros64", sys.ArchAMD64)

This is weird to me because TrailingZeros64 is defined for ARM64 and this returns an error related to WASM when compiling:

panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
       /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
        /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
        /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
       /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
go: error obtaining buildID for go tool compile: exit status 2
go: error obtaining buildID for go tool compile: exit status 2
go: error obtaining buildID for go tool compile: exit status 2
go: error obtaining buildID for go tool compile: exit status 2
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
        /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
go: error obtaining buildID for go tool compile: exit status 2
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
       /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
        /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
        /go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
go: error obtaining buildID for go tool compile: exit status 2
go: error obtaining buildID for go tool compile: exit status 2
go: error obtaining buildID for go tool compile: exit status 2
go: internal error: Builder WorkDir unexpectedly changed from /var/folders/nv/rqg_nqy55pq_ky2j_34whq6c0000gn/T/go-build1659387489 to
panic: runtime error: index out of range [-16384]

goroutine 1 [running]:
cmd/internal/obj/wasm.init.0()
        go/src/cmd/internal/obj/wasm/wasmobj.go:91 +0x1f4
go tool dist: FAILED: go/pkg/tool/darwin_arm64/go_bootstrap install -a cmd/asm cmd/cgo cmd/compile cmd/link cmd/preprofile: exit status 1

maybe I forgot to regenerate something?

After that, I tried to make the bitsetLowestSet intrinsic work but ssa.OpEq64 doesn't seem to accept a constInt64. Could you guide me to where are the rules for instructions (like what they accept as params and at which position)? I remember there is such a table but I can't seem to find it...

@thepudds
Copy link
Contributor

Hi @Clement-Jean, I think it is great that you are exploring this.

I wanted to point you to two optional resources that I think could be helpful if you don’t already know about them:

  • The #contributors channel in Gopher Slack is a good place for both general and specific questions about contributing to Go.
  • The #assembly channel in Gopher slack has friendly/knowledgeable people.

There is an invite app for access if you are interested.

There are also the mailing lists and other forums, and people will comment here as well, but I wanted to mention those two channels as options for informal or ad-hoc conversations that tend to be fairly helpful.

@Clement-Jean
Copy link

Clement-Jean commented Feb 10, 2025

It seems that without the implementation of intrinsics, vector types, and register allocation for vectors, the ARM64 implementation is largely inefficient.

I tried both representation of the bitset (packed and unpacked) and my implementation is almost always 2 times slower than the current one on the BenchmarkMapAccessHit benchmark.

If anyone wants to check my implementation you can find it here (on branch simd_swissmap_arm64): https://github.com/Clement-Jean/go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-arm64 compiler/runtime Issues related to the Go compiler and/or runtime. Implementation Issues describing a semantics-preserving change to the Go implementation. NeedsFix The path to resolution is known, but the work has not been done. Performance
Projects
Development

No branches or pull requests

4 participants