Alpha and Itanium had data alignment requirements with penalties for
faulting. Does x86-64? Is sys$start_align_fault_report() et al. still
relevant?

--
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.

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?

Hmmm. Using an alignment fault generator and reporter I'm seeing plenty
on Alpha and Itanium; zero on x86-64.

--
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.

On 2/25/2022 6:57 PM, 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?
>
> Hmmm.  Using an alignment fault generator and reporter I'm seeing plenty
> on Alpha and Itanium; zero on x86-64.

I had an old Fortran program testing alignment overhead and
I just ran it on Windows x86-64 and it showed absolutely
no overhead for bad alignment of REAL*8 arrays (and there is
a lot of overhead on VMS Alpha and Itanium).

I guess we can say welcome back to CISC. :-)

Arne

On Friday, February 25, 2022 at 7:12:55 PM UTC-5, Arne Vajhøj wrote:
> On 2/25/2022 6:57 PM, 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?
> >
> > Hmmm. Using an alignment fault generator and reporter I'm seeing plenty
> > on Alpha and Itanium; zero on x86-64.
> I had an old Fortran program testing alignment overhead and
> I just ran it on Windows x86-64 and it showed absolutely
> no overhead for bad alignment of REAL*8 arrays (and there is
> a lot of overhead on VMS Alpha and Itanium).
>
> I guess we can say welcome back to CISC. :-)
>
> Arne
Arne,

With all due respect, the performance penalty for non-aligned references is still very real, speaking as one who did a lot of work on non-faulting IBM System/370 processors back in the day. The same was true with VAX CPUs. They did not fault, but they paid a performance penalty.

There is a difference in context from the days of the System/370 and the VAX: multi-level large caches.

The caches close to the processing core are very fast. This obscures the loss of performance due to non-aligned references. Second, all loads/stores to/from a cache are, almost by definition, aligned.

A program designed to produce alignment faults is also very likely to not abuse the memory system in a way to detect the mis-aligned data penalty. Faults, which are synchronous interrupts, have overhead orders of magnitude more than a double memory fetch, particularly when sequential elements are referenced (sequential elements may well be in the same cache line, even if not aligned on the proper boundary).

If I had the spare time to play with it, I would write a program to randomly address a storage area beyond total cache size, so that every memory reference is a cache miss. Run aligned and unaligned data references and compare the result.

It is easy for a benchmark to measure the incorrect phenomenon.

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

On 2022-02-25 22:23:39 +0000, Mark Daniel said:

> Alpha and Itanium had data alignment requirements with penalties for
> faulting. Does x86-64? Is sys$start_align_fault_report() et al. still
> relevant?

I suspect the VSI answer will be "It depends". Some instruction subsets
can either greatly benefit from or require alignment. Others, not so
much. With recent processor generations, alignment is not so much of an
issue, save for how much cache it might use.

VSI will be using llvm code generation for the foreseeable future too,
which mostly-avoids dealing with this for compiled code. A lot of folks
have looked at that code generation. At least until VSI has ~finished
the port, and starts profiling VSI and app code, that is.

"On the Sandy Bridge, there is no performance penalty for reading or
writing misaligned memory operands, except for the fact that it uses
more cache banks so that the risk of cache conflicts is higher when the
operand is misaligned. Store-to-load forwarding also works with
misaligned operands in most cases."

Page table swappage will be interesting to profile, as OpenVMS has
~twice the usual number of tables in use with the four-mode "emulation"
work.

Some related reading...

https://www.agner.org/optimize/
https://www.agner.org/forum/viewtopic.php?f=1&t=75&sid=9aec4d9491a7ec1f7d01e971651c13be

https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html
https://community.intel.com/t5/Software-Tuning-Performance/Why-should-data-be-aligned-to-16-bytes-for-SSE-instructions/m-p/1164004

https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/

--
Pure Personal Opinion | HoffmanLabs LLC

On 2/25/2022 11:37 PM, Bob Gezelter wrote:
> On Friday, February 25, 2022 at 7:12:55 PM UTC-5, Arne Vajhøj wrote:
>> On 2/25/2022 6:57 PM, 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?
>>>
>>> Hmmm. Using an alignment fault generator and reporter I'm seeing
>>> plenty on Alpha and Itanium; zero on x86-64.
>> I had an old Fortran program testing alignment overhead and I just
>> ran it on Windows x86-64 and it showed absolutely no overhead for
>> bad alignment of REAL*8 arrays (and there is a lot of overhead on
>> VMS Alpha and Itanium).
>>
>> I guess we can say welcome back to CISC. :-)
>
> With all due respect, the performance penalty for non-aligned
> references is still very real, speaking as one who did a lot of work
> on non-faulting IBM System/370 processors back in the day. The same
> was true with VAX CPUs. They did not fault, but they paid a
> performance penalty.
>
> There is a difference in context from the days of the System/370 and
> the VAX: multi-level large caches.
>
> The caches close to the processing core are very fast. This obscures
> the loss of performance due to non-aligned references. Second, all
> loads/stores to/from a cache are, almost by definition, aligned.
>
> A program designed to produce alignment faults is also very likely to
> not abuse the memory system in a way to detect the mis-aligned data
> penalty. Faults, which are synchronous interrupts, have overhead
> orders of magnitude more than a double memory fetch, particularly
> when sequential elements are referenced (sequential elements may well
> be in the same cache line, even if not aligned on the proper
> boundary).
>
> If I had the spare time to play with it, I would write a program to
> randomly address a storage area beyond total cache size, so that
> every memory reference is a cache miss. Run aligned and unaligned
> data references and compare the result.
>
> It is easy for a benchmark to measure the incorrect phenomenon.

There are lies, damn lies and benchmarks.

:-)

I tested on a 2 MB array.

And I admit that the results can be due to many things.

But the numbers sure show a big difference!

Fortran/VMS/Itanium:

