John Dallman <jgd@cix.co.uk> wrote:
>In article <pB2YJ.292172$zX2.209805@fx12.ams4>,
>mark.daniel@wasd.vsm.com.au (Mark Daniel) wrote, quoting VSI:
>
>> "On X86, there is no such thing as an alignment fault nor is
>> there a performance penalty for accessing unaligned data."
>
>That's a bit over-simplified. On x86, alignment faults are implemented in
>the hardware, but can be turned off, and are invariably turned off on
>every operating system where I've looked at this (Windows, Linux, macOS).

This is true. And it's turned off because the performance penalty is not
too significant of one.

>There certainly used to be performance penalties for accessing unaligned
>data. I don't see how they can be avoided for the cases where misaligned
>data means that a data structure has member(s) in an additional cache
>line, increasing cache pressure.

All you can do is throw cache at the problem and try to write code that
has good reference locality. Intel are experts at throwing cache at
problems, though.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 3/15/2022 4:09 PM, John Dallman wrote:
> In article <pB2YJ.292172$zX2.209805@fx12.ams4>,
> mark.daniel@wasd.vsm.com.au (Mark Daniel) wrote, quoting VSI:
>
>> "On X86, there is no such thing as an alignment fault nor is
>> there a performance penalty for accessing unaligned data."
>
> That's a bit over-simplified. On x86, alignment faults are implemented in
> the hardware, but can be turned off, and are invariably turned off on
> every operating system where I've looked at this (Windows, Linux, macOS).
>
>
> There certainly used to be performance penalties for accessing unaligned
> data. I don't see how they can be avoided for the cases where misaligned
> data means that a data structure has member(s) in an additional cache
> line, increasing cache pressure.

In certain scenarios (random access where data size vs
cache size has the wrong ratio) that should be able
to create some overhead.

But not like what can be seen on Alpha and Itanium. My
little test program showed a factor 300 impact
on Itanium.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>
>But not like what can be seen on Alpha and Itanium. My
>little test program showed a factor 300 impact
>on Itanium.

No architecture ever had as much cache pressure as Itanium.
Intel just kept adding more and more cache but all the cache in the world
was never enough.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Tuesday, March 15, 2022 at 11:50:48 AM UTC-4, Mark Daniel wrote:
> On 26/2/22 8:23 am, Mark Daniel wrote:
> > Alpha and Itanium had data alignment requirements with penalties for
> > faulting. Does x86-64? Is sys$start_align_fault_report() et al. still
> > relevant
> Recent reply under the VSI Engineering imprimatur:
>
> "On Alpha and IA64, accessing unaligned data results in an exception and
> an exception handler fixes up the read and records the alignment fault.
> On X86, there is no such thing as an alignment fault nor is there a
> performance penalty for accessing unaligned data. The various tools to
> report alignment faults are still present on X86, but they are not
> relevant and will never report any alignment faults."
>
> https://forum.vmssoftware.com/viewtopic.php?f=37&t=8475&p=17487#p17486
> --
> Anyone, who using social-media, forms an opinion regarding anything
> other than the relative cuteness of this or that puppy-dog, needs
> seriously to examine their critical thinking.
Dave's answer isn't technically correct.

On Alpha, all unaligned access trap to the PAL code where the unaligned operation
is fixed up without the knowledge of OpenVMS. Fast and quick.

On Itanium, unaligned accesses within the same cache line are handled by the chip
unless the 'ac' flag is set in the User Mask register.

From the Itanium SRM Volume 1

ac 3 Alignment check for data memory references (including IA-32)
0: unaligned data memory references may cause an Unaligned Data Reference fault.
1: all unaligned data memory references cause an Unaligned Data Reference fault.

When trapped to OpenVMS, there are several possible spinlocks that need to be acquired
in the event that the unaligned access might be with memory that is being deallocated by
another CPU.

