It is already done in parallel, as controlled by the GOMAXPROCS environment variable, q.v.

(If you are aware of areas where it could usefully be more parallel, please let us know.)

Thanks a lot for pointing this out. What's real value for this variable? Is it set automatically according to the number of physical cores on user's machine?

I defaults to GOMAXPROCS

GOMAXPROCS defaults to the number of logical CPU cores on your machine.

@ianlancetaylor Do you mean it will account into the hyper threading results?

Whatever your operating system counts as a core is what go build will use.

Do you mean the following counting method:

$ cat /proc/cpuinfo | grep processor | wc -l
4

The method differs by operating system and processor.

Stepping back for a moment, what is the problem you are having? You've mentioned something about building Go code in parallel. To the best of my understanding the Go tool builds packages in parallel by running multiple copies of the go compiler -- one per package, up to GOMAXPROCS by default or go build -p N if supplied. Inside the compiler each function is compiled in parallel, again using GOMAXPROCs threads. I'm reasonably confident that the Go tool, where possible, uses the resources the operating system makes available to it when compiling. Do you disagree? If so, please explain what you are seeing.

@davecheney I compile go git master version on a dual Xeon E5-2699v4 (44 physical cores in total) machine with 256 G ram. It takes several minutes for buildings and testings. So I want to know whether this is reasonable.

I think a few minutes is a reasonable time to execute ./all.bash. You can judge for yourself using a tool like top(1) or htop(1).