OFFSET 0 : 590 ms
OFFSET 1 : 197510 ms
OFFSET 2 : 197510 ms
OFFSET 3 : 197520 ms
OFFSET 4 : 197510 ms
OFFSET 5 : 197510 ms
OFFSET 6 : 197510 ms
OFFSET 7 : 197510 ms
OFFSET 8 : 590 ms
OFFSET 9 : 197510 ms
OFFSET 10 : 197520 ms
OFFSET 11 : 197520 ms
OFFSET 12 : 197520 ms
OFFSET 13 : 197520 ms
OFFSET 14 : 197520 ms
OFFSET 15 : 197520 ms
OFFSET 16 : 580 ms

GFortran/Windows/x86-64 (100x more reps):

OFFSET 0 : 7473 ms
OFFSET 1 : 7285 ms
OFFSET 2 : 7301 ms
OFFSET 3 : 7301 ms
OFFSET 4 : 7269 ms
OFFSET 5 : 7208 ms
OFFSET 6 : 7191 ms
OFFSET 7 : 7192 ms
OFFSET 8 : 7519 ms
OFFSET 9 : 7285 ms
OFFSET 10 : 7270 ms
OFFSET 11 : 7285 ms
OFFSET 12 : 7270 ms
OFFSET 13 : 7207 ms
OFFSET 14 : 7176 ms
OFFSET 15 : 7176 ms
OFFSET 16 : 7473 ms

Arne

On Saturday, February 26, 2022 at 4:36:58 PM UTC-5, Arne Vajhøj wrote:
> On 2/25/2022 11:37 PM, Bob Gezelter wrote:
> > On Friday, February 25, 2022 at 7:12:55 PM UTC-5, Arne Vajhøj wrote:
> >> On 2/25/2022 6:57 PM, 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?
> >>>
> >>> Hmmm. Using an alignment fault generator and reporter I'm seeing
> >>> plenty on Alpha and Itanium; zero on x86-64.
> >> I had an old Fortran program testing alignment overhead and I just
> >> ran it on Windows x86-64 and it showed absolutely no overhead for
> >> bad alignment of REAL*8 arrays (and there is a lot of overhead on
> >> VMS Alpha and Itanium).
> >>
> >> I guess we can say welcome back to CISC. :-)
> >
> > With all due respect, the performance penalty for non-aligned
> > references is still very real, speaking as one who did a lot of work
> > on non-faulting IBM System/370 processors back in the day. The same
> > was true with VAX CPUs. They did not fault, but they paid a
> > performance penalty.
> >
> > There is a difference in context from the days of the System/370 and
> > the VAX: multi-level large caches.
> >
> > The caches close to the processing core are very fast. This obscures
> > the loss of performance due to non-aligned references. Second, all
> > loads/stores to/from a cache are, almost by definition, aligned.
> >
> > A program designed to produce alignment faults is also very likely to
> > not abuse the memory system in a way to detect the mis-aligned data
> > penalty. Faults, which are synchronous interrupts, have overhead
> > orders of magnitude more than a double memory fetch, particularly
> > when sequential elements are referenced (sequential elements may well
> > be in the same cache line, even if not aligned on the proper
> > boundary).
> >
> > If I had the spare time to play with it, I would write a program to
> > randomly address a storage area beyond total cache size, so that
> > every memory reference is a cache miss. Run aligned and unaligned
> > data references and compare the result.
> >
> > It is easy for a benchmark to measure the incorrect phenomenon.
> There are lies, damn lies and benchmarks.
>
> :-)
>
> I tested on a 2 MB array.
>
> And I admit that the results can be due to many things.
>
> But the numbers sure show a big difference!
>
> Fortran/VMS/Itanium:
>
> OFFSET 0 : 590 ms
> OFFSET 1 : 197510 ms
> OFFSET 2 : 197510 ms
> OFFSET 3 : 197520 ms
> OFFSET 4 : 197510 ms
> OFFSET 5 : 197510 ms
> OFFSET 6 : 197510 ms
> OFFSET 7 : 197510 ms
> OFFSET 8 : 590 ms
> OFFSET 9 : 197510 ms
> OFFSET 10 : 197520 ms
> OFFSET 11 : 197520 ms
> OFFSET 12 : 197520 ms
> OFFSET 13 : 197520 ms
> OFFSET 14 : 197520 ms
> OFFSET 15 : 197520 ms
> OFFSET 16 : 580 ms
>
> GFortran/Windows/x86-64 (100x more reps):
>
> OFFSET 0 : 7473 ms
> OFFSET 1 : 7285 ms
> OFFSET 2 : 7301 ms
> OFFSET 3 : 7301 ms
> OFFSET 4 : 7269 ms
> OFFSET 5 : 7208 ms
> OFFSET 6 : 7191 ms
> OFFSET 7 : 7192 ms
> OFFSET 8 : 7519 ms
> OFFSET 9 : 7285 ms
> OFFSET 10 : 7270 ms
> OFFSET 11 : 7285 ms
> OFFSET 12 : 7270 ms
> OFFSET 13 : 7207 ms
> OFFSET 14 : 7176 ms
> OFFSET 15 : 7176 ms
> OFFSET 16 : 7473 ms
>
> Arne
Arne,

One needs to analyze beyond raw performance. In this case, I start with the cache organization and related structure. If you "break" the cache, buy forcing every reference to be a cache miss, one will essentially see the 2x performance loss.

If the cache is able to gain anything, it will skew the numbers.

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

On 2022-02-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> GFortran/Windows/x86-64 (100x more reps):
>
> OFFSET 0 : 7473 ms
> OFFSET 1 : 7285 ms
> OFFSET 2 : 7301 ms
> OFFSET 3 : 7301 ms
> OFFSET 4 : 7269 ms
> OFFSET 5 : 7208 ms
> OFFSET 6 : 7191 ms
> OFFSET 7 : 7192 ms
> OFFSET 8 : 7519 ms
> OFFSET 9 : 7285 ms
> OFFSET 10 : 7270 ms
> OFFSET 11 : 7285 ms
> OFFSET 12 : 7270 ms
> OFFSET 13 : 7207 ms
> OFFSET 14 : 7176 ms
> OFFSET 15 : 7176 ms
> OFFSET 16 : 7473 ms
>