On x86, at this point, we don't even turn on the trapping. I'm sure there are hardware
performance registers that count them globally but OpenVMS doesn't ask about that.
Tools like MONITOR ALIGNMENT and the various system services to report alignment
faults will just return 0s.

On Wednesday, March 16, 2022 at 8:36:09 AM UTC-4, John Dallman wrote:
> In article <4ff9c36f-5aef-4753...@googlegroups.com>,
> xyzz...@gmail.com (John Reagan) wrote:
>
> > On x86, at this point, we don't even turn on the trapping. I'm
> > sure there are hardware performance registers that count them
> > globally but OpenVMS doesn't ask about that.
> Presumably the compilers - both GEM-based and LLVM - will use natural
> alignment by default?
>
> John
Our Alpha and Itanium frontends are already natural alignment by default (COBOL
is the exception). Nothing changed for x86.

You can use various pragmas like nomember_alignment, pack(0), etc. to place structure
fields in whatever offset you prefer.

On 3/16/2022 9:15 AM, John Reagan wrote:
> On Wednesday, March 16, 2022 at 8:36:09 AM UTC-4, John Dallman wrote:
>> In article <4ff9c36f-5aef-4753...@googlegroups.com>,
>> xyzz...@gmail.com (John Reagan) wrote:
>>> On x86, at this point, we don't even turn on the trapping. I'm
>>> sure there are hardware performance registers that count them
>>> globally but OpenVMS doesn't ask about that.

>> Presumably the compilers - both GEM-based and LLVM - will use natural
>> alignment by default?

> Our Alpha and Itanium frontends are already natural alignment by default (COBOL
> is the exception). Nothing changed for x86.

That is what we expect.

Changing defaults could break index-sequential file access code
with copied over files or mixed architecture cluster.

Arne

More a case that x86 has always allowed any old alignment though it's
expensive.

Proper architectures simply don't (and ARM does some rotating on reads).

Jon

Jon Schneider <jon@jschneider.tenreversed> wrote:
>More a case that x86 has always allowed any old alignment though it's
>expensive.

Remember the x86 has grown by accretion. There are a lot of aspects of the
architecture which are consequences of that.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On Tuesday, March 15, 2022 at 10:10:52 PM UTC+2, John Dallman wrote:
> In article <pB2YJ.292172$zX2.2...@fx12.ams4>,
> mark....@wasd.vsm.com.au (Mark Daniel) wrote, quoting VSI:
> > "On X86, there is no such thing as an alignment fault nor is
> > there a performance penalty for accessing unaligned data."
> That's a bit over-simplified. On x86, alignment faults are implemented in
> the hardware, but can be turned off, and are invariably turned off on
> every operating system where I've looked at this (Windows, Linux, macOS).
>

That's not 100% correct.
On Intel hardware (as opposed to AMD's) for SSEn instructions (as opposed to Integer and AVX) alignment faults can't be turned off.
Naturally, it does not apply to SSEn instructions that are called 'unaligned load' and 'unaligned store' .

>
> There certainly used to be performance penalties for accessing unaligned
> data. I don't see how they can be avoided for the cases where misaligned
> data means that a data structure has member(s) in an additional cache
> line, increasing cache pressure.
>

Relatively recent measurements:
https://www.realworldtech.com/forum/?threadid=203203&curpostid=203232
And the rest of the sub-thread. Especially
https://www.realworldtech.com/forum/?threadid=203203&curpostid=203263

>
> John

On Friday, March 18, 2022 at 2:20:00 PM UTC+2, Jon Schneider wrote:
> More a case that x86 has always allowed any old alignment though it's
> expensive.
>
> Proper architectures simply don't (and ARM does some rotating on reads).
>
> Jon

Both sentences make no sense at all, esp. the 2nd, considering that ARMv7-AR and ARMv8-A
architectures are identical IA32/AMD64 (a.k.a. x86-64) in nearly all aspects of handling of unaligned accesses.

Most likely, you were victim to DEC's propaganda of early 1990s and didn't pay attention that even DEC themselves
changed the tune 5-7 years later.