C ++ 'da ifade sırasını zorunlu kılma

Sabit bir sırayla yürütmek istediğim birkaç ifadem olduğunu varsayalım. Optimizasyon düzeyi 2 ile g ++ kullanmak istiyorum, böylece bazı ifadeler yeniden sıralanabilir. Belirli bir ifadeleri sıralamak için hangi araçlara ihtiyaç vardır?

Aşağıdaki örneği düşünün.

using Clock = std::chrono::high_resolution_clock;

auto t1 = Clock::now(); // Statement 1
foo();                  // Statement 2
auto t2 = Clock::now(); // Statement 3

auto elapsedTime = t2 - t1;

Bu örnekte 1-3 ifadelerinin verilen sırada yürütülmesi önemlidir. Ancak, derleyici düşünce ifadesi 2, 1 ve 3'ten bağımsız olup kodu aşağıdaki gibi çalıştıramaz mı?

using Clock=std::chrono::high_resolution_clock;

foo();                  // Statement 2
auto t1 = Clock::now(); // Statement 1
auto t2 = Clock::now(); // Statement 3

auto elapsedTime = t2 - t1;

C ++ standartlar komitesiyle tartışıldıktan sonra biraz daha kapsamlı bir cevap vermeye çalışmak istiyorum. C ++ komitesinin bir üyesi olmanın yanı sıra, LLVM ve Clang derleyicilerinde de geliştiriciyim.

Temel olarak, bu dönüşümleri gerçekleştirmek için dizide bir bariyer veya bazı işlemler kullanmanın bir yolu yoktur. Temel sorun, tamsayı toplaması gibi bir şeyin işlemsel anlamının uygulama tarafından tamamen bilinmesidir . Onları simüle edebilir, doğru programlarla gözlemlenemeyeceğini bilir ve her zaman onları hareket ettirmekte özgürdür.

Bunu önlemeye çalışabilirdik, ancak son derece olumsuz sonuçları olur ve sonunda başarısız olur.

İlk olarak, derleyicide bunu önlemenin tek yolu, ona tüm bu temel işlemlerin gözlemlenebilir olduğunu söylemektir. Sorun şu ki, bu daha sonra derleyici optimizasyonlarının ezici çoğunluğunu engelleyecektir. Derleyicinin içinde, esasen zamanlamanın gözlemlenebilir olduğunu ancak başka hiçbir şeyin olmadığını modellemek için iyi bir mekanizmamız yok. Hangi işlemlerin zaman aldığı konusunda iyi bir modelimiz bile yok . Örnek olarak, 32 bitlik işaretsiz bir tamsayıyı 64 bitlik işaretsiz bir tam sayıya dönüştürmek zaman alır mı? X86-64'te sıfır zaman alır, ancak diğer mimarilerde sıfır olmayan süre alır. Burada genel olarak doğru bir cevap yok.

Ancak derleyicinin bu işlemleri yeniden düzenlemesini engellemede bazı kahramanlıklarla başarılı olsak bile, bunun yeterli olacağının garantisi yoktur. C ++ programınızı bir x86 makinesinde çalıştırmanın geçerli ve uyumlu bir yolunu düşünün: DynamoRIO. Programın makine kodunu dinamik olarak değerlendiren bir sistemdir. Yapabileceği bir şey, çevrimiçi optimizasyondur ve hatta zamanlamanın dışında tüm temel aritmetik komutları spekülatif olarak çalıştırabilir. Ve bu davranış, dinamik değerlendiricilere özgü değildir, gerçek x86 CPU da (çok daha az sayıda) talimatları speküle edecek ve bunları dinamik olarak yeniden sıralayacaktır.

Temel fark, aritmetiğin gözlemlenebilir olmadığı gerçeğidir (zamanlama düzeyinde bile), bilgisayarın katmanlarına nüfuz eden bir şeydir. Derleyici, çalışma zamanı ve çoğu zaman donanım için doğrudur. Gözlenebilir olmaya zorlamak, hem derleyiciyi önemli ölçüde kısıtlar, hem de donanımı önemli ölçüde kısıtlar.

