Pro64-based GPLed compiler

Pro64-based GPLed compiler

[Marc Gonzalez-Sigler]

Hello everyone,

In 2000, SGI released a GPLed compiler suite.
http://gcc.gnu.org/ml/gcc/2000-05/threads.html#00632
http://web.archive.org/www.sgi.com/newsroom/press_releases/2000/may/linux-ia64.html

I've taken PathScale's source tree (they've removed the IA-64 code 
generator, and added an x86/AMD64 code generator), and tweaked the 
Makefiles.

I thought some of you might want to take a look at the compiler.

http://www-rocq.inria.fr/~gonzalez/vrac/open64-alchemy-src.tar.bz2

Disclaimer: this release has received *very* little testing. Some might 
cringe when they see the way I hacked the Makefile structure. (I welcome 
all comments and suggestions.) I haven't managed to build the IPA 
(inter-procedure analyzer) module.

-- 
Regards, Marc

Re: Pro64-based GPLed compiler

[Vladimir Makarov]

Marc Gonzalez-Sigler wrote:

> Hello everyone,
>
>
> I've taken PathScale's source tree (they've removed the IA-64 code 
> generator, and added an x86/AMD64 code generator), and tweaked the 
> Makefiles.
>
> I thought some of you might want to take a look at the compiler.
>
> http://www-rocq.inria.fr/~gonzalez/vrac/open64-alchemy-src.tar.bz2
>
This reference doesn't work.   The directory vrac looks empty.

Vlad

Re: Pro64-based GPLed compiler

[Marc]

Vladimir Makarov wrote:

> Marc Gonzalez-Sigler wrote:
> 
>> I've taken PathScale's source tree (they've removed the IA-64 code
>> generator, and added an x86/AMD64 code generator), and tweaked the
>> Makefiles.
>>
>> I thought some of you might want to take a look at the compiler.
>>
>> http://www-rocq.inria.fr/~gonzalez/vrac/open64-alchemy-src.tar.bz2
>
> This reference doesn't work.   The directory vrac looks empty.

Fixed. I'll never understand how AFS ACLs work ;-(

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: Pro64-based GPLed compiler

[Daniel Berlin]

On Wed, 2005-06-29 at 14:01 -0400, Vladimir Makarov wrote:
> Marc Gonzalez-Sigler wrote:
> 
> > Hello everyone,
> >
> >
> > I've taken PathScale's source tree (they've removed the IA-64 code 
> > generator, and added an x86/AMD64 code generator), and tweaked the 
> > Makefiles.
> >
> > I thought some of you might want to take a look at the compiler.
> >
> > http://www-rocq.inria.fr/~gonzalez/vrac/open64-alchemy-src.tar.bz2
> >
> This reference doesn't work.   The directory vrac looks empty.
> 

The only other interesting thing they've done is add a simdizer.

I diff'd the pathscale compiler and the open64 compiler source, and the
main differences are:

A bunch of random code #ifdef KEY'd
A SIMDizer, which doesn't look like it's as good as ours, it just has
better dependence and alias info to work with  ATM.

Re: Pro64-based GPLed compiler

[James E Wilson]

Daniel Berlin wrote:
> A bunch of random code #ifdef KEY'd

FYI Pathscale was formerly known as Key Research.  So the KEY probably 
wouldn't mean anything special here, it is likely just a marker for 
local changes.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Pro64-based GPLed compiler

[Vladimir Makarov]

James E Wilson wrote:

> Daniel Berlin wrote:
>
>> A bunch of random code #ifdef KEY'd
>
>
> FYI Pathscale was formerly known as Key Research.  So the KEY probably 
> wouldn't mean anything special here, it is likely just a marker for 
> local changes.

I heard a lot of this compiler and expected a better results for it. 
 Using -O2 -mtune=nocona for gcc4 and -O2 -mtune=em64t for open64 on 
em64t machine in 32-bit mode, I found preliminarily  that pathscale 
compiler generates about 10% worse and 30% larger code (text segment) 
for SPECInt2000.  It is also 70% slower than gcc4.  I just hope results 
for 64-bit mode, amd machine, or SPECFP2000 are better.

Vlad

Re: Pro64-based GPLed compiler

[Daniel Berlin]

On Thu, 2005-06-30 at 18:23 -0400, Vladimir Makarov wrote:
> James E Wilson wrote:
> 
> > Daniel Berlin wrote:
> >
> >> A bunch of random code #ifdef KEY'd
> >
> >
> > FYI Pathscale was formerly known as Key Research.  So the KEY probably 
> > wouldn't mean anything special here, it is likely just a marker for 
> > local changes.
> 
> I heard a lot of this compiler and expected a better results for it. 

Don't believe the hype.
It's really not that good of a compiler :)
It has interesting loop nest optimizations, but, ...

