Does compiling Go code on one machine and running it on another degrade the program's performance?

Will there be any performance loss if I compile a Go program on my Mac (obviously, targeting Linux architecture) and push it to Linux server to run on?

I read somewhere that Go compiler optimizes the binary for the specific hardware its being compiled on, like the number of CPU cores for multithreading, etc.? Is it true?

Is it safe to compile Go code on one machine and run it on another (without performance degradation)?

> Does compiling Go code on one machine and running it on another degrade the program's performance?

No.

Your question suggests that different systems can build different binaries from the same source when targeting the same platform, but they don't. Go builds are reproducible by default, i.e. targeting the same platform (as specified by GOOS and GOARCH) when building a package will always yield the exact same binary, no matter where you build it. This is extremely important to be able to assert that a given binary was actually produced from a given source.

While it is possible to break this guarantee (for example through deliberate inclusion of a timestamp in the binary through use of a compiler argument such as -ldflags '-X main.timestamp=${DATE}') this won't influence your execution speed in any measurable quantity.

> Is it safe to compile Go code on one machine and run it on another (without performance degradation)?

Yes. There will be no performance degradation.

> <…> Go compiler optimizes the binary for the specific hardware its being compiled on, like the number of CPU cores for multithreading, etc.? Is it true?

No, it is not (as of 2021-08-13) but read on for some caveats.

The "problem" in our discussion is the assumed defaults.

The thing is, "Go" is a programming langugage defined by its spec (and its memory model), and any implementation which is able to parse text files written according to the spec and execute the Go program they define in a way it adheres to the memory model, is, by definition, "can run Go programs".

As you can see, there could be lots of implementations of Go — including Go interpreters written in Go (search for "yaegi" and "monkey-go", for instance).

Still, I think, it can be safely assumed you meant the "stock", "default" implementation of Go which is developed by the Go core team (and lots of volunteers) and is available from here.
That particular implementation provides the so-called ahead-of-time (AOT) compilation, and the compiler it includes does not, presently, export any build-time controls to affect machine code generation.
It also does not consider the specifics of the local system the build process takes place on — such as its CPU model and the number of H/W threads on its CPUs.

But note an interesting twist: since some time the stock Go implementation has wasm as one of the architectures it targets, and WASM code (typically) runs on a VM which may implement just-in-time (JIT) compilation which is able to fine-tune the compiled code at runtime (by profiling and then recompiling code laying on the hot paths).
The exact value of such fine-tuning compared to an AOT-compiled machine code is questionable as it depends on too many things, and can only be compared and contrasted by benchmarking.

TL;DR

In your case, please, be confident: cross-compilation does not make any difference.