Just how do you test Efficiency? 
Author Message
 Just how do you test Efficiency?

I've been using Pascal for a few months now, and learning from
those with Experience on this newsgroup has been {*filter*}y useful.

But can anyone recommend to me how I can scrape up those extra marks
and improve efficiency in my programs?

Apart from the length of my code (which I guess can be misleading) I don't
know of any other methods of checking.

Are there are any efficiency test programs or does anyone have any general
tips?

Cheers!
    Jimbo



Mon, 06 May 2002 03:00:00 GMT  
 Just how do you test Efficiency?

Quote:

> Are there are any efficiency test programs or does anyone have any general
> tips?

A definite yes. Just to give you some background, I have been writing a
distributed (ie multi-machine) raytracer. Typical calculation times can
range up to several hours for complicated images, so obvioussly
efficiency is a must. About a weeks work allowed me to increase the
speed of my program by roughly a factor of between 1.5 and 2.8. So, with
that in mind, here are some tips:

1. The process you want to go through is called optimisation. Rule #1:
Premature optimisation is the root of all evil. Only look to make your
program run faster / with less memory / etc, when you're sure you have a
solid program and performance is the biggest problem.

2. The 90/10 rule: 90% of a programs time/memory/disk etc is, on the
whole, used up by 10% of it's code. This means that, on the whole, you
shouldn't fiddle about with code vainly hoping that it'll make things
faster. If you improve that 10% of the code, you may be able to double
the speed of your program. If you improve the other 90%, you'll find
you've spent hours or days of your time, improving the program speed by
tiny amounts (normally tenths of a percent).

I'll assume, for the moment, that you want to increase the speed of your
program.

3. You first need to find the 10% of code that is slowing your program
down. This is done using a tool called a profiler. Several types exist,
and it's often useful to use more than one type on the same program:
there tend to be biases on results between different sorts of profiler.

a) Call graph profiling.

These sorts of profilers normally parse your source code, and add
statements which record the value of some internal counter (normally CPU
cycle counter) at the start and end of every procedure call. You then
end up with a record of how many times each procedure was called, now
long all the invocations took, and how long on average each invocation
was.

Pros:

- Simple and normally easy to come by.
- There are normally quite a few to choose from.
- Given suitable API's, ports may exist for different systems.

Cons:

- Can often give misleading results: if a lot of data has to be
recorded, and you're recording information about small, often called
procedures, the overhead of profiling (and cache flushes due to it) can
totally skew the results.

- The profiled software often does not run at full speed. Again, this
reduces confidence in the accuracy of results.

- Does not give you an overall system view, and does not deal well with
profiling systems that consist of more than one process.
-

b) Sample profiling.

These are much more advanced. To cut a long story (and a lot of
technical details) short, the machine takes the value of the program
counter (instruction pointer), normally once every millisecond or so,
and from that, determines what code is executing at that point. With a
few hundred thousand samples, you tend to get a good idea of what code
is taking the most time.

Pros:

- Excellent across-process profiling. With suitable OS support, you can
see how much time is spent in your program, and how much time is spent
in the OS servicing your program. This is great if, for example, your
program runs slowly because of inefficient memory management or disk
usage, resulting in lots of O/S calls. Also works nicely with DLL's and
COM stuff... you can get an idea of the relative loading of each
process.

- Normally *very* accurate. The profiling overhead is independent of the
frequency of execution of any one piece of code.

- More detailed. Most decent sampling profilers will be able to tell
you, right down to the instruction level, how fast everything is
executing, and where your time is spent. This is not necessary for all
programs, but if you're doing *very* CPU intensive stuff, you'll often
find there's one little bit (eg the matrix stuff in graphics programs,
or B-tree traversal stuff in databases) that benefits from fine
examination: some programs aren't so much 90%-10% as 99%-1%

- Don't affect running speed of profiled program.

Cons:

- Very Platform Specific.
- Not much shareware or freeware in this dept: Can cost an arm and a
leg.

Advice:

- Dev environement specific.

There are normally call graph profilers written for most development
environments. There may even be some reasonably generic ones for pascal
environments.

- Win32?

I don't know much about other platforms, but if you're developing for
Win32, have a go at getting VTune from Intel. It's an excellent sampling
profiler, and is the tool I used for a 2x speedup in my raytracer.

There is a free 15 day evaluation version, but after that, be prepared
to remortgage your house <g>.

4. After profiling.

You then have an idea of where the time is being spent. Remember to
optimise from THE TOP DOWN. Don't just randomly recode in assembler.
Your optimisation options should be performed in the following order:

a) High level stuff: Can I improve the design so that the problem simply
does not crop up?

