Gccgo now committed to gcc mainline

121 views
Skip to first unread message

Ian Lance Taylor

unread,
Dec 2, 2010, 11:42:20 PM12/2/10
to golan...@googlegroups.com
The gccgo compiler is now committed to gcc mainline, and will, as
planned, be part of the gcc 4.6 release in a few months.

Ian

Gustavo Niemeyer

unread,
Dec 3, 2010, 7:03:38 AM12/3/10
to Ian Lance Taylor, golan...@googlegroups.com
> The gccgo compiler is now committed to gcc mainline, and will, as
> planned, be part of the gcc 4.6 release in a few months.

Thanks, and congratulations Ian!

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter

Ryan Phillips

unread,
Dec 4, 2010, 12:39:41 PM12/4/10
to Gustavo Niemeyer, Ian Lance Taylor, golan...@googlegroups.com
Gustavo Niemeyer <gus...@niemeyer.net> said:
> > The gccgo compiler is now committed to gcc mainline, and will, as
> > planned, be part of the gcc 4.6 release in a few months.
>
> Thanks, and congratulations Ian!

Is the support in GCC 4.6 for x86 architectures, or for all architectures GCC
supports?

Regards,
Ryan

unread,
Dec 5, 2010, 5:59:27 AM12/5/10
to golang-nuts
It seems that gccgo (gcc-4.6-20101204) has horrible performance. For
example, on a mandelbrot benchmark, it is around 4x slower than 8g. Is
that considered "normal behavior" or is it just on my computer?

Ian Lance Taylor

unread,
Dec 6, 2010, 1:04:08 PM12/6/10
to Ryan Phillips, Gustavo Niemeyer, golan...@googlegroups.com
Ryan Phillips <ry...@trolocsis.com> writes:

> Is the support in GCC 4.6 for x86 architectures, or for all architectures GCC
> supports?

It has only been tested on x86. In order to work correctly, the file
libgo/runtime/go-go.c needs a definition of SAVE_REGS appropriate for
the architecture. I don't know of any other architecture specific
issues.

Ian

Francisco Diaz Trepat - gmail

unread,
Dec 6, 2010, 1:18:31 PM12/6/10
to golang-nuts
also .vim files

Ian Lance Taylor

unread,
Dec 6, 2010, 1:24:31 PM12/6/10
to ⚛, golang-nuts
⚛ <0xe2.0x...@gmail.com> writes:

> It seems that gccgo (gcc-4.6-20101204) has horrible performance. For
> example, on a mandelbrot benchmark, it is around 4x slower than 8g. Is
> that considered "normal behavior" or is it just on my computer?

On the code in test/bench/mandelbrot.go gccgo runs slightly faster than
6g. So, it depends on the benchmark.

I would expect gccgo to tend to run slower than 8g for a program that
uses a lot of goroutines. That is because gccgo still uses a separate
thread for each goroutine. I would expect gccgo to tend to run faster
than 8g for straight line code with few goroutines. But, of course, in
all cases, it depends.

I have not yet made any effort at all to speed up the gccgo generated
code. There may well be some low-hanging fruit in there.

Ian

unread,
Dec 6, 2010, 2:33:51 PM12/6/10
to golang-nuts
On Dec 6, 7:24 pm, Ian Lance Taylor <i...@google.com> wrote:
I used [http://shootout.alioth.debian.org/u64/program.php?
test=mandelbrot&lang=go&id=6] I downloaded some time ago. It turns out
that the problematic part is the x87 FPU code on x86-32. Using "-
mfpmath=sse" produces much faster code:

sse: 69 seconds (user time)
x87: 411 seconds (user time)

The assembly code of the x87 version is in a bad shape.

Ian Lance Taylor

unread,
Dec 6, 2010, 4:48:52 PM12/6/10
to ⚛, golang-nuts
⚛ <0xe2.0x...@gmail.com> writes:

> I used [http://shootout.alioth.debian.org/u64/program.php?
> test=mandelbrot&lang=go&id=6] I downloaded some time ago. It turns out
> that the problematic part is the x87 FPU code on x86-32. Using "-
> mfpmath=sse" produces much faster code:
>
> sse: 69 seconds (user time)
> x87: 411 seconds (user time)
>
> The assembly code of the x87 version is in a bad shape.

Ah, interesting point. This is most likely because gccgo turns on
standard conformant floating point behaviour. That makes results
reproducible when using float64 with optimization turned on, but it does
have a performance cost. So another way to get better results might be
-fexcess-precision=fast.

Ian

Reply all
Reply to author
Forward
0 new messages