Ancak tüm bunlar umudunuzu kaybetmenize neden olmamalıdır. Temel matematiksel işlemlerin yürütülmesini zamanlamak istediğinizde, güvenilir bir şekilde çalışan teknikleri iyi inceledik. Genellikle bunlar mikro kıyaslama yapılırken kullanılır . Bunun hakkında CppCon2015'te bir konuşma yaptım: https://youtu.be/nXaxk27zwlk

Orada gösterilen teknikler, Google'ın aşağıdaki gibi çeşitli mikro karşılaştırma kitaplıkları tarafından da sağlanmaktadır: https://github.com/google/benchmark#preventing-optimization

Bu tekniklerin anahtarı verilere odaklanmaktır. Hesaplamanın girdisini optimize edici için opak ve hesaplamanın sonucunu optimize edici için opak yaparsınız. Bunu yaptıktan sonra, güvenilir bir şekilde zamanlayabilirsiniz. Orijinal sorudaki örneğin gerçekçi bir versiyonuna bakalım, ancak foouygulama tarafından tamamen görülebilir tanımıyla . Ayrıca DoNotOptimize, burada bulabileceğiniz Google Benchmark kitaplığından (taşınabilir olmayan) bir sürümünü de çıkardım : https://github.com/google/benchmark/blob/master/include/benchmark/benchmark_api.h#L208

#include <chrono>

template <class T>
__attribute__((always_inline)) inline void DoNotOptimize(const T &value) {
  asm volatile("" : "+m"(const_cast<T &>(value)));
}

// The compiler has full knowledge of the implementation.
static int foo(int x) { return x * 2; }

auto time_foo() {
  using Clock = std::chrono::high_resolution_clock;

  auto input = 42;

  auto t1 = Clock::now();         // Statement 1
  DoNotOptimize(input);
  auto output = foo(input);       // Statement 2
  DoNotOptimize(output);
  auto t2 = Clock::now();         // Statement 3

  return t2 - t1;
}

Burada, girdi verilerinin ve çıktı verilerinin hesaplama etrafında optimize edilemez olarak işaretlenmesini foove yalnızca bu işaretçilerin etrafında hesaplanan zamanlamaların olmasını sağlıyoruz. Hesaplamayı kısaltmak için verileri kullandığınızdan, iki zamanlama arasında kalmanız garanti edilir ve yine de hesaplamanın kendisinin optimize edilmesine izin verilir. Yeni bir Clang / LLVM derlemesi tarafından oluşturulan sonuçta elde edilen x86-64 derlemesi şudur:

% ./bin/clang++ -std=c++14 -c -S -o - so.cpp -O3
        .text
        .file   "so.cpp"
        .globl  _Z8time_foov
        .p2align        4, 0x90
        .type   _Z8time_foov,@function
_Z8time_foov:                           # @_Z8time_foov
        .cfi_startproc
# BB#0:                                 # %entry
        pushq   %rbx
.Ltmp0:
        .cfi_def_cfa_offset 16
        subq    $16, %rsp
.Ltmp1:
        .cfi_def_cfa_offset 32
.Ltmp2:
        .cfi_offset %rbx, -16
        movl    $42, 8(%rsp)
        callq   _ZNSt6chrono3_V212system_clock3nowEv
        movq    %rax, %rbx
        #APP
        #NO_APP
        movl    8(%rsp), %eax
        addl    %eax, %eax              # This is "foo"!
        movl    %eax, 12(%rsp)
        #APP
        #NO_APP
        callq   _ZNSt6chrono3_V212system_clock3nowEv
        subq    %rbx, %rax
        addq    $16, %rsp
        popq    %rbx
        retq
.Lfunc_end0:
        .size   _Z8time_foov, .Lfunc_end0-_Z8time_foov
        .cfi_endproc


        .ident  "clang version 3.9.0 (trunk 273389) (llvm/trunk 273380)"
        .section        ".note.GNU-stack","",@progbits

