AnsweredAssumed Answered

VRf-VEE_Benchmarks

Question asked by VRFuser on Mar 14, 1997
send q VRf-VEE_Benchmarks vrf

from: Greg Goebel / HP-MXD
      gvg@lvld.hp.com / 970-679-3030 / FAX 970-679-5971
to:   VRf
date: Friday, 14 March 1997 1650 MST

Hi All:

A HP France fellow was questioning our benchmark data for VEE 4.0 and I think
the reply I wrote would help put matters in perspective (we're gonna get a
lot of this stuff for a while):

--------------------------------- cut here ----------------------------------

> I run a very simple test in order to compare performances between 3.2 and
> 4.0 HP VEE releases.
>     
> My platform is  : embedded VXI Pentium 166 Mhz (E6233A) under Windows NT
> 4.0.
>     
> I attached the 2 vee codes I used for the test : one for 3.2, and the other
> for 4.0. The program, very straight, measures time of execution of 1000
> loops. At each loop, a waveform is displayed. No I/Os are performed neither
> with VXI nor HPIB harware.
>     
> Regarding Vee4.0 test, I developped it from scratch instead of loading the
> test developped under 3.2. Except this, the two codes contain exactly the
> same objects, same size for the Waveform object, etc...).
>     
> The results of these tests are :
>     
> Vee 3.2                         10.38 s
> Vee 4.0 (3.2 compatible mode)   11.05 s
> Vee 4.0 (compiled)              10.52 s

Your example programs didn't come through email, but I figured this was easy
enough to do:  I wired a Start Button to a For Count set to 1000, had that
drive a Noise Generator firing into an XY Trace, and used a Timer Object and
an Alphanumeric to monitor program progress.

I got the following times:

  % 22.59 / 22.12 -- compiled.
  % 24.03 -- compatibility.

I didn't have VEE 3.2 on the same machine, but I would assume the
compatibility mode as the worst case.

Then I cut out the XY trace object and got:

  % 1.389 / 1.375 -- compiled.
  % 2.433 -- compatibility.

What this tells me is that the vast majority of execution time was spent in
displaying the traces, which is an I/O bound operation and wasn't optimized
in VEE 4.0.  I would not expect to see any performance increases.

By the way, in compiled mode you need to run *twice* or more to get best
performance because you do a compile prerun the first time around (hence the
two times listed).  The first run could well be slower than VEE 3.2 under
such circumstances.

> Each run was done under the same conditions (CPU load, memory available
> ...) checked with a performance monitor.
>     
> Further, I tested a program using the E1432 PnP driver (not attached here).
> The gap between Vee3.2 and 4.0 is dramatically increased (4.0 worst)
> DESPITE I USED THE COMPILED MODE FOR 4.0 (for Vee4.0, I developped from
> scratch in the Vee4.0 environment - except this the 2 codes contain exactly
> the same objects).

Since using a PNP driver involves invocations of an external DLL (a very
time-consuming process) the overhead is such that VEE 4.0 optimizations have
very little effect.  Again, the prerun delay likely accounts for the
increased time to run the program ... it would be interesting to see if it
dropped with successive runs.

> Since these results do not match (with respect to each other) VEE 4.0
> performances announcement, I would like to get feedbacks on it.
>     
> I thank you for any comments.

I can provide counterexamples that reveal substantial performance increases.
What this tends to confirm is (1) the fact that optimization has to be
considered for an entire program and specialized examples can be used to
prove a wide variety of conclusions and (b) the overall performance at a
system level of the old VEE wasn't that bad to begin with, since for the most
part the programs were I/O bound to begin with.

> Best regards, Bruno

If you have more comments, let us know.

[<>] regards -- gvg

Outcomes