What is the performance impact of reporting alignment faults?

[Dennis Handly]

>That's not a default with that abort-penalty for an unaligned reference Dennis, that's a requirement.

I don't think I understand that you said?  From the subject of this topic, I assume the default on OpenVMS is to continue on unaligned accesses and be very slow.

>The default on all of the OpenVMS compilers is natural alignment, which may or may not be the best model.

I don't think there is anything wrong with it.  :-)

But this means the topic author isn't taking the default and is cheating and the compiler doesn't provide help.

>the 'ac' flag gets set in the user mask.  So now EVERY unaligned memory reference causes a fault, traps to OpenVMS, which in turn takes out a spinlock in order to fix up the unaligned reference

This sounds completely backwards and not how HP-UX does it.  There the default is set to 1 and the process aborts on an alignment trap.

If you set it to 0, then the kernel emulates the instruction, if the chip doesn't handle it.

This gives applications a choice and allows the chip to handle it.

[H.Becker]

>>> By the way, our test environment is an HP rx2620  (1.60GHz/6.0MB) with 16GB of memory, running OpenVMS V8.3.  We see similar behavior on our intended production environment: HP BL860c i2  (1.60GHz/5.0MB) 16 cores with 32GB of memory, running OpenVMS V8.4.

>>> It is the exception processing that was taking the extra time.  Yet another thing to be wary of (as has been reported in other posts) when moving to Itanium.

You should see much better exception performance on 8.4.

[Hoff]

:>That's not a default with that abort-penalty for an unaligned reference Dennis, that's a requirement.
:
:I don't think I understand that you said? From the subject of this topic, I assume the default on OpenVMS is to :continue on unaligned accesses and be very slow.

If I interprete "default" as indicating what happens when the compiler doesn't correctly predict data alignment, and when the run-time is "unforgiving" about that, then that is what I'd consider a "requirement" and not a "default".

If I interprete "default" as what happens when the compiler doesn't correctly predict data alignment" and the run-time is 'unforgiving', but you can switch either or both the compiler and (particularly) the run-time 'forgiving'", then that's a different design choice.

The VMS run-time is 'forgiving'. 

Whether the compiler misdetected the alignment is certainly debateable; generating the extra instructions unnecessarily is certainly bad, but mispredicting unaligned data is bad, too.

When the compiler misses on the data alignment (often enough), application performance craters.

Equivalent to 10,000 to 15,000 instructions per alignment fault.