Burada, derleyicinin çağrıyı foo(input)tek bir talimata kadar optimize ettiğini addl %eax, %eax, ancak onu zamanlamanın dışına çıkarmadan veya sabit girdiye rağmen tamamen ortadan kaldırmadan görebilirsiniz.

Umarım bu yardımcı olur ve C ++ standartları komitesi, API'leri DoNotOptimizeburaya benzer standartlaştırma olasılığını araştırıyor .

Özet:

Yeniden sıralamayı engellemenin garantili bir yolu yok gibi görünüyor, ancak bağlantı zamanı / tam program optimizasyonu etkinleştirilmediği sürece , çağrılan işlevi ayrı bir derleme biriminde bulmak oldukça iyi bir bahis gibi görünüyor . (En azından GCC ile, mantık bunun diğer derleyiciler için de olası olduğunu öne sürse de.) Bu, işlev çağrısı maliyetiyle gelir - satır içi kod, tanımı gereği aynı derleme birimindedir ve yeniden sıralanmaya açıktır.

Orijinal cevap:

GCC, çağrıları -O2 optimizasyonu altında yeniden sıralar:

#include <chrono>
static int foo(int x)    // 'static' or not here doesn't affect ordering.
{
    return x*2;
}
int fred(int x)
{
    auto t1 = std::chrono::high_resolution_clock::now();
    int y = foo(x);
    auto t2 = std::chrono::high_resolution_clock::now();
    return y;
}

GCC 5.3.0:

g++ -S --std=c++11 -O0 fred.cpp :

_ZL3fooi:
        pushq   %rbp
        movq    %rsp, %rbp
        movl    %ecx, 16(%rbp)
        movl    16(%rbp), %eax
        addl    %eax, %eax
        popq    %rbp
        ret
_Z4fredi:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $64, %rsp
        movl    %ecx, 16(%rbp)
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movq    %rax, -16(%rbp)
        movl    16(%rbp), %ecx
        call    _ZL3fooi
        movl    %eax, -4(%rbp)
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movq    %rax, -32(%rbp)
        movl    -4(%rbp), %eax
        addq    $64, %rsp
        popq    %rbp
        ret

Fakat:

g++ -S --std=c++11 -O2 fred.cpp :

_Z4fredi:
        pushq   %rbx
        subq    $32, %rsp
        movl    %ecx, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        call    _ZNSt6chrono3_V212system_clock3nowEv
        leal    (%rbx,%rbx), %eax
        addq    $32, %rsp
        popq    %rbx
        ret

Şimdi, harici işlev olarak foo () ile:

#include <chrono>
int foo(int x);
int fred(int x)
{
    auto t1 = std::chrono::high_resolution_clock::now();
    int y = foo(x);
    auto t2 = std::chrono::high_resolution_clock::now();
    return y;
}

g++ -S --std=c++11 -O2 fred.cpp :

_Z4fredi:
        pushq   %rbx
        subq    $32, %rsp
        movl    %ecx, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movl    %ebx, %ecx
        call    _Z3fooi
        movl    %eax, %ebx
        call    _ZNSt6chrono3_V212system_clock3nowEv
        movl    %ebx, %eax
        addq    $32, %rsp
        popq    %rbx
        ret

AMA, eğer bu -flto ile bağlantılıysa (bağlantı zamanı optimizasyonu):

0000000100401710 <main>:
   100401710:   53                      push   %rbx
   100401711:   48 83 ec 20             sub    $0x20,%rsp
   100401715:   89 cb                   mov    %ecx,%ebx
   100401717:   e8 e4 ff ff ff          callq  100401700 <__main>
   10040171c:   e8 bf f9 ff ff          callq  1004010e0 <_ZNSt6chrono3_V212system_clock3nowEv>
   100401721:   e8 ba f9 ff ff          callq  1004010e0 <_ZNSt6chrono3_V212system_clock3nowEv>
   100401726:   8d 04 1b                lea    (%rbx,%rbx,1),%eax
   100401729:   48 83 c4 20             add    $0x20,%rsp
   10040172d:   5b                      pop    %rbx
   10040172e:   c3                      retq