In situations like this Arne, it is _always_ a good idea to have
a look at the generated code just to make sure that the compiler
has not done anything unexpected.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

When the Alpha first came out its attackers used to provide
example code that performed very badly to prove they were
better. Wasn't this one of the methods used to write those
really bad performing programs? This and forcing repeated
dumping of the pipelined instructions?

bill

Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>When the Alpha first came out its attackers used to provide
>example code that performed very badly to prove they were
>better. Wasn't this one of the methods used to write those
>really bad performing programs? This and forcing repeated
>dumping of the pipelined instructions?

Yes, although has been pointed out, if you have a large enough array and do
random accesses so that a pull from main memory is needed with nearly every
one, you'll find the x86_64 also performs very badly.

But, having a whole lot of cache helps a whole lot at speeding up clean
well-written code with unaligned accesses, as is noted.

Unfortunately the code that people use to demonstrate defects in system
architectures is frequently little different than the code written by
inexperienced programmers.
--scott

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

On Sunday, February 27, 2022 at 6:43:41 AM UTC-8, Bill Gunshannon wrote:
> When the Alpha first came out its attackers used to provide
> example code that performed very badly to prove they were
> better. Wasn't this one of the methods used to write those
> really bad performing programs? This and forcing repeated
> dumping of the pipelined instructions?

As well as I remember it, Alpha only has 32 bit and 64 bit aligned
load/store instructions. If you want something else, you do it with
some other instructions. Shifts and such.

If the compiler does all that for you, it will be pretty slow.

In the Fortran 66 days, it was believe that Fortran COMMON didn't
allow for padding. Some systems would have complicated systems
to avoid problems. Ones that I remember trapped the alignment
exception, copied that data, reran the instruction, and maybe
copied data back.

But then came processors with imprecise interrupts, which
didn't allow finding the offending instruction.

But now COMMON, and C's struct, allow for padding, so it usually
isn't a problem.

Den 2022-02-27 kl. 21:16, skrev gah4:
> On Sunday, February 27, 2022 at 6:43:41 AM UTC-8, Bill Gunshannon wrote:
>> When the Alpha first came out its attackers used to provide
>> example code that performed very badly to prove they were
>> better. Wasn't this one of the methods used to write those
>> really bad performing programs? This and forcing repeated
>> dumping of the pipelined instructions?
>
> As well as I remember it, Alpha only has 32 bit and 64 bit aligned
> load/store instructions.

https://en.wikipedia.org/wiki/DEC_Alpha#Byte-Word_Extensions_(BWX)

On 2/26/2022 11:50 PM, Bob Gezelter wrote:
> On Saturday, February 26, 2022 at 4:36:58 PM UTC-5, Arne Vajhøj wrote:
>> On 2/25/2022 11:37 PM, Bob Gezelter wrote:
>>> It is easy for a benchmark to measure the incorrect phenomenon.
>> There are lies, damn lies and benchmarks.
>>
>> :-)
>>
>> I tested on a 2 MB array.
>>
>> And I admit that the results can be due to many things.
>>
>> But the numbers sure show a big difference!
>>
>> Fortran/VMS/Itanium:
>>
>> OFFSET 0 : 590 ms
>> OFFSET 1 : 197510 ms
>> OFFSET 2 : 197510 ms
>> OFFSET 3 : 197520 ms
>> OFFSET 4 : 197510 ms
>> OFFSET 5 : 197510 ms
>> OFFSET 6 : 197510 ms
>> OFFSET 7 : 197510 ms
>> OFFSET 8 : 590 ms
>> OFFSET 9 : 197510 ms
>> OFFSET 10 : 197520 ms
>> OFFSET 11 : 197520 ms
>> OFFSET 12 : 197520 ms
>> OFFSET 13 : 197520 ms
>> OFFSET 14 : 197520 ms
>> OFFSET 15 : 197520 ms
>> OFFSET 16 : 580 ms
>>
>> GFortran/Windows/x86-64 (100x more reps):
>>
>> OFFSET 0 : 7473 ms
>> OFFSET 1 : 7285 ms
>> OFFSET 2 : 7301 ms
>> OFFSET 3 : 7301 ms
>> OFFSET 4 : 7269 ms
>> OFFSET 5 : 7208 ms
>> OFFSET 6 : 7191 ms
>> OFFSET 7 : 7192 ms
>> OFFSET 8 : 7519 ms
>> OFFSET 9 : 7285 ms
>> OFFSET 10 : 7270 ms
>> OFFSET 11 : 7285 ms
>> OFFSET 12 : 7270 ms
>> OFFSET 13 : 7207 ms
>> OFFSET 14 : 7176 ms
>> OFFSET 15 : 7176 ms
>> OFFSET 16 : 7473 ms

> One needs to analyze beyond raw performance. In this case, I start
> with the cache organization and related structure. If you "break" the
> cache, buy forcing every reference to be a cache miss, one will
> essentially see the 2x performance loss.
>
> If the cache is able to gain anything, it will skew the numbers.

I modified the program to test with different data sizes, verified
that the code was indeed working on an unaligned addresses and
tried both sequential and random access to array.

I simply can't get a big difference between aligned and unaligned access.

Data at the bottom.

I am not saying that there are no cases where unaligned data access
make a significant difference.

But I have not been able to come up with a case.

Arne

