[Info-vax] If sensitive with ! Data misalignment - Impacts codes/system performances

[John Reagan]

"A famous IT technical writer" <Philippe.vouters at laposte.net> wrote in 
message 
news:0ab18b09-9d47-4c79-b365-190c38d8dac9 at q16g2000vbt.googlegroups.com...
On Dec 8, 4:52 pm, "John Reagan" <johnrrea... at earthlink.net> wrote:
Dear John,

Thank you so much to bring in your precisions. A quick check tells me
you are consciously set as the technical contributor for the
misaligned pointers article. Anyhow and without alignments faults, the
performances may reveal really poor on misaligned pointers with the /
assume=(NOALIGNED_OBJECTS) HP C compiler qualifier or unaligned data
with the /nomember_alignment HP C compiler qualifier. For these
reasons, it is often best for performances reasons to attempt to align
data..

Unaligned packed data may reveal important for network bound
applications where the network is the true bottleneck. As well and in
this case, you may use compression/decompression algorithms to ensure
the volume of network traffic to be kept at a minimum.

I have never tested the impact of data alignment/misalignment on disk
I/Os. If someone has an input to give on this, he remains welcomed.



One way to handle alignment faults is to align the data to match the 
compiler's assumptions about pointer variables.  For example, a "pointer to 
an integer" is assumed to be a "pointer to an ALIGNED integer".  That is 
true on Alpha and I64.  Of course, aligning data may have downstream effects 
if other programs know about the layout.  Or perhaps you have binary data on 
disk, in a mailbox, global section, etc.  All might prevent you from easily 
using /ALIGN or /MEMBER_ALIGN.

If you can't align your data, the alternative is to mark the pointers to be 
"pointer to UNALIGNED integer" with the appropriate syntax for your language 
(ie, "unaligned" in C).  Some languages don't have syntax for this (ie, 
BASIC).

For data sent out over the network or to disk I/O, there is almost always 
buffering involved.  If the OS code calls OTS$MOVE or OTS$MOVEM, those 
routines are specially written to detect unaligned pointers, do a few bytes 
of transfer, then perform loads/stores on quadword boundaries, and finally 
perhaps a few extra bytes at the end.  For large copies (ie, larger than 64 
bytes), I'd say that aligned vs unaligned buffers for calls to OTS$MOVE are 
pretty similar.  For C's memset, memcpy, etc.  they were revised for V8.4 
for much better performance as well.

John