std :: vector <uint8_t> C++ 11/14を有効にしたときにmemcpyを呼び出す代わりに手動でコピーする

Question

gina 4.9を使用してLinaroツールチェーンを使用してARM用クロスコンパイルを実行した結果、-std=c++14を追加するとvector.assign()のコンパイル結果が見つかりました。重要性のパフォーマンスの問題を引き起こす方法。

私はこの割り当て+コピーを行ういくつかの異なる方法を試しましたが、すべて私はstd::vectorを使用している限り、このパフォーマンスの問題があります。

私はこのおもちゃの例で問題を再現することができます

：

VectorTest.h

#include <stdint.h> 
#include <stddef.h> 
#include <vector> 

struct VectorWrapper_t 
{ 
    VectorWrapper_t(uint8_t const* pData, size_t length); 
    std::vector<uint8_t> data; 
}; 

VectorTest.cpp

#include "VectorTest.h" 

VectorWrapper_t::VectorWrapper_t(uint8_t const* pData, size_t length) 
{ 
    data.assign(pData, pData + length); 
} 

gccのフラグ：

-std=c++14 \ 
-mthumb -march=armv7-a -mtune=cortex-a9 \ 
-mlittle-endian -mfloat-abi=hard -mfpu=neon -Wa,-mimplicit-it=thumb \ 
-O2 -g 

アセンブリを見ると、元のバージョン（C++ 03、私は仮定していますか？）がmemmoveを呼び出すのに対し、C++ 14バージョンでは代わりにデータをコピーしているような余分なループが追加されている手動でgccが-fverbose-asmで追加した.locタグを見ると、このループの手順はstl_construct.hとstl_uninitialized.hになります。

gcc 5.2.1（C++ 14）に変更すると、memmoveの代わりにmemcpyを除いて、C++ 03の例とほぼ同じようにコンパイルされます。

ここでvectorの代わりにstd::unique_ptr<uint8_t[]>を使用してこの問題を回避することができます。しかし、vectorを使用している他の場所でパフォーマンスの問題が発生する可能性があり、修正する方法がある（gcc 5.2へのアップデートは現実的ではありません）。

私の質問は：なぜC++ 11/14では別の方法でコンパイルされますか？参考のため

、gcc --versionレポート：
arm-linux-gnueabihf-gcc (Linaro GCC 4.9-2014.12) 4.9.3 20141205 (prerelease)。

ここで生成されたアセンブリGCCは次のとおりです。

