Getting the most for a process.

[George Seibel]

In article <593 at cogent.UUCP> doug at cogent.UUCP (Doug Perlich) writes:
>I have recently become interested in having an application program run as fast
>as possible!  (Sound familiar)?

Yup.

>What I am interested in is how can a program get a higher priority at run time.
>More exactly what other methods are there to get screaming performance out of
>a UNIX machine.
>As I understand it only root can use a negative nice to make a program run
>faster, are there ways of dedicating a processor (w/ or wo/ a multiprocessor)?
>
>I am mainly interested in a multi-user system.
>
>It seems to me the answer is no because then every programmer would try this
>in his/her code and the system would halt.

Even if you get 100% of the machine, you only go as fast as the machine
will run your program.  Here's what to do if you *really* want to go fast:

1) Choose the best algorithm.  e.g. Quicksort beats Bubble sort...
2) profile the application with representative inputs.  The usual
   scenario is:

   cc -p applic.c -o applic  [could be f77 or pc instead of cc]
   applic                    [will produce file "mon.out"]
   prof applic > prof.out
   
   Now look in prof.out.  This should tell you where your program is
   spending its time.  Look at those parts of the code.  Are they doing
   unnecessary work?   Find a hacker and ask how to make it go faster.
   Bringing frequently-called functions inline is usually a win.
   If you're doing a lot of I/O, can it be brought in-core?  Can you
   use binary files instead of formatted files?   Check out the options
   on your compiler.  Try the optimisation options.  Make sure you are
   not using runtime bounds checking.   Are you even using a compiler?
   If the application is written in an interpreted language, there
   probably is no profiler or optimiser.  Consider rewriting.

What if you aren't a programmer, or you don't have the source code?

3) Buy a faster computer.  (This is also a valid solution if you *are*
   a programmer)

George Seibel, UCSF