Yeniden sıralama, derleyici veya işlemci tarafından yapılabilir.

Çoğu derleyici, okuma-yazma talimatlarının yeniden sıralanmasını önlemek için platforma özgü bir yöntem sunar. Gcc'de bu

asm volatile("" ::: "memory");

( Daha fazla bilgi burada )

Bunun, okuma / yazma işlemlerine bağlı oldukları sürece yalnızca dolaylı olarak yeniden sıralama işlemlerini engellediğini unutmayın.

Uygulamada , sistem çağrısının Clock::now()böyle bir engelle aynı etkiye sahip olduğu bir sistem henüz görmedim . Emin olmak için ortaya çıkan montajı inceleyebilirsiniz.

Bununla birlikte, test edilen işlevin derleme sırasında değerlendirilmesi nadir değildir. "Gerçekçi" yürütmeyi sağlamak için foo(), giriş / çıkıştan veya bir volatileokumadan girdi türetmeniz gerekebilir .

Başka bir seçenek de satır içi yazmayı devre dışı bırakmak olabilir foo()- yine, bu derleyiciye özeldir ve genellikle taşınabilir değildir, ancak aynı etkiye sahip olacaktır.

Gcc'de bu, __attribute__ ((noinline))

@Ruslan temel bir konuyu gündeme getiriyor: Bu ölçüm ne kadar gerçekçi?

Yürütme süresi birçok faktörden etkilenir: Biri üzerinde çalıştığımız gerçek donanım, diğeri ise önbellek, bellek, disk ve CPU çekirdekleri gibi paylaşılan kaynaklara eşzamanlı erişimdir.

Dolayısıyla, karşılaştırılabilir zamanlamalar elde etmek için genellikle yaptığımız şey : düşük bir hata payı ile tekrarlanabilir olduklarından emin olun . Bu onları biraz yapay kılar.

"sıcak önbellek" ve "soğuk önbellek" yürütme performansı, büyüklük sırasına göre kolayca farklılık gösterebilir - ancak gerçekte, aralarında bir şey olacaktır ("ılık"?)

C ++ dili, çeşitli şekillerde neyin gözlemlenebilir olduğunu tanımlar.

Eğer foo()hiçbir şey gözlemlenebilir yapar, o zaman tamamen ortadan kaldırılabilir. Eğer foo()"yerel" halde saklar değerleri (yığın halinde veya bir amacı, bir yerlerde olması) bir hesaplama yapar, ancak ve derleyici bir güvenli bir şekilde türetilmiş işaretçi almak kanıtlamak için Clock::now()kod, daha sonra hiçbir gözlenebilir sonuçları için orada Clock::now()aramaları taşımak .

Eğer foo()bir dosya veya ekran ve derleyici ile etkileşim olduğunu ispat edemez Clock::now()does not ardından bir dosya veya ekran etkileşim gözlemlenebilir davranış olduğu için, yapılamaz yeniden sıralama, dosya veya ekran etkileşim.

Kodu hareket etmemeye zorlamak için derleyiciye özgü korsanları kullanabilirsiniz (satır içi montaj gibi), başka bir yaklaşım da derleyicinizi zekice alt etmeye çalışmaktır.

Dinamik olarak yüklenmiş bir kitaplık oluşturun. Söz konusu koddan önce yükleyin.

Bu kütüphane bir şeyi açığa çıkarır:

namespace details {
  void execute( void(*)(void*), void *);
}

ve şu şekilde sarar:

template<class F>
void execute( F f ) {
  struct bundle_t {
    F f;
  } bundle = {std::forward<F>(f)};

  auto tmp_f = [](void* ptr)->void {
    auto* pb = static_cast<bundle_t*>(ptr);
    (pb->f)();
  };
  details::execute( tmp_f, &bundle );
}