DATA SIZE = 2500 ( 20000 BYTES), REP = 100000, SEQUENTIAL ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 717 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 718 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 718 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 717 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 718 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 733 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 718 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 717 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 718 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 717 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 718 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 718 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 717 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 733 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 718 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 733 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 718 ms
DATA SIZE = 25000 ( 200000 BYTES), REP = 10000, SEQUENTIAL ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 717 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 702 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 702 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 718 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 702 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 702 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 718 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 702 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 717 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 702 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 718 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 686 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 718 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 702 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 702 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 702 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 718 ms
DATA SIZE = 250000 ( 2000000 BYTES), REP = 1000, SEQUENTIAL ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 718 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 702 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 717 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 718 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 702 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 717 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 718 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 718 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 717 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 702 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 718 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 718 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 702 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 717 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 718 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 717 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 718 ms
DATA SIZE = 2500000 (20000000 BYTES), REP = 100, SEQUENTIAL ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 718 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 702 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 717 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 718 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 717 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 718 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 718 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 717 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 718 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 717 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 718 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 702 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 718 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 733 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 717 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 718 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 702 ms
DATA SIZE = 4096 ( 32768 BYTES), REP = 16666, RANDOM ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 733 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 733 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 734 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 733 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 733 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 733 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 733 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 734 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 717 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 733 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 734 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 748 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 734 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 733 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 733 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 733 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 718 ms
DATA SIZE = 32768 ( 262144 BYTES), REP = 1666, RANDOM ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 561 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 593 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 609 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 577 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 593 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 577 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 593 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 593 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 577 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 577 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 608 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 593 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 593 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 577 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 593 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 577 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 577 ms
DATA SIZE = 262144 ( 2097152 BYTES), REP = 166, RANDOM ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 609 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 624 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 639 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 624 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 640 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 624 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 640 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 624 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 608 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 624 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 624 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 639 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 624 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 624 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 640 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 624 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 608 ms
DATA SIZE = 2097152 (16777216 BYTES), REP = 16, RANDOM ACCESS
OFFSET 0 (ADDRESS MOD 8 = 0): 733 ms
OFFSET 1 (ADDRESS MOD 8 = 1): 749 ms
OFFSET 2 (ADDRESS MOD 8 = 2): 749 ms
OFFSET 3 (ADDRESS MOD 8 = 3): 749 ms
OFFSET 4 (ADDRESS MOD 8 = 4): 749 ms
OFFSET 5 (ADDRESS MOD 8 = 5): 748 ms
OFFSET 6 (ADDRESS MOD 8 = 6): 749 ms
OFFSET 7 (ADDRESS MOD 8 = 7): 749 ms
OFFSET 8 (ADDRESS MOD 8 = 0): 733 ms
OFFSET 9 (ADDRESS MOD 8 = 1): 749 ms
OFFSET 10 (ADDRESS MOD 8 = 2): 748 ms
OFFSET 11 (ADDRESS MOD 8 = 3): 749 ms
OFFSET 12 (ADDRESS MOD 8 = 4): 749 ms
OFFSET 13 (ADDRESS MOD 8 = 5): 749 ms
OFFSET 14 (ADDRESS MOD 8 = 6): 749 ms
OFFSET 15 (ADDRESS MOD 8 = 7): 764 ms
OFFSET 16 (ADDRESS MOD 8 = 0): 718 ms

On 2/27/2022 8:56 PM, Arne Vajhøj wrote:
> I simply can't get a big difference between aligned and unaligned access.
>
> Data at the bottom.
>
> I am not saying that there are no cases where unaligned data access
> make a significant difference.
>
> But I have not been able to come up with a case.

Code below in case anybody wonder WTF I am doing.

Arne

PROGRAM TEST_ALIGN
INTEGER*4 N,REP,OFFSET
PARAMETER (N=2500000,REP=100,OFFSET=17)
BYTE DUMMY(OFFSET)
REAL*8 X(N+(OFFSET-1)/8+1)
EQUIVALENCE (DUMMY,X)
INTEGER*4 I,J,SCALE(4)
DATA SCALE/1000,100,10,1/
DO 200 J=1,REP
DO 100 I=1,N+1
X(I)=I
100 CONTINUE
200 CONTINUE
DO 400 J=1,4
WRITE(6,700) N/SCALE(J),8*N/SCALE(J),REP*SCALE(J),
+ 'SEQUENTIAL ACCESS'
DO 300 I=1,OFFSET
CALL TEST(I,DUMMY(I),N/SCALE(J),REP*SCALE(J),.FALSE.)
300 CONTINUE
400 CONTINUE
DO 600 J=1,4
WRITE(6,700) 2**(9+3*J),8*2**(9+3*J),REP*SCALE(J)/6,
+ 'RANDOM ACCESS'
DO 500 I=1,OFFSET
CALL TEST(I,DUMMY(I),2**(9+3*J),REP*SCALE(J)/6,.TRUE.)
500 CONTINUE
600 CONTINUE
700 FORMAT(1X,'DATA SIZE = ',I7,' (',I8,' BYTES), REP = ',I6,', ',A)
END

and:

SUBROUTINE TEST(IX,X,N,REP,RANACC)
INTEGER*4 IX,N,REP
REAL*8 X(*)
LOGICAL*4 RANACC
INTEGER*4 I,T1,T2,DUMMY,RANIX
CALL SYSTEM_CLOCK(T1,DUMMY,DUMMY)
DO 200 J=1,REP
IF(RANACC) RANIX=0
DO 100 I=1,N
IF(RANACC) THEN
RANIX=MOD(401*RANIX+1,N)
X(RANIX+1)=I
ELSE
X(I)=I
ENDIF
100 CONTINUE
200 CONTINUE
CALL SYSTEM_CLOCK(T2,DUMMY,DUMMY)
IF(RANACC) THEN
WRITE(6,300) IX-1,MOD(LOC(X),8),T2-T1
ELSE
WRITE(6,300) IX-1,MOD(LOC(X),8),T2-T1
ENDIF
RETURN
300 FORMAT(1X,'OFFSET ',I2,' (ADDRESS MOD 8 = ',I1,'): ',I6,' ms')
END

On Friday, February 25, 2022 at 1:53:45 PM UTC-8, 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?

Ordinary instructions for x86 and x86-64 allow unaligned access.

Interlocked instructions, such as CMPXCHG16B require aligned
memory operands, in this case on a 16 byte boundary.

Interlocked operations allow for read-modify-write without allowing
any other task or thread, on any processor, in between.

