Newsgroups: comp.parallel
From: voss@messua.informatik.rwth-aachen.de (Martin Voss)
Subject: Results: Which performance analysis tools to use?
Organization: RWTH -Aachen / Rechnerbetrieb Informatik
Date: 5 Apr 1995 10:09:21 GMT
Message-ID: <3m95mg$kma@usenet.srv.cis.pitt.edu>

Three weeks ago, I posted some questions concerning the use of
performance analysis tools on parallel systems. Here they are 
again:

> 1. Which machine do you use?
> 2. Which programing-model are you using (message passing, shared
>    virtual memory, HPF like, ...)?
> 3. Which language do you use most (C, C++, Fortran, ...?
> 4. How do you classify yourself (novice, intermediate, expert)?
> 5. Which performance analysis tool or environment are you using?
> 6. Have these analyses already helped you to improve the performance 
>    of your code?
> 7. What are the best features of this tool?
> 8. What do you miss?
> 9. Any other comments?

Unfortunately there have not been many answers. But I guess that quite
a few people have to deal with this subject. So, in case I will receive
further comments, this summary will be updated then. 
Please, feel encouraged to contribute your experience.

I have received 7 answers. I want to thank these people very much for 
their effort. 

The comments should better be seen in context, but I do not want to mail
the whole stuff in here. Therefore, this summary is meant to give some
pointers. If someone is particularly interested, I will provide the list 
of contributers or their contributions on request.

Martin Voss

voss@pool.informatik.rwth-aachen.de

----------------------------------------------------------------------

> 1. Which machine do you use?

... KSR1, an Intel Paragon, as well as R3000, R4000, R4400, Supersparc, 
    Alpha, and other uniprocessors and/or shared memory multiprocessors
... Paragon
... Cray T3D
... SGI for developing and testing, Cray X-MP (soon C90) for running

> 2. Which programing-model are you using ...

... Message passing (Paragon)
... PVM, HPF like   (T3D)
... Shared memory   (X-MP)

> 3. Which language do you use most ...

... C
... Fortran
... C (C++ as soon as it becomes available)

> 4. How do you classify yourself

... intermediate to expert
... Intermediate
... expert

> 5. Which performance analysis tool or environment are you using?
  > 6. Have these analyses already helped you to improve ...
  > 7. What are the best features of this tool?

... I have found that for single processor runs, programs such as GPROF and
    PIXIE can help quite a bit (especially if you can read assembly code).
    ... Most people seem to assume that the only way to improve the per 
        processor performance is to use a faster processor.  It is my 
        experience that with most RISC based systems, this may not be 
        the case.  In fact, I believe that the per processor performance 
        of untuned code tends to be quite poor ...
    ... Therefore, by spending time tuning the uniprocessor code (or the 
        multiprocessor code when run using a single processor/thread) one
        can reduce the number of processors required and frequently decrease the
        communications inefficiecies enough to make the desired goal achievable.
... PARvis
    ... Ja ("yes")
    ... gute graphische Darstellung ("visualization OK")
... MPP Apprentice
    ... No.  I now know my code is rubbish though, so progress is being made!
    ... A nice interface.  Lots of buttons and menus!
... Perftrace/perfview
    ... Yes, and to catch some very subtle programming errors too.
    ... You can easily count how many memory references and FLOPs the compiler generates
        from a given loop/function.

