PA-RISC commands on Itanium!?!

[Lorenzo Facello]

Hi,
it's possible to start an executable object file PA-RISC in a hpux 11.00 on Virtual Machine on Itanium with Hpux 11.23?

I heard about a library or somthing else...

What do you say?
thanks
LF

[Lorenzo Facello]

I found Aires..
did you have any experience about..??

[Lorenzo Facello]

Aries!!!! sorry

[A. Clay Stephenson]

Yes, ARIES works and does just what you want.

[Patrick Wallek]

Yes, Aries does allow you to run PA-RISC binaries on an Itanium machine.

So, your scenario should work. Test it and see how it goes.

[Lorenzo Facello]

hi guys,
from the man page I read that aries "transparently emulates" the PA-RISC applic.
but what we have to configure?
thanks

[Dave Hutton]

The only experience we've had with it was an application that required a specific version of apache/tomcat. I know when we installed it we had to select install incompatible binaries.

It installs and there wasn't really anything we needed to do to make it work. Aries is smart enough to know what to do and runs it correctly.

man 5 aries has quite a bit of information.

I think the software package we were installing was SiteMinder by CA.

I'm trying to recall more details. But once we got over the fact installing incompatible software on our server was okay, it went pretty smoothly.

[Patrick Wallek]

>>but what we have to configure?

As far as I know, NOTHING. HP-UX automatically determines that it is a PA-RISC executable and invokes ARIES to run it. This is all done behind the scenes and should be transparent to you.

[Torsten.]

According to this you may configure aries, but I guess you don't need to do this:

http://docs.hp.com/en/B2355-60105/Aries.5.html

"The name ARIES expands to Automatic Recompilation and Integrated Environment Simulation."

[Lorenzo Facello]

thanks all for the help..
I'm testing.....

[Andrew Young_2]

Hi Lorenzo

We are running Aries in a production environment for an old AI Engine from Nexpert. Unfortunately Nexpert was bought out in the late 1990's and that code was abandoned, but we still use it for fraud detection. The only problem we had was that the libraries it uses must also be PA-RISC so we had to load the Oracle client libraries for PA-RISC in order for it to access the database.

Based on our earlier benchmarking we believe that code on the Montecito processors, which is software emulation unlike the earlier the emulators which were on the processor itself, runs with a less then 10% performance loss compared to running native Itanium code. Our mean was about 6%, but that varied from about 4 to 9 depending on the nature of the application, we tested IO, memory and CPU intensive loads as well as combinations.

This gap could however widen with the arrival of new Itanium optomised compilers from Intel. But that is mainly because Itanium code will now run even faster.

HTH

Andrew Y

[Dennis Handly]

>This gap could however widen with the arrival of new Itanium optimised compilers from Intel.

There are no Intel compilers on HP-UX. Are you talking about Integrity Linux?

There is HP's aCC6 and of course gcc/g++.

[G V R Shankar · Accepted solution]

I am not sure if the following helps you. I did a research on my systems and it worked perfectly.

1. Install the latest patch PHSS_35528.
2. Configure the file .aries64rc (this file is to be configured for 64 Aries) in either / or application user home directory (application user home directory is always preferred. If the file is present in both the locations, the file in application user home directory will override the file in /).

3. As I understand from aries documentation, Aries is a dynamic binary emulator which transparently emulates 32-bit and 64-bit PA-RISC HP-UX applications on Itanium-based HP-UX machines.
4.
5. Calculating the values of heap_ssz and ap_heap_ssz

heap_ssz size

Specifies the maximum size of Aries heap (in kbytes). the Aries heap is used to allocate internal Aries data structures and for creating Aries threads for emulation of PA-RISC application threads.

1. Checked in my server, pa_maxssiz_64bit = 524288 KB (512 MB).
2. Default value of ssz = 256 MB & default value of ccsz = 16 MB

64 bit Aries heap_ssz = pa_maxssiz_64bit - ssz - ccsz - 33
heap_ssz = 512 - 256 -16 - 33 = 207 MB (211968 KB)

ap_heap_ssz

Specifies the maximum size (in kbytes) of memory area used for Aries private heap. This area is part of Aries heap whose size is determined by Aries option -heap_ssz. This area is allocated from Aries heap and is used for Aries' malloc() calls. Remaining area of Aries heap is used for allocating the new threads

The default value is 8192 KB (8 MB). This can be increased to max heap_ssz - 2048 KB

Before proceeding further to configure .aries64rc, it would be fine if we know how many applications will be running under Aries. I had SAP application, following line would be sufficient in .aries64rc

Following is an example

/usr/sap/PRD/D00/work/dw.sapPRD_D00 -heap_ssz 211968 -ap_heap_ssz 8192

[Andrew Young_2]

Hi

I'm going to be controversial and say that based on tests that we did 12 months ago, when evaluating to move off our N4000 servers onto either Itanium or IBM PowerPC based hardware, as well as later pre-implementation tests, we were disappointed in the relative performance of certain applications on the Itanium.

