How to speed up the program on Go
Alas, I do not keep my blog, and I consider it necessary to publish the result of the recent “discovery” in the form of a note. I believe there will be people to whom this is very useful.
Go is a language compiled into native code, and therefore, obviously, should be fast. However, unfortunately, at the moment this is not always true .
In my case, Go lost PHP (well, in fact, the PHP module in C, but the result is still depressing). In short, when calculating the Whirlpool-hash, Go lost 3.5-7.5 times!
In the set of sources, the same reason is described - the “weak” standard Go compiler (the one that is invoked via the go build). This is completely true. The fact is that the compiler is rather “young” and does not yet have baggage optimizations, which, for example, GCC has.
The solution is - there is a version of the compiler Go - gccgo.
Building the program through gccgo with optimizations is as follows:
In this case, it will be assembled with all the available optimizations and instructions on the current equipment.
In general, it suffices to use only the -O2 option.
Test results for my case :
The total execution time of the program compiled by gccgo with optimizations turned out to be 4.2-9.2 times faster than the build without optimizations.
Summary "plate":
On this, in general, everything, thank you for your attention.
UPD1 : Compiler in go 1.2.1 gives significantly better results (added to the table):
Also note that there is some difference in the final build when using different compilers for different platforms or different linkers. Information here: blog.golang.org/gccgo-in-gcc-471
In short, everything will be fine if you use gccgo> = 4.7.1 paired with the linker gold on x86 (32/64 bit). The problems are perhaps not terribly scary, but more target platforms appear. Details in the post on the link above.
Go is a language compiled into native code, and therefore, obviously, should be fast. However, unfortunately, at the moment this is not always true .
In my case, Go lost PHP (well, in fact, the PHP module in C, but the result is still depressing). In short, when calculating the Whirlpool-hash, Go lost 3.5-7.5 times!
In the set of sources, the same reason is described - the “weak” standard Go compiler (the one that is invoked via the go build). This is completely true. The fact is that the compiler is rather “young” and does not yet have baggage optimizations, which, for example, GCC has.
The solution is - there is a version of the compiler Go - gccgo.
Building the program through gccgo with optimizations is as follows:
go build -compiler gccgo -gccgoflags "-march=native -O3" main.go
In this case, it will be assembled with all the available optimizations and instructions on the current equipment.
In general, it suffices to use only the -O2 option.
Test results for my case :
Hidden text
# Standart compiler
➜ go build ./dedup.go
➜ time ./dedup> / dev / null
')
real 0m4.612s
user 0m4.588s
sys 0m0.020s
# gccgo compiler without optimizations
➜ go build -compiler gccgo ./dedup.go
➜ time ./dedup> / dev / null
real 0m2.110s
user 0m2.084s
sys 0m0.024s
# PHP realization
➜ time php hash.php> / dev / null
real 0m0.634s
user 0m0.608s
sys 0m0.024s
# gccgo with optimizations
➜ go build -a -gccgoflags "-march = native -O3" -compiler gccgo ./dedup.go
➜ time ./dedup> / dev / null
real 0m0.534s
user 0m0.512s
sys 0m0.020s
➜ go build ./dedup.go
➜ time ./dedup> / dev / null
')
real 0m4.612s
user 0m4.588s
sys 0m0.020s
# gccgo compiler without optimizations
➜ go build -compiler gccgo ./dedup.go
➜ time ./dedup> / dev / null
real 0m2.110s
user 0m2.084s
sys 0m0.024s
# PHP realization
➜ time php hash.php> / dev / null
real 0m0.634s
user 0m0.608s
sys 0m0.024s
# gccgo with optimizations
➜ go build -a -gccgoflags "-march = native -O3" -compiler gccgo ./dedup.go
➜ time ./dedup> / dev / null
real 0m0.534s
user 0m0.512s
sys 0m0.020s
The total execution time of the program compiled by gccgo with optimizations turned out to be 4.2-9.2 times faster than the build without optimizations.
Summary "plate":
| Option | Relative time |
| gccgo optimized | 85% |
| Php | 100% |
| gc v1.2.1 | 210% |
| gccgo | 350% |
| gc v1 | 750% |
On this, in general, everything, thank you for your attention.
UPD1 : Compiler in go 1.2.1 gives significantly better results (added to the table):
Hidden text
➜ time ./dedup> / dev / null
real 0m1.550s
user 0m1.528s
sys 0m0.020s
real 0m1.550s
user 0m1.528s
sys 0m0.020s
Also note that there is some difference in the final build when using different compilers for different platforms or different linkers. Information here: blog.golang.org/gccgo-in-gcc-471
In short, everything will be fine if you use gccgo> = 4.7.1 paired with the linker gold on x86 (32/64 bit). The problems are perhaps not terribly scary, but more target platforms appear. Details in the post on the link above.
Source: https://habr.com/ru/post/222957/
All Articles