What version of Go are you using (go version)?

Please note: Our "build machine" is Linux, from which we compile for Linux (linux/amd64) and cross-compile for our other platforms (windows/amd64, aix/ppc64, linux/ppc64le).

go version go1.17.5 linux/amd64

Does this issue reproduce with the latest release?

Yes, for all versions of Go used to compile programs for aix/ppc64.

What operating system and processor architecture are you using (go env)?

Please note: Our "build machine" is Linux, from which we compile for Linux (linux/amd64) and cross-compile for our other platforms (windows/amd64, aix/ppc64, linux/ppc64le).

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/builder/.cache/go-build"
GOENV="/home/builder/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="{{PRODUCT RELATED PATH OMITTED}}/pkg/mod"
GONOPROXY="github.ibm.com"
GONOSUMDB="github.ibm.com"
GOOS="linux"
GOPATH="{{PRODUCT RELATED PATH OMITTED}}/srv_git"
GOPRIVATE="github.ibm.com"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go1.17.5"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go1.17.5/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="{{PRODUCT RELATED PATH OMITTED}}/src/github.com/minio/minio/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1906808776=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Our company implements a cross-platform application (linux/amd64, windows/amd64, aix/ppc, linux/ppc64le) that makes extensive use of HTTPS (TLS) within a client-server architecture. As a part of our development/test cycle, we CPU profile our application in different scenarios (using pprof). When doing so on AIX, we discovered that many of the src/crypto/aes block and stream cipher functions were a significant performance bottleneck for our application.

On further inspection, we found that "generic" versions (implemented in Go and not in pseudo-assembler) were being used for ppc64, which are significantly slower than their "optimized" ppc64le counterparts.

To work around these limitations, we've worked on customizing the Golang language by porting over ppc64le implementations of block and stream cipher functions to ppc64 into new files src/crypto/aes/asm_ppc64.s and src/crypto/aes/gcm_ppc64.s assembler files, then built out some of the higher-level Golang functions to make use of this assembler (with new src/crypto/aes/cipher_ppc64x.go and src/crypto/aes/gcm_ppc64.go files). We've then run the component unit tests to validate correctness.

The purpose of this issue is to see whether we could get these changes added to Golang so that this customization is no longer needed for us or others making extensive use of crypto features with Golang on aix/ppc64.

What did you expect to see?

Similar performance for HTTPS (TLS) block and stream cipher code as with other platforms.

What did you see instead?

Since much of the src/crypto/aes code for ppc64 is implemented in ("generic") Go, performance is worse on this platform.