Back in ancient times (2005!) I bought a PowerMac G5 running OSX
mostly because IBM's XL-Fortran (8.1) was available for it.  Shortly
afterwards IBM dropped support for it when Apple moved to Intel
processors.  However, I still use it as my primary development
platform becuase it still outperforms the latest Gfortran even though
Mac-XLF is getting a little long in the tooth (Linux-XLF is up to
version 13.1).  I've been thinking of converting the box over to Linux
(e.g. YDL 6.2) and getting a later version of XLF.  Has anyone gone
this route?  One stumbling block is that IBM has increased the single
user price of XL for Linux in the last few years from $1000 then $2000
to a whopping $4000 just recently.

Al Greynolds
www.ruda-cardinal.com

Hi Al,

no experience with Mac or PowerPC, but ...

Al Greynolds wrote:
> Back in ancient times (2005!) I bought a PowerMac G5 running OSX
> mostly because IBM's XL-Fortran (8.1) was available for it.  Shortly
> afterwards IBM dropped support for it when Apple moved to Intel
> processors.  However, I still use it as my primary development
> platform becuase it still outperforms the latest Gfortran

For curiosity: What do you mean by outperform? gfortran vs. xlf on the 
same computer or xlf on PowerMac vs. gfortran on a (more modern) 
Intel/AMD system?

And by how much? If I look on my AMD at my polyhedron benchmarks [as of 
May], I see only a performance difference of 6% (geometric mean) to 
Intel's 11.1 compiler - and if I use Intel's math library (IMF) it 
shrinks to less than a per cent. Pathscale seems to be another 2% faster 
than Intel, i.e. 8% in total (when using the standard GLIBC).

For single benchmarks, one can find, e.g., 13.28s gfortran (GLIBC), 
11.21s gfortran (IMF) vs. 15.35s intel but also the reverse that intel 
is, e.g., 40% faster.

Thus, I would be interested by how much gfortran is off compared with xlf.

Tobias

In article 
<0102014a-4a5f-4ae8-8062-52dcfad9b2c4@p11g2000prf.googlegroups.com>,
 Al Greynolds <awgreynolds@earthlink.net> wrote:

> Back in ancient times (2005!) I bought a PowerMac G5 running OSX
> mostly because IBM's XL-Fortran (8.1) was available for it.  Shortly
> afterwards IBM dropped support for it when Apple moved to Intel
> processors.  However, I still use it as my primary development
> platform becuase it still outperforms the latest Gfortran even though
> Mac-XLF is getting a little long in the tooth (Linux-XLF is up to
> version 13.1).

The other problem is that IBM XLF was only supported on MacOSX up to 
10.3.  There were patches that allowed it to work on 10.4, but as 
far as I know, it does not work at all on 10.5.  And, of course, 
MacOSX 10.6 is intel-only and is not supported on PPC hardware at 
all.

It is true that the PPC hardware was far ahead of intel hardware in 
many ways.  The early G5 Macs for example, had a 1 GB/s memory bus 
speed in 2003. I think intel did not have that kind of memory 
bandwidth until 2007 (or 2008, I forget).  Of course, I'm still 
waiting to see a PowerBook G5. ;-)  That was the real reason apple 
switched to intel hardware, IBM simply dropped the ball with 
low-power hardware that could be used in laptops and consumer 
desktops.

> I've been thinking of converting the box over to Linux
> (e.g. YDL 6.2) and getting a later version of XLF.  Has anyone gone
> this route?  One stumbling block is that IBM has increased the single
> user price of XL for Linux in the last few years from $1000 then $2000
> to a whopping $4000 just recently.

I still have several PPC machines too, so I would like to see these 
comments.  How much life is there left in PPC hardware?  I just got 
an i7-based MacBook Pro that does sgemm at 46 GFLOPS and dgemm at 23 
GFLOPS.  Remember, the vector unit in G5 hardware did not do double 
precision at all, so the dgemm speed is about 8x faster.  I have not 
timed a recent desktop machine, but they should be even faster than 
the low-power laptop chips.

BTW, gfortran does run in 64-bit mode on the MacBook Pro, so it is a 
pretty impressive, completely portable, development machine.  A free 
gfortran is cheaper than a $4000 xlf.

$.02 -Ron Shepard

On Aug 26, 10:10=A0am, Tobias Burnus <bur...@net-b.de> wrote:

> For curiosity: What do you mean by outperform? gfortran vs. xlf on the
> same computer or xlf on PowerMac vs. gfortran on a (more modern)
> Intel/AMD system?

I mean on the same Quad PowerMac G5 box running OSX (10.4.11).  And
"outperforms" here just doesn't mean "speed".  Even my old version of
XLF is a much more robust Fortran-95/OpenMP compiler than the current
Gfortran so I don't have to waste time chasing/working-around compiler
bugs.  Also, the latest XLFs have implemented all of F2003 and most
(if not all) of F2008.

Al

On Aug 26, 12:22=A0pm, Al Greynolds <awgreyno...@earthlink.net> wrote:
> On Aug 26, 10:10=A0am, Tobias Burnus <bur...@net-b.de> wrote:
>
> > For curiosity: What do you mean by outperform? gfortran vs. xlf on the
> > same computer or xlf on PowerMac vs. gfortran on a (more modern)
> > Intel/AMD system?
>
> I mean on the same Quad PowerMac G5 box running OSX (10.4.11). =A0And
> "outperforms" here just doesn't mean "speed". =A0Even my old version of
> XLF is a much more robust Fortran-95/OpenMP compiler than the current
> Gfortran so I don't have to waste time chasing/working-around compiler
> bugs. =A0Also, the latest XLFs have implemented all of F2003 and most
> (if not all) of F2008.
>