Bu, boş bir lambda paketler ve dinamik kütüphaneyi derleyicinin anlayamayacağı bir bağlamda çalıştırmak için kullanır.

Dinamik kitaplığın içinde şunları yapıyoruz:

void details::execute( void(*f)(void*), void *p) {
  f(p);
}

ki bu oldukça basit.

Şimdi çağrıları yeniden sıralamak için execute, test kodunuzu derlerken anlayamayacağı dinamik kitaplığı anlamalıdır.

Yine de foo()sıfır yan etkiyle leri ortadan kaldırabilir , ancak biraz kazanırsınız, bazılarını kaybedersiniz.

Hayır yapamaz. C ++ standardına göre [intro.execution]:

14 Bir tam ifade ile ilişkili her değer hesaplaması ve yan etki, değerlendirilecek bir sonraki tam ifade ile ilişkili her değer hesaplamasından ve yan etkiden önce sıralanır.

Tam ifade, temelde noktalı virgülle sonlandırılan bir ifadedir. Gördüğünüz gibi yukarıdaki kural, ifadelerin sırayla yürütülmesi gerektiğini şart koşmaktadır. Öyle içindeki derleyici daha başıboş izin verildiğini ifadeleri (yani o dışındaki siparişlerde bir açıklama oluşturan ifadeleri değerlendirmek için izin bazı koşulda olduğu soldan sağa veya başka bir şey spesifik).

Varsa kuralının uygulanacağı koşulların burada karşılanmadığına dikkat edin. Herhangi bir derleyicinin , sistem saatini almak için çağrıları yeniden sıralamanın gözlemlenebilir program davranışını etkilemeyeceğini kanıtlayabileceğini düşünmek mantıksızdır . Zamanı almak için iki çağrının, gözlemlenen davranışı değiştirmeden yeniden düzenlenebileceği bir durum olsaydı, bunu kesin bir şekilde çıkarabilmek için yeterli anlayışa sahip bir programı analiz eden bir derleyici üretmek son derece verimsiz olurdu.

Hayır.

Bazen "sanki" kuralı gereği ifadeler yeniden sıralanabilir. Bunun nedeni, mantıksal olarak birbirlerinden bağımsız olmaları değil, bu bağımsızlığın, programın anlamını değiştirmeden böyle bir yeniden sıralamanın gerçekleşmesine izin vermesidir.

Şimdiki zamanı alan bir sistem çağrısının taşınması, bu koşulu açıkça karşılamaz. Bilerek veya bilmeyerek bunu yapan bir derleyici uyumsuzdur ve gerçekten saçmadır.

Genel olarak, bir sistem çağrısı ile sonuçlanan herhangi bir ifadenin agresif bir şekilde optimize eden bir derleyici tarafından bile "ikinci tahmin" yapılmasını beklemem. Sistem çağrısının ne yaptığını yeterince bilmiyor.

noinline işlev + satır içi montaj kara kutusu + tam veri bağımlılıkları

Bu, https://stackoverflow.com/a/38025837/895245'e dayanmaktadır, ancak neden ::now()orada yeniden sıralanamayacağına dair net bir gerekçe görmediğim için paranoyak olmayı ve onu bir noinline işlevinin içine koymayı asm.

Bu şekilde , veri bağımlılığını noinline"bağladığından" yeniden sıralama yapılamayacağından oldukça eminim ::now.

main.cpp

#include <chrono>
#include <iostream>
#include <string>

// noinline ensures that the ::now() cannot be split from the __asm__
template <class T>
__attribute__((noinline)) auto get_clock(T& value) {
    // Make the compiler think we actually use / modify the value.
    // It can't "see" what is going on inside the assembly string.
    __asm__ __volatile__ ("" : "+g" (value));
    return std::chrono::high_resolution_clock::now();
}

template <class T>
static T foo(T niters) {
    T result = 42;
    for (T i = 0; i < niters; ++i) {
        result = (result * result) - (3 * result) + 1;
    }
    return result;
}

