Does "MISALGNDSTRCT" affect CPU performance

[Tru64Unix]

Hi all,

There are many alignment fault in the appliance.Anyone knows whether "MISALGNDSTRCT" affect CPU performance seriously?

Thanks.

[Richard Whalen]

Depends upon the CPU. For Alpha processors, it has a moderate effect as the fixup is taken care of in PAL code. For Integrity it is very expensive, as it traps to part of the operating system that has to fix it up.

[John Gillings]

Yes. Accesses to misaligned data will affect CPU performance. How much depends on the processor, and how good the compiler is at detecting misaligned accesses.

For VAX you can expect an unaligned access to be between 1.5x and 3x more expensive than a similar aligned access (but then aligned accesses are more expensive than they need to be, because the microcode paths contain checks for misalignment).

On Alpha unaligned will be about 10x if the compiler knows about it and about 100x if it doesn't.

On IA64 it starts at about 100x and goes up.

If you care about performance, you'll align all you data. All platforms will benefit, but especially IA64

[Robert Gezelter]

Tru64Unix,

Misaligned data always affects performance. Worse yet, it does not necessarily show up on the CPU usage.

Even for VAX, where the architecture did not officially penalize one for having unaligned data, it potentially forced a double fetch ("potentially" because it might have already been in the cache).

On Alpha, the fault is expensive, and on Itanium, the fault is even more expensive.

In virtually every case, unaligned data is straightforward correctable with minor changes to the structure involved.

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

[Jean-François Piéronne]

I have written a program which exhibit the cost of accessing unaligned data, for example:
- On my AXP box
Assuming standard pointers (aligned) during iterations
Align for two pointers
ELAPSED: 0 00:00:06.40 CPU: 0:00:06.37 BUFIO: 1 DIRIO: 0 FAULTS: 1
Align for 4 bytes
ELAPSED: 0 00:00:38.68 CPU: 0:00:38.36 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 2 bytes
ELAPSED: 0 00:00:41.16 CPU: 0:00:38.50 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 1 bytes
ELAPSED: 0 00:00:38.86 CPU: 0:00:38.48 BUFIO: 1 DIRIO: 0 FAULTS: 0

Normal Align4 Align2 Align1
Normal 100.00 16.61 16.55 16.55
Align4 602.20 100.00 99.64 99.69
Align2 604.40 100.36 100.00 100.05
Align1 604.08 100.31 99.95 100.00


Assuming unaligned pointers during iterations
Align for two pointers
ELAPSED: 0 00:00:07.57 CPU: 0:00:07.49 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 4 bytes
ELAPSED: 0 00:00:06.53 CPU: 0:00:06.51 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 2 bytes
ELAPSED: 0 00:00:06.51 CPU: 0:00:06.48 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 1 bytes
ELAPSED: 0 00:00:06.52 CPU: 0:00:06.49 BUFIO: 1 DIRIO: 0 FAULTS: 0

Normal Align4 Align2 Align1
Normal 100.00 115.05 115.59 115.41
Align4 86.92 100.00 100.46 100.31
Align2 86.52 99.54 100.00 99.85
Align1 86.65 99.69 100.15 100.00



Using __unaligned
Normal 85.05
Align4 589.25
Align2 594.14
Align1 592.91

On my IA64 box:
Assuming standard pointers (aligned) during iterations
Align for two pointers
ELAPSED: 0 00:00:01.87 CPU: 0:00:01.86 BUFIO: 1 DIRIO: 0 FAULTS: 1
Align for 4 bytes
ELAPSED: 0 00:04:39.97 CPU: 0:04:34.95 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 2 bytes
ELAPSED: 0 00:04:39.03 CPU: 0:04:34.87 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 1 bytes
ELAPSED: 0 00:04:42.17 CPU: 0:04:35.14 BUFIO: 1 DIRIO: 0 FAULTS: 0

Normal Align4 Align2 Align1
Normal 100.00 0.68 0.68 0.68
Align4 14782.26 100.00 100.03 99.93
Align2 14777.96 99.97 100.00 99.90
Align1 14792.47 100.07 100.10 100.00


