 |
From: "Rob 'Commander' Pike" <r...@google.com>
Date: Sat, 17 Apr 2010 19:52:23 -0700
Local: Sat, Apr 17 2010 10:52 pm
Subject: Re: [go-nuts] Garbage collection and performance in gccgo
On Apr 17, 2010, at 6:51 PM, Hans Stimer wrote:
> On Sat, Apr 17, 2010 at 1:49 PM, Ian Lance Taylor <i...@google.com> wrote:
A dominant fraction of that ratio is caused by a couple of tests that depend critically on libraries for which equivalent performance versions are not available in Go. For instance, pidigits depends on a multiprecision math package, and the C versions all use GNU's, which is written in very tight assembler. There's a similar story for regular expressions (regex-dna for instance). Even Python beats Go for pure regexp performance, but then Python's regexps (like almost everyone else's) are implemented in C, by PCRE, whereas Go's are in a slow but simple starter implementation. It's not an apples-to-apples comparison.
> To be clear, the goal is to be within 20% of C performance or closer, > not to be 20% of the performance. > How is that coming? Right now the flawed benchmarks (for what they are worth) are showing it at over 7x slower than C, which is pretty far from 1.2x.
Plus, if you look at those C benchmarks, the highest scorers are often tainted with #pragmas, assembler tweaks, and require particular GCC flags to make them perform that well. If you compare a straight C program to a roughly-equivalent Go program, you'll find the two languages are much closer in performance than this benchmark suite would have you believe.
Still, there's no question Go isn't always performing at the level we want yet.
> Any idea where the performance improvements are going to come from? How big of effort is this going to be?
If you try a straight but carefully written C program and a straight but carefully written Go program, we're there already, even for some of these benchmarks. The reverse-complement benchmark in our tests compares a clean but fast C version and a Go version and they're almost exactly the same speed. Have a look at > Will we see 1.2x this year?
http://code.google.com/p/go/source/browse/test/bench/timing.log?r=rel...
for a fair and honest performance comparison as expressed by this particular benchmark suite. Also some of our internal comparisons between C++ and Go have been encouraging.
Our overall take: The compilers are OK (gc) to good (gccgo) but have room to improve. The libraries, particularly those people like to use in benchmarks, can be slow. Garbage collection isn't fast enough yet, but even if it were, taking care not to generate unnecessary garbage can have a huge effect.
-rob
P.S. Someone should write a FAQ entry about this particular benchmark suite.
-- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||