[llvm-bugs] [Bug 25335] New: atomics are 20x slower compared to gcc if atomic<T>'s T is a packed struct

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=25335

            Bug ID: 25335
           Summary: atomics are 20x slower compared to gcc if atomic<T>'s
                    T is a packed struct
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: sami.liedes at iki.fi
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Consider this code:

------------------------------------------------------------
#include <array>
#include <atomic>
#include <cstdint>
#include <iostream>

struct Entry {
    uint32_t pos;
};

constexpr size_t N = 1000000000;

std::array<std::atomic<Entry>, N> *arr;

int main() {
    arr = new std::array<std::atomic<Entry>, N>();

    std::cout << "lock_free(): " << (*arr)[100].is_lock_free() << std::endl;

    for (size_t i=0; i<N; i++) {
        Entry e;
        e.pos = 1;
        (*arr)[i].store(e, std::memory_order_relaxed);
    }
}
------------------------------------------------------------

When compiled with gcc 4.9 -std=c++14 -O3 for x86_64:

------------------------------------------------------------
$ time ./atomic_bench.gcc
lock_free(): 1

real    0m0.689s
user    0m0.490s
sys     0m0.198s
------------------------------------------------------------

When compiled with recent clang HEAD, -std=c++14 -O3:

------------------------------------------------------------
$ time ./atomic_bench.clang
lock_free(): 1

real    0m11.120s
user    0m10.931s
sys     0m0.187s
------------------------------------------------------------

Profiling shows that the bunch of the time is spent in __atomic_store_4.

Curiously, removing the packed attribute from the struct makes clang as fast as
gcc. However, it is a 4-byte struct; there hardly is a reason why writing it
entirely could not be just as fast as a 4-byte integer.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20151028/35d6284a/attachment.html>