https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89557

--- Comment #3 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail 
dot com> ---
(In reply to Jakub Jelinek from comment #2)
> -Og is not meant to generate code with good performance, but code which is
> easy to debug, so benchmarking something with -Og makes no sense.

I agree on the first part of your sentence. On the other hand, -Og is in my
opinion the best among the -O? options for C/C++ developers to use during the
development cycle and I believe -Og was originally intended to be used by
developers, so we should care about its performance because of its presumably
non-negligible userbase.

> That said, if znver1 has slow movaps and it is confirmed on something other
> than a microbenchmark, then we should adjust tuning to avoid using it for
> memory copying.

I think a carefully selected use of znver1 16-byte movaps isn't slow, but it is
slow at least in the case when it is preceded by two 8-byte stores or more
generally by any partial store to the 16 bytes in memory.

A little piece of code enables to clearly demonstrate the cause of a problem in
order to suggest an optimization rule for the compiler to follow. The IPC data
I measured are from a larger application, and I was directed to the seemingly
short code fragment by using "perf record" because it is a performance issue in
the larger app.

The 16-byte struct is fundamental to the application and I cannot avoid using
it at this point in time, although I can remove the 16-byte alignment attribute
which causes movaps to be generated.

In general, imposing a 16-byte alignment on any C/C++ data structure with size
>= 16 bytes shouldn't slow down any program by a factor of 2. It can be
expected to increase or decrease performance by say a factor of 1.1 depending
on workload. A factor of 2 slowdown is unexpected.

It would be interesting to see what would happen to performance if all data
structures in C/C++ codes with size >= 16 bytes were annotated to be aligned to
16 bytes. I don't have performance measurements about such general use of the
aligned(16) attribute.

Thank you for your reply.

Reply via email to