Gccgo now committed to gcc mainline

[Ian Lance Taylor]

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]

> 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]

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

[⚛]

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]

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]

also .vim files

[Ian Lance Taylor]

⚛ <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

[⚛]

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]

⚛ <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