The increase in performance was linear based on processor speed where we expected additional gains to be had based on the additional design features on the Itanium in terms of things like the number of registers and pipelines. This made us believe that the code we were testing was not optimized for the Itanium processor but standard code produce on a non optimizing compiler. This was especially apparent for the Java VMs.

When we eventually received our new servers, with Montecito's fitted we re ran the same tests with the latest code available at the time 09-2006 and the performance was similar.

Unless someone can prove me different, it is my opinion that only recently have optimizing compilers been available for the Itanium and they have come from Intel. I'm not sure if HP base their compilers on those supplied by Intel, since I am not a programmer, but certainly empirical evidence suggests that up until recently code has been a straight port from PA-RISC and not optimized for the Itanium.

Andrew Y

[Dennis Handly]

>Andrew: we were disappointed in the relative performance of certain applications on the Itanium.

Was the application CPU or I/O bound?

>design features on the Itanium in terms of things like the number of registers and pipelines. This made us believe that the code we were testing was not optimized for the Itanium processor

What compiler options did you use? Did you use +O4, PBO or -IPO? I hope you weren't using gcc.

>but standard code produce on a non optimizing compiler.

The default is only +O1.

>Unless someone can prove me different, it is my opinion that only recently have optimizing compilers been available for the Itanium and they have come from Intel.

You are incorrect. HP has supplied its own compilers for Integrity since 11.20.

>I'm not sure if HP base their compilers on those supplied by Intel

No, not those on HP-UX.

>code has been a straight port from PA-RISC and not optimized for the Itanium.

Which code? You're not correct if you are talking about HP's compilers.

[Andrew Young_2]

Hi

We were using four sets of software.

We used existing depots where possible. These included HP supplied depots. Where no HP supplied depots were available we used depots from the HP-UX porting sites. Where we were unhappy with some of the functionality provided by the precompiled binaries we attempted to compile under HP C/aC++ Developer's Bundle (B9007AA) v C.11.23.12. All libraries and headers were patched to 09/2006 release dates or subsequent where available (this was in October/November/December) Where we encountered compiler errors that we were not able to adequately and quickly resolve we then resorted to gcc 4.0.2. However most performance testing was done on precompiled depots.

Our main CPU tests were done by reading a large xml file into memory with accompanying style sheets and using a small Java app to covert this to a postscript file. This was done for a fixed large number of iterations all within memory. The operation was CPU bound, we ran it in an incremental number threads to also test scalibility. We also conducted similar tests using Perl to test various computational behaviour of the CPU, in which we simulated different types of calculations, although some also required Java. We compared these to an IBM Power box we were also evaluating. The HP supplied JAVA VM's were dog slow compared to the IBM equivalant. They also did not scale well once we started running multiple threads per core. The compiled versions of Perl were slightly better, however they still performed worse than the IBM equivalants. Significantly slower. However all told, when we factored in IO performance the server's performance equalised.

The only difference we could ascribe these performance differences to, having factorred in relative CPU speeds, was that the IBM optimisation was substantially better than that of HP. We ascribed this the relative age of the different processors, and the maturity of the different compilers.

The reason why I questioned the compilers is that I know HP are no longer supplying staff for the development of the CPU's themselves, that being handed to Intel. I also know that Intel recently released new optimising compilers for the Itanium processor. It somehow doesn't make sense for HP and Intel to duplicate the effort.

Since I am not a coder, just a lowly sysadmin working to tight deadlines and budgets (as always) I guess we could have done things better, and I'm sure given enough time, money, resources we could have made everything faster, better, easier but I can only report what we found.

Regards

Andrew Y

[Dennis Handly]

>Andrew: We used existing depots where possible. These included HP supplied depots.

If these were not compiled with aC++, then this isn't HP's compiler.

>Where we were unhappy with some of the functionality provided by the precompiled binaries we attempted to compile under HP C/aC++ Developer's Bundle (B9007AA) v C.11.23.12.

A.06.10 is HP's compiler, what compiler options did you use?

>we then resorted to gcc 4.0.2. However most performance testing was done on precompiled depots.

This will not have the performance of HP's compilers.

>Our main CPU tests were done by reading a large xml file into memory with accompanying style sheets and using a small Java app to covert this to a postscript file.

Unfortunately, this won't test the performance of HP's compilers, only Java.

>The only difference we could ascribe these performance differences to, having factored in relative CPU speeds, was that the IBM optimisation was substantially better than that of HP. We ascribed this the relative age of the different processors, and the maturity of the different compilers.

No, this has mostly to do with Java and not compilers.

>The reason why I questioned the compilers is that I know HP are no longer supplying staff for the development of the CPUs themselves, that being handed to Intel.

The two are unrelated.

>It somehow doesn't make sense for HP and Intel to duplicate the effort.

HP thinks it does but only on HP-UX. Especially since there is HP's quality and support.

If you are interested in higher performing GNU like compilers, you should search for:
osprey compiler