On Sunday, February 27, 2022 at 3:16:43 PM UTC-5, gah4 wrote:
: > As well as I remember it, Alpha only has 32 bit and 64 bit aligned
> load/store instructions. If you want something else, you do it with
> some other instructions. Shifts and such.
>
> If the compiler does all that for you, it will be pretty slow.

Pretty slow is subjective of course. but really it wasn't too bad imho.

As long as the compiler exactly what to expect unaligned it fetched a larger aligned chunk, mask and shift as needed and onwards.

That was just a few clock cycles extra, MUCH less than the dozens of cycles the actual memory access would take.

If it had the check a suspect address it would be a bit longer.

Now if the compiler did not know or rather was mis-informed (about a dynamic data structure address) then an alignment trap would execute and thousands of instructions would execute some of them with system wide serialization. Ouch.

fwiw,
Hein.

On 2022-02-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I modified the program to test with different data sizes, verified
> that the code was indeed working on an unaligned addresses and
> tried both sequential and random access to array.
>
> I simply can't get a big difference between aligned and unaligned access.
>

Have you looked at the generated code to verify that unaligned access
is really occuring ?

Another possibility, depending on how smart the compiler is, is that
it could always do aligned access lookups and then only extract the
data it needs out of each lookup.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-02-28, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2022-02-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> I modified the program to test with different data sizes, verified
>> that the code was indeed working on an unaligned addresses and
>> tried both sequential and random access to array.
>>
>> I simply can't get a big difference between aligned and unaligned access.
>>
>
> Have you looked at the generated code to verify that unaligned access
> is really occuring ?
>
> Another possibility, depending on how smart the compiler is, is that
> it could always do aligned access lookups and then only extract the
> data it needs out of each lookup.
>

Also, the optimisation settings and level might make a difference.
Try varying them to see if the behaviour changes, especially when
you switch between optimising for time versus space (and yes, include
-O0 in the list of things you try. :-)).

It's for reasons like this that I suggested at the start of this
to look at the generated code, just in case the compiler is doing
something you are not expecting.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Monday, February 28, 2022 at 7:43:21 AM UTC-8, Hein RMS van den Heuvel wrote:
> On Sunday, February 27, 2022 at 3:16:43 PM UTC-5, gah4 wrote:
> :
> > As well as I remember it, Alpha only has 32 bit and 64 bit aligned
> > load/store instructions. If you want something else, you do it with
> > some other instructions. Shifts and such.
> >
> > If the compiler does all that for you, it will be pretty slow.

> Pretty slow is subjective of course. but really it wasn't too bad imho.
> As long as the compiler exactly what to expect unaligned it fetched a larger aligned chunk, mask and shift as needed and onwards.
(snip)

> Now if the compiler did not know or rather was mis-informed (about a dynamic data structure address) then an alignment trap would execute and thousands of instructions would execute some of them with system wide serialization. Ouch.

Fortunately, Fortran now allows for padding, such that COMMON variables can be aligned.

In the olden days, I believe before Fortran 90, padding wasn't allowed.
People then learned to arrange variables appropriately, with double precision
variables, usually with the strictest alignment, first.

Since you could take a COMMON array (where the compiler should know its alignment)
and pass it to a subroutine, where it wasn't known, that could happen.

I first learned about this on the IBM 360/91, which doesn't have the ability to fix them
at run time. Because of the pipelining, and especially out-of-order retirement, it doesn't
have the address where the alignment exception occurred. Other S/360 models could
fix it up, though slowly, processing the exception.

One that was a problem for some years, was that the 8087, with a 16 bit bus,
only needed 16 bit alignment. Then the 80486 could use 4 byte alignment,
and compilers (and linkers) supplied that. When Pentium was much slower
with misaligned 8 byte operands (that is, x87 double precision), it took some
years for compilers to adjust.

But since many RISC processors require alignment, people should be used
to it by now.

On Sunday, February 27, 2022 at 12:58:20 PM UTC-8, Jan-Erik Söderholm wrote:

(snip, I wrote)

> > As well as I remember it, Alpha only has 32 bit and 64 bit aligned
> > load/store instructions.

> https://en.wikipedia.org/wiki/DEC_Alpha#Byte-Word_Extensions_(BWX)

But does it really do 8 and 16 bit load/store, or just move the previous logic
into the instructions?

Well, as noted by others, in most case the only question is access to cache..
Cache will load/store some larger unit. But x86 needs the ability to do
byte and word I/O operations, without the read/modify/write cycle it can
use on memory. (Though with some complications on multi processor
systems.)

In the case of bytes and (16 bit) words, and before BWX, the load instruction
ignores the low bits, and loads the whole 32 or 64 bit unit. (As well as I
know, Alpha still calls 16 bits 'word'). Then there are instructions to move
around bytes and 16 bit words between registers, that ignore the high bits.

But misaligned larger data units take somewhat more work.

Does BWX allow, and especially process fast, load or store of a 64 bit
double from/to an odd address?

