From: Andrew Gerrand Date: Wed, 21 Apr 2010 04:00:56 +0000 (+1000) Subject: go_faq: add question: Why does Go perform badly on benchmark X? X-Git-Tag: weekly.2010-04-27~63 X-Git-Url: http://www.git.cypherpunks.su/?a=commitdiff_plain;h=0857573a673c122f7a27311423da3ca2fab739d3;p=gostls13.git go_faq: add question: Why does Go perform badly on benchmark X? R=r, cw CC=golang-dev https://golang.org/cl/895043 --- diff --git a/doc/go_faq.html b/doc/go_faq.html index 0961ae9deb..0445188062 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -162,7 +162,7 @@ Can I translate the Go home page into another language?

Absolutely. We encourage developers to make Go Language sites in their own languages. -However, if choose to add the Google logo or branding to your site +However, if you choose to add the Google logo or branding to your site (it does not appear on golang.org), you will need to abide by the guidelines at http://www.google.com/permissions/guidelines.html @@ -334,3 +334,37 @@ compiled with a version of the Plan 9 C compiler that supports segmented stacks for goroutines. Work is underway to provide the same stack management in gccgo. + +

Performance

+ +

+Why does Go perform badly on benchmark X?

+ +

+One of Go's design goals is to approach the performance of C for comparable +programs, yet on some benchmarks it does quite poorly, including several +in test/bench. The slowest depend on libraries +for which versions of comparable performance are not available in Go. +For instance, pidigits depends on a multi-precision math package, and the C +versions, unlike Go's, use GMP (which is +written in optimized assembler). +Benchmarks that depend on regular expressions (regex-dna, for instance) are +essentially comparing Go's stopgap regexp package to +mature, highly optimized regular expression libraries like PCRE. +

+ +

+Benchmark games are won by extensive tuning and the Go versions of most +of the benchmarks need attention. If you measure comparable C +and Go programs (reverse-complement is one example), you'll see the two +languages are much closer in raw performance than this suite would +indicate. +

+ +

+Still, there is room for improvement. The compilers are good but could be +better, many librarise need major performance work, and the garbage collector +isn't fast enough yet (even if it were, taking care not to generate unnecessary +garbage can have a huge effect). +

+