Whether that performance hit really matters depends on various factors, including the numbers of faults and what else the code is doing.  (There are other things that will slow down application performance and to varying degrees, such as cache misses or most anything that'll trigger a bubble, I/O, etc.  And off the top, I don't recall the analogous "instruction" hit for I/O, but that's huge, too.)

VMS doesn't have anything that's really comparable to Vtune, unfortunately.

Handling unaligned references in a compiler with the insertion of "extra" instructions is normal.  Having to add extra instructions probably happened with VAX (been a while since I looked at that) and those extra instructions were commonplace on Alpha (both for data (un)alignment, and for dealing with instruction subsets), and it's a necessity on Itanium.  Having the compiler and the run-time trigger an application-level unaligned-data error (on VMS) isn't.

Itanium is variously perceived as either a limited-use architecture, and as being sufficiently weird that the typical code-scheduling optimizations implemented for other architectures can't automatically be reused, so there aren't many open-source compilers that target the architecture.  gcc is one of the few, and I don't know how actively that's being maintained and extended for Itanium.  One of the HP folks stated "the need for improved gcc performance for Itanium is urgent", and that was from around five years ago.  The LLVM folks report that that tool-chain has yet lower performance than gcc on Itanium, and there wasn't any activity with that back-end with Itanium when last I checked.

But if past code-generation improvements with compilers other architectures are any guide, I wouldn't expect a huge improvement even with a large investment in the Itanium compilers.  Barring degenerate cases - such as massive numbers of alignment faults, as can arise here - the performance-improvement percentages just aren't there with the compilers, as compared with other changes in computer designs.

[jreagan]

The VAX compilers accessed the memory without regard to alignment.  The VAX microcode did all work.  On machines like the 11/780, aligned vs unaligned didn't make much difference.  On later model VAXen, it did help to a small degree.  The biggest help was to longword align code labels.

On Alpha, the first revision of the architecture ONLY had longword and quadword memory accesses.  The compilers were required to fetch larger chunks of memory and mask/shift.  There is also the _U forms that mask the effective-address to fetch quadwords above or below (helpful in fetching unaligned data).  Note that fixing alignment faults on Alpha can help performance too.  The PAL code fixup isn't free.  The defaults on the Alpha compilers are still EV4-era instruction sets (ie, no word, no byte).  You need /ARCH=HOST or something to enable the newer instructions.

[Dennis Handly]

>If I interpret "default" as indicating what happens when the compiler doesn't correctly predict data alignment, and when the run-time is "unforgiving" about that, then that is what I'd consider a "requirement" and not a "default".

(Unfortunately, I no longer know what the last "that" is referring.)

On the HP-UX compilers, there is no predicting.  The compilers only do what they are told and will assume natural alignment unless options, pragmas, attributes or typedefs are used to indicate misaligned data.

>If I interpret "default" as what happens when the compiler doesn't correctly predict data alignment" and the run-time is 'unforgiving', but you can switch either or both the compiler and (particularly) the run-time 'forgiving'", then that's a different design choice.

On HP-UX, it really isn't the "runtime" since the work is done in the kernel.  Or on PA-RISC, in a bolted on signal handler library.

And on PA-RISC it is so slow, that reporting of the faults doesn't have to be much slower.

[Hoff]

So that compiler implementation transfers the Itanium alignment requirements and particularly pushes at least this aspect of the architecture from the compiler's analysis processing onto the programmer, and HP-UX enforces unalignment data errors at run-time.  

Certainly makes for simpler compiler designs, and vastly simpler code analysis.  And a far larger incentive for code coverage testing by programmers targeting HP-UX, certainly.

If there is no means to switch on code analysis and run-time handling of unaligned data, then the behavior is not really what I'd consider a "default".  This behavior is a requirement.  ("Default" implies there are alternatives.  And based on what I'm reading here, there aren't.  Unaligned data causes an HP-UX application to receive (what I presume is probably) a signal.  That the application would then fail.  

(It's conceivably that sufficiently gonzo programming requirements could lead to the implementation an application-level fix-up and some sort of a recovery, but I'd doubt most HP-UX programmers would bother.)

The VMS compilers do rather more here, and the run-time (which is also implemented in privileged code) fixes up cases where the data isn't alighed.

The OP has the answer, and certainly I've learned rather more about the design and code analysis features in the HP-UX compilers.  Thanks.

[jreagan]

Yeah, the VAX strongly influenced the compiler's ability to tightly pack data.  Partially for PDP-11 compatibility and partially since the first 11/780s shipped with 256KB of memory. :)  [I suspect that Dave Cutler had some hand in the decision as well.  Next time any of us sees Andy G, ask him.]

For instance, VAX Pascal will let you put a 32-bit integer on a BIT boundary!

PACKED RECORD

  F1: BOOLEAN;   (* One bit big, starting at offset 0 *)

  F2: INTEGER;    (* 32bits bit, starting at offset 1 *)

END;

Even on VAX, you have to extract from memory into a register, operate on the register, and insert it back.

When we ported to Alpha, we changed all the defaults so that F2 field would now aligned on at least a byte boundary for a PACKED record and 32-bit boundary for an "unpacked" record.  [We still have qualifier to get VAX packing rules in case you have old VAX binary data on disk.]

[Dennis Handly]

>and HP-UX enforces unaligned data errors at run-time.

(Actually the hardware does this.)

>And a far larger incentive for code coverage testing by programmers targeting HP-UX, certainly.

It depends.  To get misaligned data, you usually have to tell the compiler you are cheating for struct layout.  (Of course you can add non-portable casts that the compiler will warn about.)
 
>If there is no means to switch on code analysis and run-time handling of unaligned data

The code analysis warnings are always on.  You can optionally reset the flag to get the hardware and kernel to handle them.

>then the behavior is not really what I'd consider a "default".  This behavior is a requirement.  ("Default" implies there are alternatives.

(Ah, ok.  So you don't believe in "you can have any color you want, as long as it is black"?

But in this case, you can change the default by looking at the fine print.  :-)

>Unaligned data causes an HP-UX application to receive a signal.  That the application would then fail.

This is the default but it can be changed.  Either by enabling belts and suspenders code generation and/or passing the buck to the hardware and kernel.

>could lead to the implementation an application-level fix-up and some sort of a recovery

You could say this was what was done on PA-RISC.

>The VMS compilers do rather more here

I wouldn't necessarily say it does more, it's that its default is different.  ;-)

You have to order the HP-UX compilers to use different alignments and packing and then there are options to handle the non-typesafe coding cases.

[Hoff]

OK; now I'm completely confused.

I know what Itanium is (not) doing, but whatever HP-UX is doing here seems, well, just as differently-odd as Itanium itself.

Off to read some HP-UX compiler documentation.

[Hoff]

John: based on a quote from DEC for a VAX-11/780 to VAX-11/785 upgrade, eight megabytes of VAX-11/780 memory cost US$36,000 back about 1985.  (That was MS780-E series)  We ended up doing that upgrade with used memory (MS780-C series), and that was "only" US$10,000 for that part of the upgrade.  At the time, an 8 MB VAX-11/785 was a very large VAX box.

I'm well aware of the data packing and padding on VAX, Alpha and Itanium running OpenVMS, and the related compiler pragmas and such.  (That's for C, other languages vary.)  And its history, for that matter.

It's the "completely different world" of HP-UX and its compilers that's the oddity (to me) here. 

But then HP-UX and its compilers on Itanium is presently only a curiosity here (for me), for reasons not germane to this discussion.  And as mentioned in another reply of mine, I'll be scrounging for technical papers on the compiler and the operating system platform, if anyone has suggestions.