performance tuning differences?

[Dan Kirkpatrick]

All valid comments in reply to my question... and I would have to be more 
specific with more tests, but I cannot comment on the code since my 
collegues are the ones designing and running the code... I just setup and 
administer the hardware and OS.  But the benchmarking they've been running 
is with the same model and code.
Not parallel or threaded, just single job per processor.  The floating 
point intensive jobs are the ones with the most differences.

>Newer kernel, better performance for most problems.

What I found odd was the same exact floating point intensive code compiled 
and run on the same exact hardware performed 20% WORSE under redhat linux 
7.1 (20% better using RH 6.2), both straight installs out of the box.

What I meant to ask, given the same code, and just looking at system OS 
configuration, is there anything to watch for?  do you find stripping down 
daemons improve performance significantly, libraries/compilers to 
avoid/suggest?  OS versions/configurations that have deep performance 
differences?

Thanks,
Dan

At 10:58 AM 8/14/2001, you wrote:
>On Tue, Aug 14, 2001 at 10:01:16AM -0400, Dan Kirkpatrick wrote:
> > Any suggestions on pure performance tuning?  Maybe some things to look 
> into?
>
>Tuning what ?
>
>Can you be more specific ?   What did you try ?  What does your profile
>information say ?    Any ideas of what might be taking up the time ?  Is 
>this a
>parallel application ?   Is it threaded ?  Is it heavy on FP or integer ?
>
> > I'm sure it's "everything" but are there any tricks that have been fairly
> > painless and resulted in good return?
>
>Use good algorithms.  Implement them well.
>
>Use the right language for the job.  And the right compiler for the language.
>
>Instrument the code, and measure, and measure, and measure.
>
>Avoid cache misses by ensuring good data locality in your algorithms (no,
>you're not running on a John von Neumann architecture - that was 20 years 
>ago -
>the memory system is hierarchical these days)
>
>Understand the problem, and how you're solving it.  Then understand your
>computing architecture.  Change the way you solve the problem to take
>advantage of your architecture.
>
> >
> > We're benchmarking different platforms, some of which with the same hard
> > drive/memory/chipset/processor speed, network inconsequential, etc... with
> > more than subtle differences.
>
>I've had an 80 MHz vector machine outperforming an almost linearly scaling
>parallel implementation of the same problem running on *seven* 180 MHz SP/2
>nodes.   This was because of cache.
>
>And I've had my PPro 150 run rings around the 180 MHz Power2 nodes on another
>problem that didn't use FP.
>
>Architectures differ - that's the beauty of it all   :)
>
> >
> > Just the difference of installing straight RedHat Linux 6.2 vs 7.1 has
> > resulted in 5%-20% performance differences depending on code, the higher
> > difference being floating point calculation code.
>
>Newer kernel, better performance for most problems.
>
> >
> > Just wondering what the consensus is for major things to try or avoid.
>
>Avoid whatever is slowing down your code - that's about as specific as
>I can get, given the level of detail in your mail   :)
>
>--
>................................................................
>:   jakob at unthought.net   : And I see the elder races,         :
>:.........................: putrid forms of man                :
>:   Jakob Østergaard      : See him rise and claim the earth,  :
>:        OZ9ABN           : his downfall is at hand.           :
>:.........................:............{Konkhra}...............:

=======================================================
Dan Kirkpatrick                   dkirk at physics.syr.edu
Computer Systems Manager
Department of Physics
Syracuse University, Syracuse, NY
http://www.physics.syr.edu/help/    Fax:(315) 443-9103
=======================================================