Given that a search for Greynold in GCC Bugzilla finds
4 bug reports from you and a comment in a fifth, and
given that all of these reports date from mid 2007, I suspect
your assessment concerning F95/OpenMP may not have
been based on a very current gfortran.  Of course, the lack
of specifying a version number for gfortran hampers pinning
down what 'current' means.  Of course, if everyone that uses
gfortran drop $1000 to $4000 into a gfortran development
fund, then perhaps the gfortran developers could afford to
make it a better compiler in a more timely fashsion.  Finally,
bugs and performance issues are likely to go unfixed if the
individual experiencing said problem refuses to report them.

PS:  One of your bug reports was fixed with an hour of the
report, two bugs took 2 days to fix, and the 4th took 6 weeks
to fix.  I'll leave it up to you to determine if this was good or
poor user support from a bunch of unpaided hacks.

--
steve

On Aug 26, 1:51=A0pm, steve <kar...@comcast.net> wrote:
> your assessment concerning F95/OpenMP may not have
> been based on a very current gfortran. =A0Of course, the lack
> of specifying a version number for gfortran hampers pinning
> down what 'current' means. =A0Of course, if everyone that uses
> gfortran drop $1000 to $4000 into a gfortran development
> fund, then perhaps the gfortran developers could afford to
> make it a better compiler in a more timely fashsion. =A0Finally,
> bugs and performance issues are likely to go unfixed if the
> individual experiencing said problem refuses to report them.
>
> PS: =A0One of your bug reports was fixed with an hour of the
> report, two bugs took 2 days to fix, and the 4th took 6 weeks
> to fix. =A0I'll leave it up to you to determine if this was good or
> poor user support from a bunch of unpaided hacks.
>
> --
> steve

I currently use 4.4.4.  I was using 4.5.0 until MacPorts messed things
up during a failed 4.5.1 installation (nobody currently provides
binaries for PPC OSX).  I occasionly try the latest 4.6 but uually hit
an ICE.

I report bugs when there is time but estimate I trip over about 10
times more than I report.  I AM thankful they do get fixed eventually
by somebody. However, I have always been shocked by how GCC can
continually move on to a new version with SO MANY "regressions" still
open.  When I was a commercial sofware developer, no release went out
with any known bugs in it.

Al

Al Greynolds wrote:
> I report bugs when there is time but estimate I trip over about 10
> times more than I report.  I AM thankful they do get fixed eventually
> by somebody.

As said by Steve: It would help tremendously if you could send bug reports.

 > However, I have always been shocked by how GCC can
> continually move on to a new version with SO MANY "regressions" still
> open.  When I was a commercial sofware developer, no release went out
> with any known bugs in it.

Well, getting to zero bugs (or even zero regressions) it very difficult 
if one has to support many platforms. For gfortran the goal is to have 
zero *regressions* for every release. Going to zero *bugs* is kind of 
impossible - for instance, gfortran has since about 5 years a bug report 
asking for coarray support ...

 From the looking at Bugzilla, there seems to be currently only few bug 
reports tickling in - mostly bugs about new Fortran 2003 features. I 
agree that there are some older bugs which should be fixed. That is also 
happening, but during the first part of the development cycle of the new 
compiler, the work mostly concentrates on the new features. As the 
compiler seems to work for the most users/programs, the pressure to new 
Fortran 2003/2008 seems to be larger than to fix some corner cases. 
(Which are not forgotten and also get slowly but steadily fixed.)

Also "regressions" can be serious or not; I regard the priority as lower 
if the bug involves rare combinations of options, the compiler crashes 
for invalid code, or the performance for a certain program is 5% lower. 
I am sure most users do not want to see the release blocked for months 
because of such regressions. If everyone had to wait for the last 
regression to be fixed, one could not release the compiler at all. In 
the last stage, no larger non-regression bug fixes or features are 
allowed to enter, leading effectively to a stop of gfortran development 
for months while waiting for regression fixes for rare hardware 
platforms, which may lack a maintainer or have only few maintainers.

And besides: It is better to release a new version which fixes many bugs 
- even though some bugs are still present.

Tobias

> However, I have always been shocked by how GCC can continually move on
> to a new version with SO MANY "regressions" still open.  When I was a
> commercial sofware developer, no release went out with any known bugs
> in it.

I do not thing that's a very good strategy except for small products or
products with small user base. Or if you're into provable software.

Fixing bugs introduces new code, which has a risk of introducing new
bugs. So, it's better to have identified, low-impact shortcomings than a
possibly lurking high-impact bug that just hasn't been exposed by testing
yet.

-- 
FX

FX <coudert@alussinan.org> wrote:

> > However, I have always been shocked by how GCC can continually move on
> > to a new version with SO MANY "regressions" still open.  When I was a
> > commercial sofware developer, no release went out with any known bugs
> > in it.
> 
> I do not thing that's a very good strategy except for small products or
> products with small user base. Or if you're into provable software.
> 
> Fixing bugs introduces new code, which has a risk of introducing new
> bugs. So, it's better to have identified, low-impact shortcomings than a
> possibly lurking high-impact bug that just hasn't been exposed by testing
> yet.

Particularly because often the bugs are there because the context is a
subtle one, which makes that context prone to mistakes. The focus on
what went wrong can distract from what else can go wrong. Especially as
the language evolves changing the context.

-- 
Bill Clodius
los the lost and net the pet to email