Arne Vajhøj wrote:
> On 2/27/2022 8:56 PM, Arne Vajhøj wrote:
>> I simply can't get a big difference between aligned and unaligned access.
>>
>> Data at the bottom.
>>
>> I am not saying that there are no cases where unaligned data access
>> make a significant difference.
>>
>> But I have not been able to come up with a case.
>
> Code below in case anybody wonder WTF I am doing.
>
> Arne
>
> PROGRAM TEST_ALIGN
> INTEGER*4 N,REP,OFFSET
> PARAMETER (N=2500000,REP=100,OFFSET=17)
> BYTE DUMMY(OFFSET)
> REAL*8 X(N+(OFFSET-1)/8+1)
> EQUIVALENCE (DUMMY,X)
> INTEGER*4 I,J,SCALE(4)
> DATA SCALE/1000,100,10,1/
> DO 200 J=1,REP
> DO 100 I=1,N+1
> X(I)=I
> 100 CONTINUE
> 200 CONTINUE
> DO 400 J=1,4
> WRITE(6,700) N/SCALE(J),8*N/SCALE(J),REP*SCALE(J),
> + 'SEQUENTIAL ACCESS'
> DO 300 I=1,OFFSET
> CALL TEST(I,DUMMY(I),N/SCALE(J),REP*SCALE(J),.FALSE.)
> 300 CONTINUE
> 400 CONTINUE
> DO 600 J=1,4
> WRITE(6,700) 2**(9+3*J),8*2**(9+3*J),REP*SCALE(J)/6,
> + 'RANDOM ACCESS'
> DO 500 I=1,OFFSET
> CALL TEST(I,DUMMY(I),2**(9+3*J),REP*SCALE(J)/6,.TRUE.)
> 500 CONTINUE
> 600 CONTINUE
> 700 FORMAT(1X,'DATA SIZE = ',I7,' (',I8,' BYTES), REP = ',I6,', ',A)
> END
>
> and:
>
> SUBROUTINE TEST(IX,X,N,REP,RANACC)
> INTEGER*4 IX,N,REP
> REAL*8 X(*)
> LOGICAL*4 RANACC
> INTEGER*4 I,T1,T2,DUMMY,RANIX
> CALL SYSTEM_CLOCK(T1,DUMMY,DUMMY)
> DO 200 J=1,REP
> IF(RANACC) RANIX=0
> DO 100 I=1,N
> IF(RANACC) THEN
> RANIX=MOD(401*RANIX+1,N)
> X(RANIX+1)=I
> ELSE
> X(I)=I
> ENDIF
> 100 CONTINUE
> 200 CONTINUE
> CALL SYSTEM_CLOCK(T2,DUMMY,DUMMY)
> IF(RANACC) THEN
> WRITE(6,300) IX-1,MOD(LOC(X),8),T2-T1
> ELSE
> WRITE(6,300) IX-1,MOD(LOC(X),8),T2-T1
> ENDIF
> RETURN
> 300 FORMAT(1X,'OFFSET ',I2,' (ADDRESS MOD 8 = ',I1,'): ',I6,' ms')
> END
>

As others commented: The compiler may have optimized the allignment away
by calling subroutine test. Maybe you should force the misalligment by
using common-blocks instead of passing as variables.

Jouk

On 3/3/2022 9:02 AM, Joukj wrote:
> Arne Vajhøj wrote:
>> Code below in case anybody wonder WTF I am doing.

>>       PROGRAM TEST_ALIGN
>>       INTEGER*4 N,REP,OFFSET
>>       PARAMETER (N=2500000,REP=100,OFFSET=17)
>>       BYTE DUMMY(OFFSET)
>>       REAL*8 X(N+(OFFSET-1)/8+1)
>>       EQUIVALENCE (DUMMY,X)
>>       INTEGER*4 I,J,SCALE(4)
>>       DATA SCALE/1000,100,10,1/
>>       DO 200 J=1,REP
>>         DO 100 I=1,N+1
>>           X(I)=I
>> 100     CONTINUE
>> 200   CONTINUE
>>       DO 400 J=1,4
>>         WRITE(6,700) N/SCALE(J),8*N/SCALE(J),REP*SCALE(J),
>>      +               'SEQUENTIAL ACCESS'
>>         DO 300 I=1,OFFSET
>>             CALL TEST(I,DUMMY(I),N/SCALE(J),REP*SCALE(J),.FALSE.)
>> 300     CONTINUE
>> 400   CONTINUE
>>       DO 600 J=1,4
>>         WRITE(6,700) 2**(9+3*J),8*2**(9+3*J),REP*SCALE(J)/6,
>>      +               'RANDOM ACCESS'
>>         DO 500 I=1,OFFSET
>>             CALL TEST(I,DUMMY(I),2**(9+3*J),REP*SCALE(J)/6,.TRUE.)
>> 500     CONTINUE
>> 600   CONTINUE
>> 700   FORMAT(1X,'DATA SIZE = ',I7,' (',I8,' BYTES), REP = ',I6,', ',A)
>>       END
>>
>> and:
>>
>>       SUBROUTINE TEST(IX,X,N,REP,RANACC)
>>       INTEGER*4 IX,N,REP
>>       REAL*8 X(*)
>>       LOGICAL*4 RANACC
>>       INTEGER*4 I,T1,T2,DUMMY,RANIX
>>       CALL SYSTEM_CLOCK(T1,DUMMY,DUMMY)
>>       DO 200 J=1,REP
>>         IF(RANACC) RANIX=0
>>         DO 100 I=1,N
>>           IF(RANACC) THEN
>>             RANIX=MOD(401*RANIX+1,N)
>>             X(RANIX+1)=I
>>           ELSE
>>             X(I)=I
>>           ENDIF
>> 100     CONTINUE
>> 200   CONTINUE
>>       CALL SYSTEM_CLOCK(T2,DUMMY,DUMMY)
>>       IF(RANACC) THEN
>>         WRITE(6,300) IX-1,MOD(LOC(X),8),T2-T1
>>       ELSE
>>         WRITE(6,300) IX-1,MOD(LOC(X),8),T2-T1
>>       ENDIF
>>       RETURN
>> 300   FORMAT(1X,'OFFSET ',I2,' (ADDRESS MOD 8 = ',I1,'): ',I6,' ms')
>>       END
>>
>
> As others commented: The compiler may have optimized the allignment away
> by calling subroutine test.

They are compiled separately.

In the main program test is being called with a byte array. The compiler
does not know that it is being treated as floating point array in the
subroutine.

In the subroutine it believes it receives a floating point array. The
compiler does not know that it is actually being called with a byte
array.

Let us say that the subroutine is being called with the address
1028 and array size 3.

I consider it valid compiler behavior to:
- update 3 FP's at 1028, 1036 and 1044
- throw an error for unaligned access

I consider it a compiler bug to:
- update 3 FP's at 1024, 1032 and 1040
- update 3 FP's at 1032, 1040 and 1048
- update 2 FP's at 1032 and 1040

Arne

