HP3000-L Archives

May 2002, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Wirt Atmar <[log in to unmask]>
Reply To:
Date:
Wed, 8 May 2002 14:42:50 EDT
Content-Type:
text/plain
Parts/Attachments:
text/plain (31 lines)
Gavin writes:

> Wirt writes:
>  > "Increase dramatically" may be too dramatic a phrase. About the
>  > best you will experience after OCTCOMPing a program will be ca.
>  > 30% increase in performance[...]
>
>  But this will be limited to a 30% improvement in that part of the program's
>  execution that takes place in the PROG file itself.  If you've got a CPU
>  intensive program then this might be significant but if, like most MPE
>  programs, only a few percent of the CPU time is spent in the program it
>  self, then you're looking at, say, that 30% improvement only applying to
10%
>  of the run time for something like a 3% effective improvement.

Everything that Gavin writes is correct, but the 30% performance increase
that I mentioned is the overall increase that we see in our own programs,
when very carefully measured from the perspective of an outside observer.

What that means is that I am sure that there are sections of code that are
increased in overall performance by a 1000x, but they just aren't being
called often enough to make a dramatic difference in overall run-time
performance, and for all the reasons that Gavin mentions, the time spent in
system intrinsics, which may well be the majority of the CPU cycles spent,
will not be affected by OCTCOMPing the program.

Wirt Atmar

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2