MP benchmarking?
At150bogomips
to the main intended uses for such systems (i.e., identical
resource-type-usage, extremely independent multiprogram
workloads)? (Such uses seem much more suited to clusters with
inexpensive interconnects.)
The communication latency and bandwidth advantages of an MP
system would seem not to be adequately tested with such a
benchmark. OTOH, a simple time-to-solution for a complex,
parallelizable problem would not address the potential for
more efficient resource usage, especially with SMT and even CMP
systems. (E.g., running a bandwidth intensive program with a
cache-friendly program on an SMT system might give each program
90% of single-thread performance, one processor providing the
performance 'equivalent' to 1.8 processors.) I suspect HPC
benchmarks measure how much parallelism can be exploited in a
single program but do not address the potential for resource
sharing. For some problem mixes, a 32P Power4 system might offer
nearly equivalent (or better??) throughput relative to a 16P HP
system (half the cores disabled) and a 16P 'standard' system--at
somewhat lower cost.
I hope that someone will correct my ignorance
Paul A. Clayton
just a former McD.'s grill worker and technophile
McCalpin
At150bogomips <at150b...@aol.com> wrote:
>Is the SPECrate-style benchmarking of MP systems representative
>to the main intended uses for such systems (i.e., identical
>resource-type-usage, extremely independent multiprogram
>workloads)? (Such uses seem much more suited to clusters with
>inexpensive interconnects.)
SPECrate has some good qualities and some poor qualities.
Like any benchmark, it is a tradeoff between accuracy and
comprehensibility.
Mostly what SPECrate shows is performance impact of contention
for the main memory bandwidth (and for any shared caches).
The test methodology maximizes the bandwidth contention,
and the timing of the benchmarks on a one-at-a-time basis
means that the detailed results contain a lot of information.
My favorite is 171.swim, which is the highest user of bandwidth
(among systems with caches >2 MB). If I remember the numbers
correctly, on a machine with a write-allocate cache strategy,
each instance of 171.swim moves about 478 GB of data (neglecting
cache conflicts, which vary depending on page coloring and
compiler array padding), so it is possible to estimate
sustainable memory bandwidth from the 171.swim rate results.
>The communication latency and bandwidth advantages of an MP
>system would seem not to be adequately tested with such a
>benchmark.
This is a known deficiency, and is one of the reasons that
the SPEComp benchmark suite was developed. The current
version(s) of the SPEComp suite are not particularly good
(which is why I pulled IBM out of participation in the
development of SPEComp two years ago), but the intent is
fine, and it is possible that the set of codes used in the
suite may someday be more sensible....
>[...] For some problem mixes, a 32P Power4 system might offer
>nearly equivalent (or better??) throughput relative to a 16P HP
>system (half the cores disabled) and a 16P 'standard' system--at
>somewhat lower cost.
I think you meant a "16P HPC" system. "HP" usually refers
to that other computer manufacturer.
I am confused by what you wrote above.... Of course the 32p
system offers better throughput than the 16p HPC system -- the
32p system has all of the cache and memory resources of the 16p
system, but has 16 more cores to make the compute part run faster.
Of course, the 32p system is very seldom twice as fast as the 16p
HPC config -- the performance ratio ranges all the way from 1x
(my 171.swim example) to very close to 2x (LINPACK HPC), with
examples to be found at nearly every intermediate point.
--
John D. McCalpin, Ph.D. mcca...@austin.ibm.com
Senior Technical Staff Member IBM POWER Microprocessor Development
"I am willing to make mistakes as long as
someone else is willing to learn from them."
Paul Repacholi
> In article <20020608095700...@mb-bh.aol.com>,
> At150bogomips <at150b...@aol.com> wrote:
> >Is the SPECrate-style benchmarking of MP systems representative to
> >the main intended uses for such systems (i.e., identical
> >resource-type-usage, extremely independent multiprogram workloads)?
> >(Such uses seem much more suited to clusters with inexpensive
> >interconnects.)
> SPECrate has some good qualities and some poor qualities. Like any
> benchmark, it is a tradeoff between accuracy and comprehensibility.
> Mostly what SPECrate shows is performance impact of contention for
> the main memory bandwidth (and for any shared caches). The test
> methodology maximizes the bandwidth contention, and the timing of
> the benchmarks on a one-at-a-time basis means that the detailed
> results contain a lot of information.
One thing I have been wondering about, is if it is worth having a
`SPECsize' set of tests. Problem that are measured with a range of
data sizes so as to not only be sure of exceding any cache, but to
also be sure to force the system to have to have the data across a
large number of the local memory islands that are becoming the norm.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Greg Lindahl
Paul Repacholi <pr...@prep.synonet.com> wrote:
>One thing I have been wondering about, is if it is worth having a
>`SPECsize' set of tests. Problem that are measured with a range of
>data sizes so as to not only be sure of exceding any cache, but to
>also be sure to force the system to have to have the data across a
>large number of the local memory islands that are becoming the norm.
The late, lamented SPEChpc benchmark suite took this approach, and
it's a fine thing for supercomputing. I've always suspected that one
reason that SPECfp wasn't much like real programs was that SPEC tends
to request a particular working set, instead of attempting to find out
how people are actually using workstations today.
Amusingly enough, for parallel programs it's the small data size
that's hardest.
greg
At150bogomips
>I think you meant a "16P HPC" system. "HP" usually refers
>to that other computer manufacturer.
Yes. (Oops. I thought that seemed wrong but was slothful and
did not bother determining the correct name. Mea culpa.)
>I am confused by what you wrote above.... Of course the 32p
>system offers better throughput than the 16p HPC system -- the
>32p system has all of the cache and memory resources of the 16p
>system, but has 16 more cores to make the compute part run faster.
>Of course, the 32p system is very seldom twice as fast as the 16p
>HPC config -- the performance ratio ranges all the way from 1x
>(my 171.swim example) to very close to 2x (LINPACK HPC), with
>examples to be found at nearly every intermediate point.
I was thinking of two groups of applications, one extremely bandwidth-
limited, the other very compute-limited. For the bandwidth-limited
applications, the HPC system would be attractive (best performance/
price), while the other group would prefer the 'standard' system. Yet
if the applications were run on alternate processors of each die on a
'standard' 32P system, the bandwidth-limited applications might get
90+% of the performance of the 16P HPC system while the compute-
limited applications might get an even greater fraction of the performance
of a 16P 'standard' system. I.e., bandwidth and compute resources
would be used more efficiently by sharing. If the modest loss in
performance was acceptable, somewhat greater performance/price might
be gained by the two application groups sharing a 32P system.
(IIRC, the price premium for the HPC systems was greater than 10%
and because of sharing the 32P system cost is significantly less than
twice that of the 16P system.)
This may or may not be an unrealistic situation. (Especially since
an extremely compute-limited application would likely be suited to
a cluster.)
(Thank you for your response--and for your freely available papers!)
McCalpin
At150bogomips <at150b...@aol.com> wrote:
>I was thinking of two groups of applications, one extremely bandwidth-
>limited, the other very compute-limited. For the bandwidth-limited
>applications, the HPC system would be attractive (best performance/
>price), while the other group would prefer the 'standard' system
Clearly, this is how the systems are intended to be positioned.
The workloads with the highest bandwidth requirements are expected
to be most cost-effective on the HPC (single core) config, while
the workloads with low bandwidth requirements are expected to be
most cost-effective on the Turbo (dual core) config. The crossover
depends on pricing issues, and I am not familiar enough with our
current pricing strategy for the single-core config to make any
detailed comments.
>. Yet
>if the applications were run on alternate processors of each die on a
>'standard' 32P system, the bandwidth-limited applications might get
>90+% of the performance of the 16P HPC system
More like 100%, or perhaps a slight bit better, since the O/S can
run on the extra processors that are unused by the applications.
>while the compute-
>limited applications might get an even greater fraction of the performance
>of a 16P 'standard' system. I.e., bandwidth and compute resources
>would be used more efficiently by sharing. If the modest loss in
>performance was acceptable, somewhat greater performance/price might
>be gained by the two application groups sharing a 32P system.
Few customers seem to be willing to share in this way, though
there are clearly cases where it makes sense.
Of course, IBM would be happy to sell you either config (or
both) so that you could do direct testing on your workloads.
Jan C. Vorbrüggen
> >system would seem not to be adequately tested with such a
> >benchmark.
> This is a known deficiency, and is one of the reasons that
> the SPEComp benchmark suite was developed. The current
> version(s) of the SPEComp suite are not particularly good
> (which is why I pulled IBM out of participation in the
> development of SPEComp two years ago), but the intent is
> fine, and it is possible that the set of codes used in the
> suite may someday be more sensible....
I agree about the intent. What little I have seen from the effort
seemed reasonable to me - in particular, spend as little effort on
inserting OMP directives as reasonable, as one would think that that
is the mode people do it in practice. AFAIK facerec didn't get in
because it prooved to difficult to get the rights to a reasonably
sized data set...John Henning, are you there?
So could you tell us in a little more detail, John (McC.), what you
don't like about SPEComp?
Jan
McCalpin
Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbr...@mediasec.de> wrote:
>> >The communication latency and bandwidth advantages of an MP
>> >system would seem not to be adequately tested with such a
>> >benchmark.
>> This is a known deficiency, and is one of the reasons that
>> the SPEComp benchmark suite was developed. The current
>> version(s) of the SPEComp suite are not particularly good
>> (which is why I pulled IBM out of participation in the
>> development of SPEComp two years ago), but the intent is
>> fine, and it is possible that the set of codes used in the
>> suite may someday be more sensible....
>
>don't like about SPEComp?
I reviewed the codes in SPECfp2000, and asked a number of
colleagues for their opinions about the relevance of the codes
being used.
Of the 14 codes in SPECfp2000, I concluded that
six were definitely no representative of what
people currently purchase computers to run
two might be representative of economically
important application areas, but this needs
more detailed evaluation
two might be representative of economically
unimportant application areas, but I don't
really care if the are representative or not
four codes were in areas that I could not evaluate
or find experts to evaluate
Because of this, I really did not want SPEComp to be based on the
CFP2000 codes. Unfortunately another vendor made effective use
of its bureaucratic talents to take control of the effort and
drive it forward with zero concern for whether the suite actually
represented what people purchase computers to run. The trouble
with bureaucracies is that after a while they exist in order to
provide jobs for bureaucrats, and not in order to serve the
original function of the organization....
At that point (June 2000) I looked at the timeline and decided
that I did not want to spend the next several years of my life
trying to bludgeon SPEC into doing what I could do myself in a
few months work. Of course, the workloads that I have put
together for this purpose are proprietary and confidential....
Wesley Jones
alternative to running benchmarks using your parallel HPC applications
when purchasing a system.
http://www.spec.org/hpg/omp2001/
Here are some features and futures:
The SPEC OMP benchmark suites have just completed the second iteration
of development with the release of SPEC OMPL2001 suite which should scale
up to 128 or 256 CPU systems.
http://www.spec.org/hpg/omp2001/press/omplrelease.html
The SPEC OMP benchmarks are based on an industry standard API for parallel
programming, OpenMP, so they will compile, run and validate on any system
with a reasonable compiler and OpenMP library.
The SPEC OMP benchmark tool set is based on the SPEC CPU2000 benchmark tool
set, so the tools run on all major platform. Source is included with this
tool set so that they may be compiled for unsupported platforms.
The SPEC OMP benchmark run rules are open and the review process helps to
ensure the quality of the benchmark results posted to the web. The multi-
vendor participation helps to ensure the fairness of the rules and the
process. We have multiple academic and research members, one which
participates very actively, and would like to have more active members.
The SPEC OMP benchmark suite results for reviewed and accepted submissions
are available in a public arena.
The SPEC OMP benchmark suites are made up of multiple application level
benchmarks giving a better idea of the performance of a system on an
ensemble of applications than a single application level benchmark would
provide. If a particular set of application level benchmarks are of
more interest to an institution than another set, a simple metric can be
defined using the geometric mean of the ratios of the individual benchmarks
of interest.
In addition to providing a computer system benchmark suite, the SPEC OMP
benchmark suites provide a benchmark for OpenMP. In a relatively short
period of time with a relatively small amount of man power we have shown
that OpenMP based parallel application suites can be developed and be both
functionally and performance portable across a variety of architectures
and O/S's.
We are interested in MPI also, but it is much harder to parallelize code
using MPI and so the application level benchmarks were parallelized using
OpenMP. We are, however, working on HPC2002 which will include a few
applications and they will run using MPI and OpenMP.
We are working towards including/replacing individual benchmarks with more
relevant application level benchmarks and market areas. To this end we
need help that could be achieved through broader participation. It is not
easy to identify and obtain the most relevant application level benchmarks,
much less create data sets and shoe horn the application into an environment
that allows many vendor's to compile, run and validate the benchmark once
created. However, we have found that making the benchmarks relatively easy
to run (even if they take a long time to run) is the only way to get results
from multiple vendors and/or institutions.
If you have suggestions for inclusion of specific applications and would be
willing to help out, you can email me, wes...@sgi.com, or contact SPEC
http://www.spec.org/spec/contact.html
Also, if you have questions that should be addressed in our FAQ, but are not,
please contact us.
http://www.spec.org/hpg/omp2001/docs/faq.html
WEs
Wesley B. Jones, PhD wes...@sgi.com
SGI, Boulder, CO Phone: (303)-448-1165
Performance Engineering, Tech Lead FAX:
SPEC HPG continues to work toward making the SPEC OMP benchmark suite as
robust and relevant as possible. Toward this end we
Greg Lindahl
> We are, however, working on HPC2002 which will include a few
> applications and they will run using MPI and OpenMP.
Cool. It'll be fun to see if shared memory machines run the MPI
versions faster than the OpenMP versions.
>We are working towards including/replacing individual benchmarks with more
>relevant application level benchmarks and market areas.
Good. Why don't you start by listening to what John McCalpin has to
say? I'm not very motivated to help in a modest way if John's
excellent input doesn't go far.
greg
Wesley Jones
We have listened to John, both specifically and generally.
Here are some examples:
We removed galgel from the OMPL2001 suite.
We are trying to replace ammp with a chemistry application or multiple chemistry
applications of greater relevance.
We are trying to get the WRF weather model in HPC2002 and then into OMP benchmarks.
This in itself is not easy.
We are trying to get an unstructured fluids application.
I am sorry that IBM feels that it is better to not participate. We would certainly
welcome the help of someone who could help get applications, evaluate applications,
integrate them into the tool set and report results. However, at this time, I don't
think that IBM really wants to report benchmarks on their full system with HPC
applications.
Here's one example that I am familiar with.
The MM5 Weather model benchmark numbers from MM5/MPP performance data page.
Performance measured in MFlop/sec
#CPU IBM P690 Power4 SGI Origin 3800
1.3Ghz 600 MHz
Performance Performance
16 8248 5015
32 13701 10302
64 19668
Given the price of the P690 and that the system has 4 1/3 times the Peak Flops per
processor and much better L1 to L2 peak bandwidth per processor and much better peak
memory bandwidth per processor averaged over the system, one would think that it
should be running an application level benchmark more than ~30% better than the
Origin 3800. But it is not, at least in this case.
Of course MM5 is just one weather application and this is just one data set.
>
> greg
McCalpin
>
>I am sorry that IBM feels that it is better to not participate.
The issue is primarily one of resource allocation. Getting anything
done via the SPEC organization has proven to be incredibly slow and
painful, and at the time I pulled us out, we did not have anyone
with the right temperment and technical skills that we were willing
to commit to this project.
I am delighted to see that someone of your technical competence
is involved --- this is a good incentive for me to try to have
someone allocated to the SPEComp project.
>[...] However, at this time, I don't
>think that IBM really wants to report benchmarks on their full system with HPC
>applications.
Like the IDC benchmark, SPEComp poses ethical difficulties.
Our SPEComp benchmark results are outstanding (I don't think
that I can go into any more detail), but that does not make the
codes any more (or less) relevant to customer applications.
Clearly there is motivation to promote these results aggressively
if what you are interested in is short-term marketing advantage.
On the other hand, if what you are interested in is "better
benchmarks", it would be wise to avoid getting committed to yet
another mediocre benchmark that will just confuse the picture in
the long term.
When I pulled IBM out of SPEComp 24 months ago, the attitude of
many members of the SPEC CPU subcommittee was:
"We will work two years on the first version, and three
years on the second version, and three years on the third
version, and by the time we ship that third revision, it
will be pretty good."
I could not justify committing 8 person years of effort into a
project that would end up being 90% bureaucracy and 10% technical
benchmarking.
Jan C. Vorbrüggen
> Our SPEComp benchmark results are outstanding (I don't think
> that I can go into any more detail), but that does not make the
> codes any more (or less) relevant to customer applications.
> Clearly there is motivation to promote these results aggressively
> if what you are interested in is short-term marketing advantage.
There are alternatives. You can still publish those outstanding results,
but in your (the collective IBM) marketing literature not promote them
agressively; instead, be even-handed and put those results in their place.
If they are indeed outstanding, it will be quite convincing to customers
in general, I believe, if the performance leader says, "well, those are
our results, but we see them as having limited value because ...."
(whatever you technical concerns with SPEComp are, John).
> On the other hand, if what you are interested in is "better
> benchmarks", it would be wise to avoid getting committed to yet
> another mediocre benchmark that will just confuse the picture in
> the long term.
That would be OK if you - IBM - had the will and the wherewithall to
go it alone and build a credible alternative. I don't think that is
realistic, for a number of reasons. Just staying on the side-lines and
afterwards saying, "I told you so" gives the impression of being
unprofessional (careful wording here - I'm sure it wasn't an easy decision
to make). I am convinced that IBM could have made a difference to SPEComp,
as it is quite active in SPEC elsewhere (Kaivalya still is president, right?).
Not having the right person available to do the job is of course
an added difficulty.
Jan
Alexis Cousein
> Like the IDC benchmark, SPEComp poses ethical difficulties.
> Our SPEComp benchmark results are outstanding (I don't think
> that I can go into any more detail), but that does not make the
> codes any more (or less) relevant to customer applications.
> Clearly there is motivation to promote these results aggressively
> if what you are interested in is short-term marketing advantage.
> On the other hand, if what you are interested in is "better
> benchmarks", it would be wise to avoid getting committed to yet
> another mediocre benchmark that will just confuse the picture in
> the long term.
Mhh -- by that rationale, of course, given that you can't buy
1p p690s, and that most people buying larger Regattas may
want to use more than one processor, IBM should have kept the
SPEC2000 scores to themselves until SPECrate numbers were available
(and/or, arguably, SPEComp -- it's not that the SPEComp codes
are any *worse* than the "normal" SPECint/fp codes wrt
your criticisms, and the fact they use OpenMP and scale
moderately well makes them rather more than less interesting).
--
<these messages express my own views, not those of my employer>
Alexis Cousein Senior Systems Engineer
SGI Belgium and Luxemburg a...@brussels.sgi.com
McCalpin
>afterwards saying, "I told you so" gives the impression of being
>unprofessional
That is why I was very careful to say "I told you so" *before*
SPEComp2000 was developed, rather than *after*.
I may not have told you personally, but my statements have been
clear and consistent for over two years now (which, by the way,
long pre-dates any opportunity I would have had to determine
whether or not these codes would run well on IBM POWER4
platforms).
McCalpin
Alexis Cousein <a...@brussels.sgi.com> wrote:
>McCalpin wrote:
>> Like the IDC benchmark, SPEComp poses ethical difficulties.
>> Our SPEComp benchmark results are outstanding (I don't think
>> that I can go into any more detail), but that does not make the
>> codes any more (or less) relevant to customer applications.
>
>1p p690s, and that most people buying larger Regattas may
>want to use more than one processor, IBM should have kept the
>SPEC2000 scores to themselves until SPECrate numbers were available
Unfortunately, that was not my call. We had SPECrate numbers
available at launch, and the product management/marketing
folks chose not to allow them to be released.
>(and/or, arguably, SPEComp -- it's not that the SPEComp codes
>are any *worse* than the "normal" SPECint/fp codes wrt
>your criticisms, and the fact they use OpenMP and scale
>moderately well makes them rather more than less interesting).
Again, it is an issue of resource allocation. I think that
the SPEComp2000 codes have some useful features and provide
some insights into performance. However, what they provide
is by no means justifiable by the huge cost of being involved
in their development, maintainance, tuning, support, etc,
which is measured in the many millions of $$$ over the 5-8
years required to turn the suite into something that is actually
moderately representative of what people purchase computers
to run.
At150bogomips
>In article <20020610043906...@mb-fr.aol.com>,
>At150bogomips <at150b...@aol.com> wrote:
>>. Yet
>>if the applications were run on alternate processors of each die on a
>>'standard' 32P system, the bandwidth-limited applications might get
>>90+% of the performance of the 16P HPC system
>
>More like 100%, or perhaps a slight bit better, since the O/S can
>run on the extra processors that are unused by the applications.
Ah, but the other (cache-friendly/compute-intensive) group of
applications running on the alternate core would nibble up some
(guessing <10%) of the bandwidth.
>>while the compute-
>>limited applications might get an even greater fraction of the performance
>>of a 16P 'standard' system. I.e., bandwidth and compute resources
>>would be used more efficiently by sharing. If the modest loss in
>>performance was acceptable, somewhat greater performance/price might
>>be gained by the two application groups sharing a 32P system.
>
>Few customers seem to be willing to share in this way, though
>there are clearly cases where it makes sense.
Internal politics (how dare you allow Professor N to use some of my
computing resources!), administrative nightmare (selecting applications
for most efficient use of resources), or lack of imagination?
>Of course, IBM would be happy to sell you either config (or
>both) so that you could do direct testing on your workloads.
If I had $0.5 million . . .
Rupert Pigott
news:20020615041350...@mb-mm.aol.com...
[SNIP]
> If I had $0.5 million . . .
... I wouldn't waste it on a computer ...
Cheers,
Rupert
Carlie Coats
[big snip...]
> We are trying to get the WRF weather model in HPC2002 and then into
> OMP benchmarks.
> This in itself is not easy.
[snip...]
> Here's one example that I am familiar with.
>
> The MM5 Weather model benchmark numbers from MM5/MPP performance data page.
> Performance measured in MFlop/sec
[snip... IBM performance not what one might expect]
> Of course MM5 is just one weather application and this is just one data set.
This is true, but...
It is probably the most widely used meteorology application.
I am afraid it is typical of codes that are written by meteorologists
who are not sophisticated in terms of the characteristics of efficient
(or numerically stable!) codes. At least it is not the grotesquerie
put out by certain botanists I won't name (been there, had to fix that!)
And on this benchmark, the IBM POWER series does suffer more from some
of the bad coding practices: since the processor-internals deal with
64-bit reals and only convert to/from 32-bit on load/store, the
"expensive" operations (divide, square root, transcendental functions)
are relatively more expensive than they are on machines that have "true"
32-bit-float arithmetic. Intel x86's that use 80-bit floating point
internals suffer from this same penalty.
And the MM5 code is egregious in this use of expensive operations (some
of it necessary, due to power-laws in thermodynamics that demand lots
of real-exponent calculations). Others, like random X**2.0 and Y**0.5
constructions and the divides in the following taken from the MRFPBL
routine, are unnecessary:
CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
(Note that CHI at the first of these lines is a dead variable after
it is used in the second of these. Note also that MRFPBL is adapted
from yet another meteorological model, so we have a case where one
set of metorologists wrote it, and another approved it for borrowing
into their model.)
fwiw.
Carlie J. Coats, Jr. co...@emc.mcnc.org
MCNC-Environmental Modeling Center phone: (919)248-9241
North Carolina Supercomputing Center fax: (919)248-9245
3021 Cornwallis Road P. O. Box 12889
Research Triangle Park, N. C. 27709-2889 USA
"My opinions are my own, and I've got *lots* of them!"
Greg Lindahl
Carlie Coats <co...@hilbert.emc.mcnc.org> wrote:
>And the MM5 code is egregious in this use of expensive operations (some
>of it necessary, due to power-laws in thermodynamics that demand lots
>of real-exponent calculations). Others, like random X**2.0 and Y**0.5
>constructions and the divides in the following taken from the MRFPBL
>routine, are unnecessary:
>
> CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
> RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
Charlie,
This is a compiler quality issue. A compiler can always optimize
"X**2.0" and "Y**0.5", and most compilers have a "fuzzy math" which is
on by default in -O which will turn the above 2 lines to at least:
CHI=XLV*XLV*QMEAN/(CP*RV*TMEAN*TMEAN) ! 1 divide, not 4
RI=(1.+ALPH)*(RI-G*G/(SS*TMEAN*CP)*((CHI-ALPH)/(1.+CHI))) ! 2 divides, not 4
The first optimization can't be done at compile-time if the 2.0 is
hidden in a variable, but that can be done in a run-time-library. I
haven't run into one that does that yet. The second optimization needs
to get turned off for your bit-exact checking (we are talking
meterology, after all), but can be left on in production as long as it
doesn't cause over/underflow.
-- greg
Niels Jørgen Kruse
(Carlie Coats) skrev:
> And the MM5 code is egregious in this use of expensive operations (some
> of it necessary, due to power-laws in thermodynamics that demand lots
> of real-exponent calculations). Others, like random X**2.0 and Y**0.5
> constructions and the divides in the following taken from the MRFPBL
> routine, are unnecessary:
>
> CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
> RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
Cute. However, if this isn't speedcritical I don't think you can blame the
author *too* much for optimizing for number of keystrokes. Alternatively, if
this is very old code, it could be optimized for codesize and/or minimum
number of registers.
> (Note that CHI at the first of these lines is a dead variable after
> it is used in the second of these. Note also that MRFPBL is adapted
> from yet another meteorological model, so we have a case where one
> set of metorologists wrote it, and another approved it for borrowing
> into their model.)
Is CHI close to 0?
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark
Terje Mathisen
> And the MM5 code is egregious in this use of expensive operations (some
> of it necessary, due to power-laws in thermodynamics that demand lots
> of real-exponent calculations). Others, like random X**2.0 and Y**0.5
> constructions and the divides in the following taken from the MRFPBL
> routine, are unnecessary:
>
> CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
> RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
Ouch!!!
Is this typical?
Are those lines in an inner loop, or even a second-level loop somewhere?
If so, then I really hope the compiler is allowed to convert divisions
into reciprocal multiplication.
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Carlie Coats
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
> Carlie Coats wrote:
> > And the MM5 code is egregious in this use of expensive operations (some
> > of it necessary, due to power-laws in thermodynamics that demand lots
> > of real-exponent calculations). Others, like random X**2.0 and Y**0.5
> > constructions and the divides in the following taken from the MRFPBL
> > routine, are unnecessary:
> >
> > CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
> > RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
>
> Ouch!!!
>
> Is this typical?
>
> Are those lines in an inner loop, or even a second-level loop somewhere?
>
> If so, then I really hope the compiler is allowed to convert divisions
> into reciprocal multiplication.
>
> Terje
There are enough of these that it is at least close to typical.
And other things like repeated calls to exponentials with identical
argument lists that the compiler _can't_ legally optimize away (imo),
since it can't know that repeated calls give the same result (after
all, you may be using your own funky function that is still called
EXP(), right?)
Back about three years ago, when we first got an SP, I spent about two
weeks cleaning up lots of issues like this on a previous release of
MM5, and wound up with a speedup factor of 2.36 on the SP for the
optimized code (that also gave a speedup by 1.9 for x86 Linux with
the Portland group compiler, and 1.4 for SGI IRIX).
At least I got them to replace _most_ of the X**0.5 constructs with
SQRT(X) and the X**2.0 with X**2 for MM5 Version 3. But lots of the
code is still lousy and there is not much interest in fixing it, even
though it is probably the most widely used research/production met model
in the world...
-- Carlie
Greg Lindahl
Carlie Coats <co...@hilbert.emc.mcnc.org> wrote:
>There are enough of these that it is at least close to typical.
>And other things like repeated calls to exponentials with identical
>argument lists that the compiler _can't_ legally optimize away (imo),
>since it can't know that repeated calls give the same result (after
>all, you may be using your own funky function that is still called
>EXP(), right?)
There's legal and there's legal. In C, if you include the system
header file, you are required to use the system functions, so those
header files can #define things to __builtin_funcname, and the
compiler can specially optimize that. In Fortran, you can at least
have a command-line switch; I don't recall the exact rules for
intrinsics. Of course exp() isn't an intrinsic, it is the operator **,
and MM5 is written in Fortran, so I'm not sure what you meant with
that example...
greg
Terje Mathisen
> There are enough of these that it is at least close to typical.
> And other things like repeated calls to exponentials with identical
> argument lists that the compiler _can't_ legally optimize away (imo),
> since it can't know that repeated calls give the same result (after
> all, you may be using your own funky function that is still called
> EXP(), right?)
>
> Back about three years ago, when we first got an SP, I spent about two
> weeks cleaning up lots of issues like this on a previous release of
> MM5, and wound up with a speedup factor of 2.36 on the SP for the
> optimized code (that also gave a speedup by 1.9 for x86 Linux with
> the Portland group compiler, and 1.4 for SGI IRIX).
If we take 2X as a useful average, using those optimizations would
immediately double the available cpu power for running MM5. Why do I
have a feeling that this is perceived as less interesting than the write
the purchase order for Yet Another SuperComputer?
> At least I got them to replace _most_ of the X**0.5 constructs with
> SQRT(X) and the X**2.0 with X**2 for MM5 Version 3. But lots of the
> code is still lousy and there is not much interest in fixing it, even
> though it is probably the most widely used research/production met model
> in the world...
Sad, but not too surprising. I see the same for oil codes.
Jan C. Vorbrüggen
> And other things like repeated calls to exponentials with identical
> argument lists that the compiler _can't_ legally optimize away (imo),
> since it can't know that repeated calls give the same result (after
> all, you may be using your own funky function that is still called
> EXP(), right?)
In Fortran, the compiler knows at compile time whether EXP refers to the
intrinsic function (which it knows to be PURE) or an external function (of
which it might or might not know additional information such as its purity).
In ANSI C, I believe the compiler is free to assume and even substitute inline
code for the content of the standard library, at least when the normal
include files are being referenced.
There remains, of course, the difference between X**2. and X**2.
Jan
Greg Lindahl
Jan C. Vorbrüggen <jvorbr...@mediasec.de> wrote:
>There remains, of course, the difference between X**2. and X**2.
I take it that you mean X**2 and X**2. ? If so, if you know of any
compilers that don't know how to convert the 2nd to the 1st, please
let us know so we can point and laugh. Seriously.
greg
Jan C. Vorbrüggen
> I take it that you mean X**2 and X**2. ?
I'd say that's what I wrote...
> If so, if you know of any compilers that don't know how to convert the
> 2nd to the 1st, please let us know so we can point and laugh. Seriously.
IIRC, the semantics of the language forbid that translation.
Jan
Bernd Paysan
>> >There remains, of course, the difference between X**2. and X**2.
>> I take it that you mean X**2 and X**2. ?
>
> I'd say that's what I wrote...
;-)
>> If so, if you know of any compilers that don't know how to convert the
>> 2nd to the 1st, please let us know so we can point and laugh. Seriously.
>
> IIRC, the semantics of the language forbid that translation.
I think the semantics is that x**p-x**2.0 gives 0 when p=2.0 - that's a "no
surprise" principle. x**p has to be coded as power(x,p)=exp(ln(x)*p). If
you can tune exp(ln(x)*p) so that with p=2.0 it really equals x*x, you
should be allowed to reduce x**2.0 to x*x. Otherwise not. x**2 however is
x*x, since integer potencies are performed as repeated multiplications (by
repeated quadration).
However, with Cray's "wrong answers fast" paradigm, the compiler is allowed
converting operations to other operations that compute somewhat the same
thing, as long as it's faster.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Greg Lindahl
Jan C. Vorbrüggen <jvorbr...@mediasec.de> wrote:
>> If so, if you know of any compilers that don't know how to convert the
>> 2nd to the 1st, please let us know so we can point and laugh. Seriously.
>
>IIRC, the semantics of the language forbid that translation.
Not really. The typical fortran compiler has numerous command line
switches that cause the compiler to behave in non-standard ways,
including algebric transforms that cross parentheses, etc. With the
way MM5 uses the ** operator, this particular transform won't hurt
anything.
greg
Carlie Coats
Jan C. =?iso-8859-1?Q?Vorbr=FCggen?= <jvorbr...@mediasec.de> wrote:
: > There are enough of these that it is at least close to typical.
Wrong! Maybe for C with the standard headers, but not for
Fortran.
In fact on that very IBM SP that started off this entire thread,
the vendor offers a "less-accurate/faster" math library (roughly
15-significant-digit accuracy instead of full-double-precision
accuracy of about 17 significant digits).
That library you specify at *link time*, overriding the compiler's
built-in math library. Which library is chosen *cannot* be known
at compile time.
-- Carlie
Sander Vesik
> In article <3D0B961E...@hda.hydro.com>,
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>> Carlie Coats wrote:
>> > And the MM5 code is egregious in this use of expensive operations (some
>> > of it necessary, due to power-laws in thermodynamics that demand lots
>> > of real-exponent calculations). Others, like random X**2.0 and Y**0.5
>> > constructions and the divides in the following taken from the MRFPBL
>> > routine, are unnecessary:
>> >
>> > CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
>> > RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
>>
>> Ouch!!!
>>
>> Is this typical?
>>
>> Are those lines in an inner loop, or even a second-level loop somewhere?
>>
>> If so, then I really hope the compiler is allowed to convert divisions
>> into reciprocal multiplication.
>>
>> Terje
>
> There are enough of these that it is at least close to typical.
> And other things like repeated calls to exponentials with identical
> argument lists that the compiler _can't_ legally optimize away (imo),
> since it can't know that repeated calls give the same result (after
> all, you may be using your own funky function that is still called
> EXP(), right?)
Well, it can, if it has math-related optimisation options that say
"uses builtin math functions" or similar. Which may be usefull beyond
the simple pathological cases like this.
>
> -- Carlie
--
Sander
+++ Out of cheese error +++
Toon Moene
> Given the price of the P690 and that the system has 4 1/3 times the Peak Flops per
> processor and much better L1 to L2 peak bandwidth per processor and much better peak
> memory bandwidth per processor averaged over the system, one would think that it
> should be running an application level benchmark more than ~30% better than the
> Origin 3800. But it is not, at least in this case.
>
> Of course MM5 is just one weather application and this is just one data set.
Thanks. That explains a lot to me.
--
Toon Moene - mailto:to...@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)
Toon Moene
> > CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
> > RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
>
> Ouch!!!
>
> Is this typical?
>
> Are those lines in an inner loop, or even a second-level loop somewhere?
>
> If so, then I really hope the compiler is allowed to convert divisions
> into reciprocal multiplication.
Well, ours does (if you give it -ffast-math on the command line, to
indicate you're not interested in bit-exact results).
Toon Moene
>
> In article <3D0B961E...@hda.hydro.com>,
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
> > Carlie Coats wrote:
> > > And the MM5 code is egregious in this use of expensive operations (some
> > > of it necessary, due to power-laws in thermodynamics that demand lots
> > > of real-exponent calculations). Others, like random X**2.0 and Y**0.5
> > > constructions and the divides in the following taken from the MRFPBL
> > > routine, are unnecessary:
> > >
> > > CHI=XLV*XLV*QMEAN/CP/RV/TMEAN/TMEAN
> > > RI=(1.+ALPH)*(RI-G*G/SS/TMEAN/CP*((CHI-ALPH)/(1.+CHI)))
> >
> > Ouch!!!
> >
> > Is this typical?
> >
> > Are those lines in an inner loop, or even a second-level loop somewhere?
> >
> > If so, then I really hope the compiler is allowed to convert divisions
> > into reciprocal multiplication.
> >
> > Terje
>
> There are enough of these that it is at least close to typical.
> And other things like repeated calls to exponentials with identical
> argument lists that the compiler _can't_ legally optimize away (imo),
> since it can't know that repeated calls give the same result (after
> all, you may be using your own funky function that is still called
> EXP(), right?)
Not if you're not also saying EXTERNAL EXP somewhere in the declaration
part of the source.
g77 performs this optimisation (in GCC-terms, it treats EXP, as well as
several other INTRINSICs, as constant functions).
Toon Moene
g77 doesn't do this optimization.
Toon Moene
> > >There remains, of course, the difference between X**2. and X**2.
> > I take it that you mean X**2 and X**2. ?
> IIRC, the semantics of the language forbid that translation.
Nope. Think "mathematically equivalent" - a phrase (ab)used a lot in
the part of the Fortran Standard(s) about the interpretation of
expressions.
2.0 is an exact integer with of type real, so X**2.0 is "mathematically
equivalent" to X**2 which (according to the rules of exponentiation by
integers) might be rendered as X*X.
Greg Lindahl
Toon Moene <to...@moene.indiv.nluug.nl> wrote:
>> I take it that you mean X**2 and X**2. ? If so, if you know of any
>> compilers that don't know how to convert the 2nd to the 1st, please
>> let us know so we can point and laugh. Seriously.
>
>g77 doesn't do this optimization.
Well, then I have to laugh a little ;-)
But seriously, it's a significant win in some codes, and not that hard
to implement.
greg