Re: Pro64-based GPLed compiler

[James E Wilson]

Vladimir Makarov wrote:
> I just hope results 
> for 64-bit mode, amd machine, or SPECFP2000 are better.

Their web pages primarily talk about the 64-bit performance on AMD 
systems.  Maybe they aren't well tuned for 32-bit performance and/or 
Intel parts.  Anyways, from what Daniel Berlin mentioned, it may be that 
the tree-ssa stuff in gcc4.x has negated much of their earlier advantage.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Pro64-based GPLed compiler

[Daniel Berlin]

On Thu, 2005-06-30 at 17:17 -0700, James E Wilson wrote:
> Vladimir Makarov wrote:
> > I just hope results 
> > for 64-bit mode, amd machine, or SPECFP2000 are better.
> 
> Their web pages primarily talk about the 64-bit performance on AMD 
> systems.  Maybe they aren't well tuned for 32-bit performance and/or 
> Intel parts.  Anyways, from what Daniel Berlin mentioned, it may be that 
> the tree-ssa stuff in gcc4.x has negated much of their earlier advantage.

I would not be surprised if they kick the crap out of us when it comes
to numerical fortran or something, but for regular c code, i'd not
expect more than 10-20% difference, max.

Re: Pro64-based GPLed compiler

[Marc Gonzalez-Sigler]

Vladimir Makarov wrote:

> I heard a lot of this compiler and expected a better results for it. 
> Using -O2 -mtune=nocona for gcc4 and -O2 -mtune=em64t for open64 on 
> em64t machine in 32-bit mode, I found preliminarily  that pathscale 
> compiler generates about 10% worse and 30% larger code (text segment) 
> for SPECInt2000.  It is also 70% slower than gcc4.  I just hope results 
> for 64-bit mode, amd machine, or SPECFP2000 are better.

You might want to give the official release a try. (In other words,
I don't think it's safe to use our "distribution" to judge EKOPath.)

http://www.pathscale.com/ekopath.html

AFAIU, LNO is not performed at -O2, so you should use -O3.
And, if I managed to build the IPA module, you should use -Ofast.

If you are interested, I can run SPECint2000 on a 3.0 GHz Northwood
core, and report the results here.

Finally, as James noted, the performance on AMD CPUs should be
higher than that on Intel CPUs.

-- 
Regards, Marc

Re: Pro64-based GPLed compiler

[Marc Gonzalez-Sigler]

Daniel Berlin wrote:

> On Thu, 2005-06-30 at 17:17 -0700, James E Wilson wrote:
> 
>> Their web pages primarily talk about the 64-bit performance on AMD 
>> systems.  Maybe they aren't well tuned for 32-bit performance and/or 
>> Intel parts.  Anyways, from what Daniel Berlin mentioned, it may be that 
>> the tree-ssa stuff in gcc4.x has negated much of their earlier advantage.
> 
> I would not be surprised if they kick the crap out of us when it comes
> to numerical fortran or something, but for regular c code, i'd not
> expect more than 10-20% difference, max.

On an FX-57, EKOPath is close to icc for SPECint2000:

http://www.spec.org/osg/cpu2000/results/res2005q2/cpu2000-20050613-04264.html
http://www.spec.org/osg/cpu2000/results/res2005q2/cpu2000-20050613-04262.html

icc on WinXP     SPECint2000 = 1970
pathcc on Linux  SPECint2000 = 1929

Do you have a SPECint2000 breakdown for gcc tree-ssa on Linux?

The dev's summit mentions SPECint2000 results, but I didn't find what
I was looking for.

http://www.gccsummit.org/2005/2005-GCC-Summit-Proceedings.pdf

-- 
Regards, Marc

Re: Pro64-based GPLed compiler

[Joost VandeVondele]

>> Their web pages primarily talk about the 64-bit performance on AMD
>> systems.  Maybe they aren't well tuned for 32-bit performance and/or
>> Intel parts.  Anyways, from what Daniel Berlin mentioned, it may be 
that
>> the tree-ssa stuff in gcc4.x has negated much of their earlier 
advantage.

>I would not be surprised if they kick the crap out of us when it comes
>to numerical fortran or something, but for regular c code, i'd not
>expect more than 10-20% difference, max.

At least there is some comparison for fortran (amd,intel,32,64)

http://www.polyhedron.co.uk/compare/linux/f77bench_AMD.html
http://www.polyhedron.co.uk/compare/linux/f77bench_p4.html
http://www.polyhedron.co.uk/compare/linux/f90bench_AMD.html
http://www.polyhedron.co.uk/compare/linux/f90bench_p4.html

there's no g77 on te first graph and f90 graphs, but NAG translates 
fortran to C and uses gcc for code generation, and as it is faster than 
g77 in f77bench_p4, that is a worthwhile comparison.

Cheers,

Joost