AEST shared image performance problem

[kari salminen]

Poor performance of translated Alpha shared images on Itanium.

I made a test with AEST (V2.0, Bld DEV_0.8/Aug 29 2006) using slightly modified examples from SYS$COMMON:[SYSHLP.EXAMPLES.AEST]MYMAIN.C and MYMATH.C

Added these lines:

ftime (&t_start);

for (j = 0; j < 500000; j++)
{
result = MYSUB(num1, num2 );
result = MYADD(num1, num2 );
result = MYADD(num1, num2 );
result = MYMUL(num1, num2 );
}

ftime (&t_current);

t_diff = (int) (1000.0 * (t_current.time - t_start.time)
+ (t_current.millitm - t_start.millitm));

printf ("\n time in ms = %d", t_diff);


Results,

Alpha native: 15 ms (AlphaServer DS25, 1 GHz)
Itanium native: 11 ms (HP rx2620, 1.60GHz)

Itanium MYMATH translated: 8239 ms

The translated image runs 550 / 750 times slower (Alpha/Itanium)

[Robert Gezelter]

Kari,

The OP says "AEST shared image performance problem", but it does not specifically which entry points were in which image (or how the images were built).

As I noted in "Strategies for Migrating from Alpha and VAX systems to HP Integrity Servers on OpenVMS, "OpenVMS Technical Journal, Volume 10, June (retrievable via http://www.rlgsc.com/publications/vmstechjournal/migrationstrategies.html ), going back and forth between translated and native images can be very costly.

Can more information about what is in which image be supplied?

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

What's your goal here? That you're building from source code and then translating implies an unusual environment or unusual porting sequence; I'm guessing that's not your real goal here.

Image translation is a last-resort process for porting code.

Application performance will be lower.

Resolving run-time errors will be more work.

If you have the source code, then using image translation is a very bad idea.

Translation can provide savings when porting is required and (for whatever reason) rewriting is not feasible.

The translation process involves both interpreting instructions and static instruction translation, and data format conversions (eg: between IEEE that is used on Itanium and the VAX floating point formats that are often used as the default on Alpha; Alpha compilers can also often be asked to build with IEEE FP). For instruction sequences that are not found and not statically translated, they're interpreted dynamically.

To help (some) with translation speed for those cases where the source code is unavailable, you can perform iterative image translations; use the history mechanisms to help improve the image process. (I've not tried this translation feedback mechanism from Alpha to I64 with AEST, but it does help somewhat when moving from VAX to Alpha; with VEST.)

But I'd never expect translated code would have anything even remotely approaching native performance. And I'd only use (iterative) image translation as a last resort when porting, and I might well (and sometimes have) chosen to re-implement the lost source code.

Stephen Hoffman
HoffmanLabs LLC

[kari salminen]

I noticed the poor performance during testing and evaluating the portability of a third party product from Alpha to Itanium. No sources nor Itanium version is available, only the libraries as shared images.

I've done a lot of VEST'ing in the past and the performance was way better, depending on code, same speed or maximal 2-3 times slower.


To get the idea where the extra time is spend, I checked the examples in the AEST kit, MYMATH calls 4 subroutines in the shared image MYMATH.

As the subroutines do only very simple mathematics, the time is spend in the TIE call translation environment.

Unfortunately AEST is missing the /FEEDBACK feature.


MYMATH.C is compiled on Alpha (OpenVMS V7.3-2, C V6.5-001-48BCD)

$ CC MYMATH/OBJ=AXP_MYMATH.OBJ

$ LINK/SHAREABLE=AXP_MYMATH AXP_MYMATH.OBJ, SYS$INPUT:/OPTIONS
SYMBOL_VECTOR=( myadd=PROCEDURE,-
mysub=PROCEDURE,-
mydiv=PROCEDURE,-
mymul=PROCEDURE)
GSMATCH=LEQUAL,2,0
$!

The AXP_MYMATH.EXE shared image is translated on Itanium


MYMAIN.C is compiled native on Itanium (OpenVMS V8.3-1H1, C V7.1-011-50EAE)

$ CC/TIE MYMAIN/OBJ=IA64_MYMAIN

$ LINK/NONATIVE_ONLY IA64_MYMAIN, SYS$INPUT:/OPTIONS
AXP_MYMATH_AV.EXE/SHAREABLE


Modified MYMAIN.C
-----------------

#include
#include
#include
#include

int MYSUB();
int MYADD();
int MYADD();
int MYMUL();

main()
{
struct timeb t_start, t_current;
int t_diff;
int num1, num2, result;
int i,j,k;

num1 = 5;
num2 = 6;

ftime (&t_start);

printf ("\n start time in %d %d", t_start.time,t_start.millitm);

for (j = 0; j < 500000; j++)
{
result = MYSUB(num1, num2 );
result = MYADD(num1, num2 );
result = MYADD(num1, num2 );
result = MYMUL(num1, num2 );
}

ftime (&t_current);

printf ("\n end time in %d %d", t_current.time, t_current.millitm);

t_diff = (int) (1000.0 * (t_current.time - t_start.time)
+ (t_current.millitm - t_start.millitm));

printf ("\n time in ms = %d", t_diff);

}


Original MYMATH.C
-----------------


int MYADD(value_1, value_2)
int value_1;
int value_2;
{
int result;

result = value_1 + value_2;
return( result );
}

int MYSUB(value_1,value_2)
int value_1;
int value_2;
{
int result;

result = value_1 - value_2;
return( result );
}

int MYDIV( value_1, value_2 )
int value_1;
int value_2;
{
int result;

result = value_1 / value_2;
return( result );
}

int MYMUL( value_1, value_2 )
int value_1;
int value_2;
{
int result;

result = value_1 * value_2;
return( result );
}

[Robert Gezelter]

Kari,

The most recent post clarifies some issues.

As has often been said. "Your mileage may vary". Going back and forth can be very expensive, a point that I noted in my paper.

However, the converse is also true, namely that the test case may not accurately reflect the performance of the actual images. It depends on how close to the execution profile the images are.

Images which do many native/translated calls can experience issues. Code paths that do not do substantial calls can see quite reasonable performance.

When I was writing the paper referenced in my earlier post, I broke an image into a collection of 10 shareable images, and ran all of the possible permutations of native and translated images against the same data sets and logged the results (yes, 1024 different runs).

While some permutations were unacceptably slow, many were quite reasonable.

In this particular situation, more information is needed before a determination one way or the other can be made.

As has been observed in other threads on ITRC, one of the common hazards in benchmarking is benchmarking something which does not reflect the actual phenomenon of interest.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Ignoring the licensing-related issues that can sometimes confound these cases, what is the third-party product?

[kari salminen]

I'm evaluating the portability of the Sybase client library from Alpha to Itanium, the Sybase servers are running on Linux.
Yes, I know there is no support anymore from Sybase, but porting a very large smoothly
running application from Alpha to Itanium is much easier and cheaper, than porting to Linux.

The translation itself was easy and the 10 client libraries are working.
Problem is the huge speed difference, on Alpha a real life database query (fetch etc.)
to a server takes 22 ms, on Itanium 38 seconds, the ratio 1:170.
This is simply a show-stopper.

This small test example verify, that the calls between native and translated code are
very time consuming.

The Sybase code is using heavily sub-routines, a call deep of more than 10 levels is an average situation.

[Robert Gezelter]

Kari,

It is not the depth of the subroutine calls that is the problem, it is the number of times that the switch is made between native and translated environments.

Do you have any way of (even unsupported) obtaining the sources?

- Bob Gezelter, http://www.rlgsc.com

[kari salminen]

Well, maybe I wasn't clear enough, in Sybase code even relative small operations are divided in many nested subroutines, often located in different shared images, this cause
additional calls and degrade the performance.

Years ago I analyzed a Sybase bug and had access to certain parts of the source code listings.

Last time we asked for the source code, Sybase wanted too many $$$.
The code is common for all operating systems.

[Hoff]

With those speeds and feeds, you're going to have to pull Sybase from this configuration.

Ingres (now open source) or MySQL or a commercial database may be alternatives here. There are various databases around. (Though the remote access requirement would likely eliminate SQLite from contention.) More work certainly, but less work than a full port.

Ingres 2006 release 1 was ported to OpenVMS Alpha.

HP has taken a more central interest in maintaining MySQL for OpenVMS, per another discussion.

If the client libraries are ODBC, that too can be available.

[kari salminen]

I compliled the above shared image on an old rusty VAX ( VMS 6.2, DEC C V5.6-003 ) and Vested it on Alpha.

It takes 30 seconds on Alpha, so it beats the Itanium, 38 seconds.

I had a look on the TIE source listings and noticed the fairly large amount code for native/translated image calls.

The conclusion: translated code runs reasonable fast, but too many calls
between native/translated code degrade the performance rapidly.

We are evaluating now FreeTDS as a Sybase client library replacement and it
looks very promising, full source code and it compiles without any problems on
the Itanium.

[Jan van den Ende]

Kari,

some thanks ( = points ) for the helpful answers would be in place. (zero for this)

Proost.

Have one on me.

jpe