 |
From: Isaac Gouy <igo...@yahoo.com>
Date: Sun, 18 Apr 2010 10:36:44 -0700 (PDT)
Local: Sun, Apr 18 2010 1:36 pm
Subject: [go-nuts] Re: Garbage collection and performance in gccgo
On Apr 17, 7:52 pm, "Rob 'Commander' Pike" <r...@google.com> wrote:
> On Apr 17, 2010, at 6:51 PM, Hans Stimer wrote:
I can't figure out how Hans Stimer calculated 7x but let's take the
> > On Sat, Apr 17, 2010 at 1:49 PM, Ian Lance Taylor <i...@google.com> wrote:
> > 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.
> 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.
median ratio for those x86 quad-core measurements 9.44 > 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.
Throw out pidigits. Throw out regex-dna.
The median ratio for the remaining measurements is approximately 6x
Throw out binary-trees - the median ratio remains approximately 6x
It doesn't seem that PCRE and GMP use explains much in this story.
> 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.
To be clear, is the intention that Go be able to follow C in using
#pragmas, assembler tweaks, and particular GCC flags to achieve that performance? In other words, will Go have rough equivalents to those "highest
> >http://shootout.alioth.debian.org/u32q/compare.php?lang=go
Once upon a time, a GNAT Ada programmer opined that the comparisons
> That particular comparison is pretty misleading. As I said, it doesn't really compare one programming language against another in any meaningful way.
> 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?
> > Will we see 1.2x this year?
> 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
> 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.
would be fair and honest when the assembler produced for the C programs and the assembler produced for the Ada programs was the same - a this apple to this apple comparison. At least that would be unambiguous.
> 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.
| |||||||||||||