On 2/28/2022 1:55 PM, Simon Clubley wrote:
> On 2022-02-28, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2022-02-27, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> I modified the program to test with different data sizes, verified
>>> that the code was indeed working on an unaligned addresses and
>>> tried both sequential and random access to array.
>>>
>>> I simply can't get a big difference between aligned and unaligned access.
>>>
>>
>> Have you looked at the generated code to verify that unaligned access
>> is really occuring ?
>>
>> Another possibility, depending on how smart the compiler is, is that
>> it could always do aligned access lookups and then only extract the
>> data it needs out of each lookup.
>>
>
> Also, the optimisation settings and level might make a difference.
> Try varying them to see if the behaviour changes, especially when
> you switch between optimising for time versus space (and yes, include
> -O0 in the list of things you try. :-)).

No alignment effect in neither default, -O0 or -O3.

> It's for reasons like this that I suggested at the start of this
> to look at the generated code, just in case the compiler is doing
> something you are not expecting.

I am not good enough in x86-64 assembler to see if it does
anything unexpected.

SUBROUTINE TEST(IX,X,N,REP)
INTEGER*4 IX,N,REP
REAL*8 X(*)
INTEGER*4 I,T1,T2,DUMMY
CALL SYSTEM_CLOCK(T1,DUMMY,DUMMY)
DO 200 J=1,REP
DO 100 I=1,N
X(I)=I
100 CONTINUE
200 CONTINUE
CALL SYSTEM_CLOCK(T2,DUMMY,DUMMY)
WRITE(6,300) IX-1,T2-T1
RETURN
300 FORMAT(1X,'OFFSET ',I2,' : ',I6,' ms')
END

becomes:

.seh_proc test_
test_:
pushq %r13
.seh_pushreg %r13
pushq %r12
.seh_pushreg %r12
pushq %rbp
.seh_pushreg %rbp
pushq %rdi
.seh_pushreg %rdi
pushq %rsi
.seh_pushreg %rsi
pushq %rbx
.seh_pushreg %rbx
subq $600, %rsp
.seh_stackalloc 600
.seh_endprologue
movq %r9, %rbp
movq %rcx, %rbx
movq %rdx, %rsi
movq %r8, %r12
leaq 40(%rsp), %rdx
leaq 36(%rsp), %rcx
leaq 44(%rsp), %r8
call _gfortran_system_clock_4
movl 0(%rbp), %r11d
movl 36(%rsp), %edi
testl %r11d, %r11d
jle .L2
movl (%r12), %r8d
testl %r8d, %r8d
jle .L2
movl %r8d, %eax
movl %r8d, %ebp
addl $1, %r11d
movl $1, %ecx
shrl $2, %eax
andl $-4, %ebp
movdqa .LC1(%rip), %xmm3
leal -1(%r8), %r12d
subl $1, %eax
leal 1(%rbp), %r13d
salq $5, %rax
leaq 32(%rsi,%rax), %rdx
.p2align 4,,10
.p2align 3
..L6:
cmpl $2, %r12d
jbe .L7
movdqa .LC0(%rip), %xmm1
movq %rsi, %rax
.p2align 4,,10
.p2align 3
..L4:
movdqa %xmm1, %xmm0
addq $32, %rax
paddd %xmm3, %xmm1
cvtdq2pd %xmm0, %xmm2
pshufd $238, %xmm0, %xmm0
movups %xmm2, -32(%rax)
cvtdq2pd %xmm0, %xmm0
movups %xmm0, -16(%rax)
cmpq %rdx, %rax
jne .L4
movl %r13d, %eax
cmpl %ebp, %r8d
je .L5
..L3:
pxor %xmm0, %xmm0
movslq %eax, %r9
leal 1(%rax), %r10d
cvtsi2sdl %eax, %xmm0
leaq (%rsi,%r9,8), %r9
movsd %xmm0, -8(%r9)
cmpl %r10d, %r8d
jl .L5
pxor %xmm0, %xmm0
addl $2, %eax
cvtsi2sdl %r10d, %xmm0
movsd %xmm0, (%r9)
cmpl %eax, %r8d
jl .L5
pxor %xmm0, %xmm0
cvtsi2sdl %eax, %xmm0
movsd %xmm0, 8(%r9)
..L5:
addl $1, %ecx
cmpl %r11d, %ecx
jne .L6
..L2:
leaq 52(%rsp), %rdx
leaq 56(%rsp), %r8
leaq 48(%rsp), %rcx
leaq 64(%rsp), %r12
call _gfortran_system_clock_4
leaq .LC2(%rip), %rax
movq %r12, %rcx
movl 48(%rsp), %esi
movq %rax, 72(%rsp)
leaq .LC3(%rip), %rax
leaq 60(%rsp), %r13
movq %rax, 144(%rsp)
movq .LC4(%rip), %rax
subl %edi, %esi
movl $12, 80(%rsp)
movq %rax, 64(%rsp)
movq $32, 152(%rsp)
call _gfortran_st_write
movl (%rbx), %eax
movq %r13, %rdx
movq %r12, %rcx
movl $4, %r8d
subl $1, %eax
movl %eax, 60(%rsp)
call _gfortran_transfer_integer_write
movq %r13, %rdx
movq %r12, %rcx
movl %esi, 60(%rsp)
movl $4, %r8d
call _gfortran_transfer_integer_write
movq %r12, %rcx
call _gfortran_st_write_done
nop
addq $600, %rsp
popq %rbx
popq %rsi
popq %rdi
popq %rbp
popq %r12
popq %r13
ret
..L7:
movl $1, %eax
jmp .L3
.seh_endproc

Arne