Assuming unaligned pointers during iterations
Align for two pointers
ELAPSED: 0 00:00:02.17 CPU: 0:00:02.15 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 4 bytes
ELAPSED: 0 00:00:02.58 CPU: 0:00:02.58 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 2 bytes
ELAPSED: 0 00:00:02.58 CPU: 0:00:02.58 BUFIO: 1 DIRIO: 0 FAULTS: 0
Align for 1 bytes
ELAPSED: 0 00:00:02.60 CPU: 0:00:02.61 BUFIO: 1 DIRIO: 0 FAULTS: 0

Normal Align4 Align2 Align1
Normal 100.00 83.33 83.33 82.38
Align4 120.00 100.00 100.00 98.85
Align2 120.00 100.00 100.00 98.85
Align1 121.40 101.16 101.16 100.00



Using __unaligned
Normal 86.51
Align4 10656.98
Align2 10653.88
Align1 10541.76


I can post the program if there is any interest.

JF

[Guy Peleg]

It depends on your definition of "many".

If many = 1000 per second then don't worry
about it.

If many > 100,000 per second, then there will
probably be a big benefit fixing alignment
faults.

As a rule of thumb start worrying when
"many" > 10,000 per second. Note that on Itanium, handling ailgnment faults requires
the MMG spinlock so there is a system wide
impact.

Guy Peleg
BRUDEN-OSSG
http://www.brudenossg.com

[Ian Miller.]

One program with >10,000 alignment faults per second really does slug performance for everyone on the system.

Sadly translated code tends to be like that :-(

[Guy Peleg]

Ian,

Could you trace with FLT the source
of alignment faults? If it is coming from TIE
let me know the popular offsets and I'll see
what could be done about it.

Guy Peleg
BRUDEN-OSSG
http://www.brudenossg.com

[John Reagan]

- If the compiler knows the data is unaligned (and it did since it knew to issue the "MISALGNDSTRCT" message), the compiler will generate several instructions to manipulate the data in pieces. The code SHOULD NOT generate any alignment faults.

- Alignment faults occur when the programmer lies to the compiler. The compiler thinks things are aligned and generates single instructions to access the data. However, at run-time an unaligned pointer causes a fault. The common ways involve pointers and/or parameters passed by reference. You will NEVER see any compiler messages for these. If we knew, we wouldn't do it.

- I don't know what JF's example looks like to determine what it tests or doesn't test.

- My favorite little tools for OpenVMS correspond to the "uac" tool on Tru64. Here are the Pascal versions:

$ type enable_align_report.pas
[inherit('starlet')]
program enable_align_report;
begin
$perm_report_align_fault;
end.
$ type disable_align_report.pas
[inherit('starlet')]
program disable_align_report;
begin
$perm_dis_align_fault_report;
end.
$ pascal enable_align_report
$ link enable_align_report
$ pascal disable_align_report
$ link disable_align_report

$ run enable_align_report
$ run YOUR-APPLICATION
$ run disable_align_report

That will cause alignment fault messages to come out to standard output. Use your .MAP and .LIS files to track down where you lied to the compiler and stop doing it.

- Instead of typing in lots more stuff, if you look at the release notes in the latest Pascal V6.1 release, I have a large section on the myths and facts of alignment faults including many ways to detect them, track them down and fix them.

[Jean-François Piéronne]

John,

my test (stress test, generate ~400k flts/s) program just walk thru a cycle list using pointer and various alignment setting and the optional __unaligned option.

I have attach the program so you can view how it does the various tests.

JF

[John Reagan]

Yes, your example generates alignment faults and does NOT generate "MISALGNDSTRCT" messages.

FYI: here is where the code lies to the compiler:

p = (genlink *)(((char *)(&base[i])) + offset);

My point is that the OP asked about the compiler message and everybody jumped to alignment faults.

The message essentially means: "the compiler generated 4 or 5 instructions instead of a single instruction".

How much does that cost? Depends on how often you execute it. The first memory load will probably pull all the data into the cache so the others will be faster. The compiler will probably have to use a temp register for the shift/mask operations. However, the memory fetch overshadows the whole mess. So how much slower? I'll guess 15% with a 50/50 confidence factor.

[Jean-François Piéronne]

Ok but the test execute pass where it lie to the compiler and pass where it not using the "__unaligned" option.
In this case the cost is 15% as you have expected (last stat of the run).