- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- AEST shared image performance problem
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2008 06:05 AM
тАО10-22-2008 06:05 AM
AEST shared image performance problem
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2008 06:26 AM
тАО10-22-2008 06:26 AM
Re: AEST shared image performance problem
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2008 06:45 AM
тАО10-22-2008 06:45 AM
Re: AEST shared image performance problem
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2008 07:25 AM
тАО10-22-2008 07:25 AM
Re: AEST shared image performance problem
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 );
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2008 07:57 AM
тАО10-22-2008 07:57 AM
Re: AEST shared image performance problem
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-22-2008 12:38 PM
тАО10-22-2008 12:38 PM
Re: AEST shared image performance problem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-24-2008 12:49 AM
тАО10-24-2008 12:49 AM
Re: AEST shared image performance problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-24-2008 01:51 AM
тАО10-24-2008 01:51 AM
Re: AEST shared image performance problem
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-24-2008 03:43 AM
тАО10-24-2008 03:43 AM
Re: AEST shared image performance problem
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-24-2008 04:10 AM
тАО10-24-2008 04:10 AM
Re: AEST shared image performance problem
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.