Goはネイティブコードにコンパイルされた言語であるため、明らかに高速である必要があります。 ただし、残念ながら、現時点ではこれは常に真実ではありません 。
私の場合、 GoはPHPに負けました （実際、CのPHPモジュールですが、結果はまだ気のめいるようです）。 要するに、ワールプールハッシュを計算すると、Goは3.5〜7.5回失われました。
多くのソースが同じ理由を説明しています-「弱い」標準のGoコンパイラ（goビルドで呼び出されるもの）。 これは完全に真実です。 事実、コンパイラは非常に「若い」ため、これまでのところ、GCCのような最適化の手荷物はありません。
解決策があります-Goコンパイラのバリアント-gccgoがあります。
最適化を使用したgccgoによるプログラムの構築は次のとおりです。
go build -compiler gccgo -gccgoflags "-march=native -O3" main.go
この場合、現在の機器で利用可能なすべての最適化と指示でアセンブリが実行されます。
一般に、単に-O2オプションを使用します。
私の場合のテスト結果：
非表示のテキスト
＃Standartコンパイラ
buildビルドを行います./dedup.go
➜time ./dedup> / dev / null
実際の0m4.612s
ユーザー0m4.588s
sys 0m0.020s
＃最適化なしのgccgoコンパイラ
➜go build -compiler gccgo ./dedup.go
➜time ./dedup> / dev / null
実際の0m2.110s
ユーザー0m2.084s
sys 0m0.024s
＃PHPの実装
➜時間php hash.php> / dev / null
実際の0m0.634s
ユーザー0m0.608s
sys 0m0.024s
＃最適化されたgccgo
➜go build -a -gccgoflags "-march = native -O3" -compiler gccgo ./dedup.go
➜time ./dedup> / dev / null
実際の0m0.534s
ユーザー0m0.512s
sys 0m0.020s
buildビルドを行います./dedup.go
➜time ./dedup> / dev / null
実際の0m4.612s
ユーザー0m4.588s
sys 0m0.020s
＃最適化なしのgccgoコンパイラ
➜go build -compiler gccgo ./dedup.go
➜time ./dedup> / dev / null
実際の0m2.110s
ユーザー0m2.084s
sys 0m0.024s
＃PHPの実装
➜時間php hash.php> / dev / null
実際の0m0.634s
ユーザー0m0.608s
sys 0m0.024s
＃最適化されたgccgo
➜go build -a -gccgoflags "-march = native -O3" -compiler gccgo ./dedup.go
➜time ./dedup> / dev / null
実際の0m0.534s
ユーザー0m0.512s
sys 0m0.020s
合計で、最適化を使用してgccgoによってコンパイルされたプログラムの実行時間は、最適化を使用しないビルドよりも4.2〜9.2倍高速でした。
要約「プレート」：
| オプション | 相対時間 |
| 最適化されたgccgo | 85％ |
| Php | 100％ |
| gc v1.2.1 | 210％ |
| gccgo | 350％ |
| gc v1 | 750％ |
これについては、一般的に、すべて、ご清聴ありがとうございました。
UPD1 ：go 1.2.1のコンパイラは、結果が大幅に向上しています（表に追加）：
非表示のテキスト
➜time ./dedup> / dev / null
実際の0m1.550s
ユーザー0m1.528s
sys 0m0.020s
実際の0m1.550s
ユーザー0m1.528s
sys 0m0.020s
また、異なるプラットフォームまたは異なるリンカに異なるコンパイラを使用する場合、最終アセンブリに多少の違いがあることに注意してください。 ここの情報： blog.golang.org/gccgo-in-gcc-471
つまり、gccgo> = 4.7.1とx86（32/64ビット）のゴールドリンカーを組み合わせて使用すれば、すべて問題ありません。 問題は恐らくそれほど恐ろしいものではありませんが、より多くのターゲットプラットフォームが登場します。 上記リンクの投稿の詳細。