Re: Alignment, can I do something about it?

[Melzzzzz]

On 13 Dec 2015 13:41:37 GMT
r...@zedat.fu-berlin.de (Stefan Ram) wrote:

> I have a vector filled with about 16000 unsigned ints,
> which seem to have 4 bytes each here.
>
> /* at file scope, after »using NUMBER = unsigned int;«: */
>
> ::std::vector<NUMBER> collection;
>
> I have an »inner loop«, where no new entries are added to
> the vector and the result of collection.data() is accessed
> as an array. It searches through subsets of the array, and
> therefore the accesses might be somewhat irregular (for the
> prefetcher). I wondered whether that array still fits in some
> cache.
>
> Now, I looked at the program with a stack monitor. It shows
> always (whenever probed) something like this, under Windows:
>
> ntoskrnl.exe!KeWaitForMultipleObjects
> ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel
> ntoskrnl.exe!KeWaitForSingleObject
> ntoskrnl.exe!_misaligned_access
> ntoskrnl.exe!_misaligned_access
> ntoskrnl.exe!_misaligned_access
> SlowProgram.exe
> SlowProgram.exe
> SlowProgram.exe
> SlowProgram.exe
> SlowProgram.exe
> kernel32.dll!BaseThreadInitThunk
> ntdll.dll!RtlUserThreadStart
>
> What's this? My program spends most of its time to »wait
> for multiple objects«??

It's a Windows thing.

>
> I do not call »_misaligned_access« directly in my SlowProgram!
>
> Is this the processor causing an interrupt due to misaligned
> data very often?

Nope. You get align exceptions on x86 only if loading SSE vectors.

>
> I used to believe that C++ would align my vector of ints so
> that this doesn't happen.

Try with custom allocator and see.

[mark]

> I do not call »_misaligned_access« directly in my SlowProgram!
>
> Is this the processor causing an interrupt due to misaligned
> data very often?
>

> I used to believe that C++ would align my vector of ints so
> that this doesn't happen.
>

> Is it because my CPU is called a »64-bit CPU« and the ints
> are 32-bit objects? So, should I try to use 64-bit objects?

There is no penalty on current Intel/AMD x64 CPUs for unaligned access.
There never was a significant one and no interrupts or hardware
exceptions are generated.

Chances are 99.999% that your vector is 8-byte aligned to begin with
(unless you went out of your way to set up some weird memory allocator).
You can cast vector.data() to uintptr_t to check the alignment - on x64,
the address space is as straightforward as it gets. A pointer is
basically a 64-bit unsigned int.

Your stack trace may well be from a GUI thread or a thread pool where a
worker has nothing to do.

Are you sure this a stack trace from your collection processing code in
the first place?

[Paavo Helde]

r...@zedat.fu-berlin.de (Stefan Ram) wrote in news:slow-vector-
2015121...@ram.dialup.fu-berlin.de:

This stack looks like some auxiliary service thread possibly created by
gcc itself. Find your actual working thread and study it instead.

Note also that it is not guaranteed at all that a "stack monitor" is able
to display correct stacks, especially for optimized compilations. In my
experience they are often at least partially garbage.

Cheers
Paavo

[mark]

On 2015-12-13 16:57, Stefan Ram wrote:

> mark <ma...@invalid.invalid> writes:
>> Are you sure this a stack trace from your collection processing code in
>> the first place?
>

> I post my C++ source code below. This is raw source code as is;
> [...]

There is nothing wrong with your code, it's not spending time in the
kernel. What you are seeing in the stack trace is an artifact of the
tool you are using to capture the stack trace (try a real debugger or
profiler).