# C++03, gcc 4.9 

    push {r3, r4, r5, r6, r7, lr} @ 
    movs r3, #0 @ tmp118, 
    mov r4, r0 @ this, this 
    str r3, [r0] @ tmp118, MEM[(struct _Vector_impl *)this_1(D)]._M_start 
    mov r5, r2 @ length, length 
    str r3, [r0, #4] @ tmp118, MEM[(struct _Vector_impl *)this_1(D)]._M_finish 
    str r3, [r0, #8] @ tmp118, MEM[(struct _Vector_impl *)this_1(D)]._M_end_of_storage 
    cbnz r2, .L19 @ length, 
    mov r0, r4 @, this 
    pop {r3, r4, r5, r6, r7, pc} @ 
.L19: 
    mov r0, r2 @, length 
    mov r6, r1 @ pData, pData 
    bl _Znwj @ 
    mov r2, r5 @, length 
    mov r1, r6 @, pData 
    mov r7, r0 @ D.13516, 
    bl memmove @ 
    ldr r0, [r4] @ D.13515, MEM[(struct vector *)this_1(D)].D.11902._M_impl._M_start 
    cbz r0, .L3 @ D.13515, 
    bl _ZdlPv @ 
.L3: 
    add r5, r5, r7 @ D.13515, D.13516 
    str r7, [r4] @ D.13516, MEM[(struct vector *)this_1(D)].D.11902._M_impl._M_start 
    str r5, [r4, #4] @ D.13515, MEM[(struct vector *)this_1(D)].D.11902._M_impl._M_finish 
    mov r0, r4 @, this 
    str r5, [r4, #8] @ D.13515, MEM[(struct vector *)this_1(D)].D.11902._M_impl._M_end_of_storage 
    pop {r3, r4, r5, r6, r7, pc} @ 
.L6: 
    ldr r0, [r4] @ D.13515, MEM[(struct _Vector_base *)this_1(D)]._M_impl._M_start 
    cbz r0, .L5 @ D.13515, 
    bl _ZdlPv @ 
.L5: 
    bl __cxa_end_cleanup @ 

# C++14, gcc 4.9 

    push {r3, r4, r5, r6, r7, lr} @ 
    movs r3, #0 @ tmp157, 
    mov r6, r0 @ this, this 
    str r3, [r0] @ tmp157, MEM[(struct _Vector_impl *)this_1(D)]._M_start 
    mov r5, r2 @ length, length 
    str r3, [r0, #4] @ tmp157, MEM[(struct _Vector_impl *)this_1(D)]._M_finish 
    str r3, [r0, #8] @ tmp157, MEM[(struct _Vector_impl *)this_1(D)]._M_end_of_storage 
    cbnz r2, .L25 @ length, 
    mov r0, r6 @, this 
    pop {r3, r4, r5, r6, r7, pc} @ 
.L25: 
    mov r0, r2 @, length 
    mov r4, r1 @ pData, pData 
    bl _Znwj @ 
    adds r3, r4, r5 @ D.20345, pData, length 
    mov r7, r0 @ __result, 
    cmp r4, r3 @ pData, D.20345 
    ittt ne 
    addne r1, r4, #-1 @ ivtmp.76, pData, 
    movne r3, r0 @ __result, __result 
    addne r4, r0, r5 @ D.20346, __result, length 
    beq .L26 @, 
.L7: 
    ldrb r2, [r1, #1]! @ zero_extendqisi2 @ D.20348, MEM[base: _48, offset: 0] 
    cbz r3, .L6 @ __result, 
    strb r2, [r3] @ D.20348, MEM[base: __result_23, offset: 0B] 
.L6: 
    adds r3, r3, #1 @ __result, __result, 
    cmp r3, r4 @ __result, D.20346 
    bne .L7 @, 
.L8: 
    ldr r0, [r6] @ D.20346, MEM[(struct vector *)this_1(D)].D.18218._M_impl._M_start 
    cbz r0, .L5 @ D.20346, 
    bl _ZdlPv @ 
.L5: 
    str r7, [r6] @ __result, MEM[(struct vector *)this_1(D)].D.18218._M_impl._M_start 
    mov r0, r6 @, this 
    str r4, [r6, #4] @ D.20346, MEM[(struct vector *)this_1(D)].D.18218._M_impl._M_finish 
    str r4, [r6, #8] @ D.20346, MEM[(struct vector *)this_1(D)].D.18218._M_impl._M_end_of_storage 
    pop {r3, r4, r5, r6, r7, pc} @ 
.L26: 
    adds r4, r0, r5 @ D.20346, __result, length 
    b .L8 @ 
.L11: 
    ldr r0, [r6] @ D.20346, MEM[(struct _Vector_base *)this_1(D)]._M_impl._M_start 
    cbz r0, .L10 @ D.20346, 
    bl _ZdlPv @ 
.L10: 
    bl __cxa_end_cleanup @ 

# C++14, gcc 5.2 

    push {r3, r4, r5, r6, r7, lr} @ 
    movs r3, #0 @ tmp118, 
    mov r4, r0 @ this, this 
    str r3, [r0] @ tmp118, MEM[(struct _Vector_impl *)this_1(D)]._M_start 
    str r3, [r0, #4] @ tmp118, MEM[(struct _Vector_impl *)this_1(D)]._M_finish 
    str r3, [r0, #8] @ tmp118, MEM[(struct _Vector_impl *)this_1(D)]._M_end_of_storage 
    cbnz r2, .L19 @ length, 
    mov r0, r4 @, this 
    pop {r3, r4, r5, r6, r7, pc} @ 
.L19: 
    mov r0, r2 @, length 
    mov r6, r1 @ pData, pData 
    mov r5, r2 @ length, length 
    bl _Znwj @ 
    mov r2, r5 @, length 
    mov r1, r6 @, pData 
    mov r7, r0 @ D.20824, 
    bl memcpy @ 
    ldr r0, [r4] @ D.20823, MEM[(struct vector *)this_1(D)].D.18751._M_impl._M_start 
    cbz r0, .L3 @ D.20823, 
    bl _ZdlPv @ 
.L3: 
    add r5, r5, r7 @ D.20823, D.20824 
    str r7, [r4] @ D.20824, MEM[(struct vector *)this_1(D)].D.18751._M_impl._M_start 
    str r5, [r4, #4] @ D.20823, MEM[(struct vector *)this_1(D)].D.18751._M_impl._M_finish 
    mov r0, r4 @, this 
    str r5, [r4, #8] @ D.20823, MEM[(struct vector *)this_1(D)].D.18751._M_impl._M_end_of_storage 
    pop {r3, r4, r5, r6, r7, pc} @ 
.L6: 
    ldr r0, [r4] @ D.20823, MEM[(struct _Vector_base *)this_1(D)]._M_impl._M_start 
    cbz r0, .L5 @ D.20823, 
    bl _ZdlPv @ 
.L5: 
    bl __cxa_end_cleanup @ 

Answer 1

これは、4.9.2のリリースではGCCのバグがあって、PR 64476を参照してください。デフォルトの-std=gnu++03モードと-std=c++14の違いは、C++ 11以降では、代入演算子を削除できるため、代入不可能な型を持つことが可能であるため、std::uninitialized_copyの実装では異なるより遅い）コードパス。割り当て可能性のチェックは間違っていました。これは、必要がないときに遅い経路を取ったことを意味します。

GCC 4.9.3では2年前に修正されましたが、あなたのコンパイラは4.9.2と4.9.3のリリース間で作成されたスナップショットに基づいており、数週間で修正できませんでした。

LinaroにGCC 4.9コンパイラを4.9.4にアップデートするか、少なくともこのバグを修正するパッチを適用するように要求することができます。