b) Mid level stuff: Can I improve the algorithm so that it's more
efficient in this case (eg change sorting / searching algorithm).

c) Mid to low level stuff: Are there any specific implementation
decisions that I can change to improve speed: eg: Different memory
allocation strategies (optimistic vs pessimistic), have I got my
row/column ordering the wrong way for cache coherency etc etc ...

If, AND ONLY IF, all else fails, you can then go for

d) Ultra low level. If a large part (>20%) of the programs time is spent
in a small amount (<20 or so lines) of code, then you may gain
significant performance benefits by recoding in assembler. It helps if
you know what you're doing, and you also know a fair bit about the
implementation details of modern processors.

Hope this helps,

MH.

--

     http://www.pergolesi.demon.co.uk

The Usenet Oracle has pondered your question deeply.  Your question
was: Will your answer to this question be in the negative?
And in response, thus spake the Oracle: Memory fault.  Core dumped.



Mon, 06 May 2002 03:00:00 GMT  
 Just how do you test Efficiency?

Quote:

> I've been using Pascal for a few months now, and learning from
> those with Experience on this newsgroup has been {*filter*}y useful.

As a follow up to my previous post, I've just downloaded the latest demo
version of VTune (The previous demo I had expired some months ago).

If your latest source code can be suitably munged to get my Delphi
compiler to support it (ie, it's sufficiently close to Borland Pascal),
and you're happy to let me profile the thing a few times, I do that and
then give you the results.

If it's passively compiler or OS specific, then of course this won't be
possible.

MH.

--

      http://www.*-*-*.com/

The Usenet Oracle has pondered your question deeply.  Your question
was: Will your answer to this question be in the negative?
And in response, thus spake the Oracle: Memory fault.  Core dumped.



Mon, 06 May 2002 03:00:00 GMT  
 Just how do you test Efficiency?
Just as a further note to the previous excellent response I would like to add
that the fastest loop is a repeat until loop for the Turbo Pascal 6 compiler,
this is due to one fewer JUMP statements, This was discovered about a year ago
in this news group.
So for my fast loops I tend to stick with repeat until if it fits.
Quote:

> I've been using Pascal for a few months now, and learning from
> those with Experience on this newsgroup has been {*filter*}y useful.

> But can anyone recommend to me how I can scrape up those extra marks
> and improve efficiency in my programs?

> Apart from the length of my code (which I guess can be misleading) I don't
> know of any other methods of checking.

> Are there are any efficiency test programs or does anyone have any general
> tips?

> Cheers!
>     Jimbo



Sun, 12 May 2002 03:00:00 GMT  
 Just how do you test Efficiency?
Hi james,

Look first in loops

There are also some useful tips at
http://www.pascal.about.com/compute/pascal/
other websites:
http://www.merlyn.demon.co.uk/
http://www.borland.com/

or you should visit some newsgroups as
forums.inprise.com or
Hope to have helped :-)

* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping.  Smart is Beautiful



Sat, 25 May 2002 03:00:00 GMT  
 Just how do you test Efficiency?
Hello Adam,

In Pascal (and also in other languages) you have in fact
two kind of loops:

The loops that check the condition before going in the loop:
these are the "WHILE <condition> do .." loops
they are used if you don't know whether the condition you
are going to check will be True or False.
(Many programmers replace this with:
(If <condition> then
(repeat
(..
(until

The loops that check the condition at the end of the loop:
these are the "REPEAT ... UNTIL <condition>" loops
You should use this kind of loops if you must execute the
commands AT LEAST once.
I use this frequently in inputroutines where an input MUST
be given:
Procedure Input;
VAR bInputOK : Boolean;
BEGIN
REPEAT
.read input
.validate input > results in setting bInputOK to True or
False
UNTIL bInputOK

A second kind of REPEAT Until are the "counter" loops
FOR iCounter := numeric1 to numeric2 DO
These also run very fast.

Some other languages use also the "FOR EACH element OF
collection DO" wich is a variation of the previous one.

Always use the loop what is the most appropriate to your
program and the conditions you use.

Marcel :-)

* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping.  Smart is Beautiful



Sun, 26 May 2002 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. TEST TEST TEST TEST

2. * Efficiency of BDE's [MOVEBY] command ?

3. databse efficiency comparison

4. Efficiency question.

5. Efficiency of BDE's SQL

6. Efficiency of BDE's SQL

7. case statement efficiency

8. How to Imporve the Efficiency of Quick Report

9. Doing a partial (not exact match) search in a database - testing whether I've found a match

10. Doing a partial (non-exact) search in a database - testing whether I've found a match

11. Help! EMS TEST done. What now?

12. Anyone done D2->ODBC->Personal Oracle?

 

 
Powered by phpBB® Forum Software