int main(int argc, char **argv) {
    unsigned long long input;
    if (argc > 1) {
        input = std::stoull(argv[1], NULL, 0);
    } else {
        input = 1;
    }

    // Must come before because it could modify input
    // which is passed as a reference.
    auto t1 = get_clock(input);
    auto output = foo(input);
    // Must come after as it could use the output.
    auto t2 = get_clock(output);
    std::cout << "output " << output << std::endl;
    std::cout << "time (ns) "
              << std::chrono::duration_cast<std::chrono::nanoseconds>(t2 - t1).count()
              << std::endl;
}

GitHub yukarı akış .

Derleyin ve çalıştırın:

g++ -ggdb3 -O3 -std=c++14 -Wall -Wextra -pedantic -o main.out main.cpp
./main.out 1000
./main.out 10000
./main.out 100000

Bu yöntemin tek küçük dezavantajı, callqbir inlineyönteme fazladan bir talimat eklememizdir . şunları içeren objdump -CDgösterir main:

    11b5:       e8 26 03 00 00          callq  14e0 <auto get_clock<unsigned long long>(unsigned long long&)>
    11ba:       48 8b 34 24             mov    (%rsp),%rsi
    11be:       48 89 c5                mov    %rax,%rbp
    11c1:       b8 2a 00 00 00          mov    $0x2a,%eax
    11c6:       48 85 f6                test   %rsi,%rsi
    11c9:       74 1a                   je     11e5 <main+0x65>
    11cb:       31 d2                   xor    %edx,%edx
    11cd:       0f 1f 00                nopl   (%rax)
    11d0:       48 8d 48 fd             lea    -0x3(%rax),%rcx
    11d4:       48 83 c2 01             add    $0x1,%rdx
    11d8:       48 0f af c1             imul   %rcx,%rax
    11dc:       48 83 c0 01             add    $0x1,%rax
    11e0:       48 39 d6                cmp    %rdx,%rsi
    11e3:       75 eb                   jne    11d0 <main+0x50>
    11e5:       48 89 df                mov    %rbx,%rdi
    11e8:       48 89 44 24 08          mov    %rax,0x8(%rsp)
    11ed:       e8 ee 02 00 00          callq  14e0 <auto get_clock<unsigned long long>(unsigned long long&)>

bu yüzden bunun foosatır içi olduğunu, ancak get_clockolmadığını ve çevrelediğini görüyoruz .

get_clock Ancak kendisi, yığına bile dokunmayan tek bir yaprak çağrısı optimize edilmiş talimattan oluşan son derece verimlidir:

00000000000014e0 <auto get_clock<unsigned long long>(unsigned long long&)>:
    14e0:       e9 5b fb ff ff          jmpq   1040 <std::chrono::_V2::system_clock::now()@plt>

Saat hassasiyetinin kendisi sınırlı olduğundan, bir fazladanın zamanlama etkilerini fark etme olasılığınızın düşük olduğunu düşünüyorum jmpq. Paylaşılan bir kitaplıkta callolduğundan bağımsız olarak birinin gerekli olduğuna dikkat edin ::now().

::now()Veri bağımlılığı ile satır içi derlemeden çağrı

Bu, jmpqyukarıda bahsedilen fazlalıkların bile üstesinden gelerek, mümkün olan en verimli çözüm olacaktır .

Bu maalesef aşağıdaki adreste gösterildiği gibi doğru şekilde yapmak son derece zordur: Genişletilmiş satır içi ASM'de printf çağrısı

Ancak, zaman ölçümünüz bir çağrı olmaksızın doğrudan hat içi montajda yapılabiliyorsa, bu teknik kullanılabilir. Bu durum, örneğin gem5 sihirli enstrümantasyon talimatları , x86 RDTSC (artık bunun temsilci olup olmadığından emin değil) ve muhtemelen diğer performans sayaçları için geçerlidir.

İlgili konular:

• C ++ optimizer'ın çağrıları clock () olarak yeniden sıralaması yasal mı?

GCC 8.3.0, Ubuntu 19.04 ile test edilmiştir.