On Monday, March 7, 2022 at 9:41:17 PM UTC-5, Arne Vajhøj wrote:
> On 2/28/2022 1:55 PM, Simon Clubley wrote:
> > On 2022-02-28, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> >> On 2022-02-27, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> >>>
> >>> I modified the program to test with different data sizes, verified
> >>> that the code was indeed working on an unaligned addresses and
> >>> tried both sequential and random access to array.
> >>>
> >>> I simply can't get a big difference between aligned and unaligned access.
> >>>
> >>
> >> Have you looked at the generated code to verify that unaligned access
> >> is really occuring ?
> >>
> >> Another possibility, depending on how smart the compiler is, is that
> >> it could always do aligned access lookups and then only extract the
> >> data it needs out of each lookup.
> >>
> >
> > Also, the optimisation settings and level might make a difference.
> > Try varying them to see if the behaviour changes, especially when
> > you switch between optimising for time versus space (and yes, include
> > -O0 in the list of things you try. :-)).
> No alignment effect in neither default, -O0 or -O3.
> > It's for reasons like this that I suggested at the start of this
> > to look at the generated code, just in case the compiler is doing
> > something you are not expecting.
> I am not good enough in x86-64 assembler to see if it does
> anything unexpected.
>
> SUBROUTINE TEST(IX,X,N,REP)
> INTEGER*4 IX,N,REP
> REAL*8 X(*)
> INTEGER*4 I,T1,T2,DUMMY
> CALL SYSTEM_CLOCK(T1,DUMMY,DUMMY)
> DO 200 J=1,REP
> DO 100 I=1,N
> X(I)=I
> 100 CONTINUE
> 200 CONTINUE
> CALL SYSTEM_CLOCK(T2,DUMMY,DUMMY)
> WRITE(6,300) IX-1,T2-T1
> RETURN
> 300 FORMAT(1X,'OFFSET ',I2,' : ',I6,' ms')
> END
>
> becomes:
>
> .seh_proc test_
> test_:
> pushq %r13
> .seh_pushreg %r13
> pushq %r12
> .seh_pushreg %r12
> pushq %rbp
> .seh_pushreg %rbp
> pushq %rdi
> .seh_pushreg %rdi
> pushq %rsi
> .seh_pushreg %rsi
> pushq %rbx
> .seh_pushreg %rbx
> subq $600, %rsp
> .seh_stackalloc 600
> .seh_endprologue
> movq %r9, %rbp
> movq %rcx, %rbx
> movq %rdx, %rsi
> movq %r8, %r12
> leaq 40(%rsp), %rdx
> leaq 36(%rsp), %rcx
> leaq 44(%rsp), %r8
> call _gfortran_system_clock_4
> movl 0(%rbp), %r11d
> movl 36(%rsp), %edi
> testl %r11d, %r11d
> jle .L2
> movl (%r12), %r8d
> testl %r8d, %r8d
> jle .L2
> movl %r8d, %eax
> movl %r8d, %ebp
> addl $1, %r11d
> movl $1, %ecx
> shrl $2, %eax
> andl $-4, %ebp
> movdqa .LC1(%rip), %xmm3
> leal -1(%r8), %r12d
> subl $1, %eax
> leal 1(%rbp), %r13d
> salq $5, %rax
> leaq 32(%rsi,%rax), %rdx
> .p2align 4,,10
> .p2align 3
> .L6:
> cmpl $2, %r12d
> jbe .L7
> movdqa .LC0(%rip), %xmm1
> movq %rsi, %rax
> .p2align 4,,10
> .p2align 3
> .L4:
> movdqa %xmm1, %xmm0
> addq $32, %rax
> paddd %xmm3, %xmm1
> cvtdq2pd %xmm0, %xmm2
> pshufd $238, %xmm0, %xmm0
> movups %xmm2, -32(%rax)
> cvtdq2pd %xmm0, %xmm0
> movups %xmm0, -16(%rax)
> cmpq %rdx, %rax
> jne .L4
> movl %r13d, %eax
> cmpl %ebp, %r8d
> je .L5
> .L3:
> pxor %xmm0, %xmm0
> movslq %eax, %r9
> leal 1(%rax), %r10d
> cvtsi2sdl %eax, %xmm0
> leaq (%rsi,%r9,8), %r9
> movsd %xmm0, -8(%r9)
> cmpl %r10d, %r8d
> jl .L5
> pxor %xmm0, %xmm0
> addl $2, %eax
> cvtsi2sdl %r10d, %xmm0
> movsd %xmm0, (%r9)
> cmpl %eax, %r8d
> jl .L5
> pxor %xmm0, %xmm0
> cvtsi2sdl %eax, %xmm0
> movsd %xmm0, 8(%r9)
> .L5:
> addl $1, %ecx
> cmpl %r11d, %ecx
> jne .L6
> .L2:
> leaq 52(%rsp), %rdx
> leaq 56(%rsp), %r8
> leaq 48(%rsp), %rcx
> leaq 64(%rsp), %r12
> call _gfortran_system_clock_4
> leaq .LC2(%rip), %rax
> movq %r12, %rcx
> movl 48(%rsp), %esi
> movq %rax, 72(%rsp)
> leaq .LC3(%rip), %rax
> leaq 60(%rsp), %r13
> movq %rax, 144(%rsp)
> movq .LC4(%rip), %rax
> subl %edi, %esi
> movl $12, 80(%rsp)
> movq %rax, 64(%rsp)
> movq $32, 152(%rsp)
> call _gfortran_st_write
> movl (%rbx), %eax
> movq %r13, %rdx
> movq %r12, %rcx
> movl $4, %r8d
> subl $1, %eax
> movl %eax, 60(%rsp)
> call _gfortran_transfer_integer_write
> movq %r13, %rdx
> movq %r12, %rcx
> movl %esi, 60(%rsp)
> movl $4, %r8d
> call _gfortran_transfer_integer_write
> movq %r12, %rcx
> call _gfortran_st_write_done
> nop
> addq $600, %rsp
> popq %rbx
> popq %rsi
> popq %rdi
> popq %rbp
> popq %r12
> popq %r13
> ret
> .L7:
> movl $1, %eax
> jmp .L3
> .seh_endproc
>
> Arne
Looks to me like the memory references are longwords and the required portion is obtained via shifting. You won't see alignment issues here.

Dan

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.