c++ - 异常、 move 语义和优化 : at compiler's mercy (MSVC2010)?

Question

在对我的旧异常类层次结构进行一些升级以利用某些 C++11 功能时，我进行了一些速度测试并发现了一些令人沮丧的结果。所有这些都是使用 x64 位 MSVC++2010 编译器完成的，最大速度优化/O2。

两个非常简单的struct，都是按位复制语义。一个没有 move 赋值运算符(你为什么需要一个？)，另一个 - 有。两个简单的内联函数按值返回这些 struct 的新创建实例，这些实例被分配给局部变量。另外，请注意周围的 try/catch block 。这是代码:

#include <iostream>
#include <windows.h>

struct TFoo
{
  unsigned long long int m0;
  unsigned long long int m1;

  TFoo( unsigned long long int f ) : m0( f ), m1( f / 2 ) {}
};

struct TBar
{
  unsigned long long int m0;
  unsigned long long int m1;

  TBar( unsigned long long int f ) : m0( f ), m1( f / 2 ) {}
  TBar & operator=( TBar && f )
  {
   m0 = f.m0;
   m1 = f.m1;
   f.m0 = f.m1 = 0;

   return ( *this );
  }
};

TFoo MakeFoo( unsigned long long int f )
{
 return ( TFoo( f ) );
}

TBar MakeBar( unsigned long long int f )
{
 return ( TBar( f ) );
}

int main( void )
{
 try
 {
  unsigned long long int lMin = 0;
  unsigned long long int lMax = 20000000;
  LARGE_INTEGER lStart = { 0 };
  LARGE_INTEGER lEnd = { 0 };
  TFoo lFoo( 0 );
  TBar lBar( 0 );

  ::QueryPerformanceCounter( &lStart );
  for( auto i = lMin; i < lMax; i++ )
  {
   lFoo = MakeFoo( i );
  }
  ::QueryPerformanceCounter( &lEnd );
  std::cout << "lFoo = ( " << lFoo.m0 << " , " << lFoo.m1 << " )\t\tMakeFoo count : " << lEnd.QuadPart - lStart.QuadPart << std::endl;

  ::QueryPerformanceCounter( &lStart );
  for( auto i = lMin; i < lMax; i++ )
  {
   lBar = MakeBar( i );
  }
  ::QueryPerformanceCounter( &lEnd );
  std::cout << "lBar = ( " << lBar.m0 << " , " << lBar.m1 << " )\t\tMakeBar count : " << lEnd.QuadPart - lStart.QuadPart << std::endl;
 }
 catch( ... ){}

 return ( 0 );
}

程序输出:

lFoo = ( 19999999 , 9999999 )       MakeFoo count : 428652
lBar = ( 19999999 , 9999999 )       MakeBar count : 74518

两个循环的汇编程序(显示周围的计数器调用):

//- MakeFoo loop START --------------------------------
00000001`3f4388aa 488d4810        lea     rcx,[rax+10h]
00000001`3f4388ae ff1594db0400    call    qword ptr [Prototype_Console!_imp_QueryPerformanceCounter (00000001`3f486448)]

00000001`3f4388b4 448bdf          mov     r11d,edi
00000001`3f4388b7 48897c2428      mov     qword ptr [rsp+28h],rdi
00000001`3f4388bc 0f1f4000        nop     dword ptr [rax]
00000001`3f4388c0 4981fb002d3101  cmp     r11,1312D00h
00000001`3f4388c7 732a            jae     Prototype_Console!main+0x83 (00000001`3f4388f3)
00000001`3f4388c9 4c895c2450      mov     qword ptr [rsp+50h],r11
00000001`3f4388ce 498bc3          mov     rax,r11
00000001`3f4388d1 48d1e8          shr     rax,1
00000001`3f4388d4 4889442458      mov     qword ptr [rsp+58h],rax       // these 3 lines
00000001`3f4388d9 0f28442450      movaps  xmm0,xmmword ptr [rsp+50h]    // are of interest 
00000001`3f4388de 660f7f442430    movdqa  xmmword ptr [rsp+30h],xmm0    // see MakeBar
00000001`3f4388e4 49ffc3          inc     r11
00000001`3f4388e7 4c895c2428      mov     qword ptr [rsp+28h],r11        
00000001`3f4388ec 4c8b6c2438      mov     r13,qword ptr [rsp+38h]       // this one too
00000001`3f4388f1 ebcd            jmp     Prototype_Console!main+0x50 (00000001`3f4388c0)

00000001`3f4388f3 488d8c24c0000000 lea     rcx,[rsp+0C0h]
00000001`3f4388fb ff1547db0400    call    qword ptr [Prototype_Console!_imp_QueryPerformanceCounter (00000001`3f486448)]
//- MakeFoo loop END --------------------------------

//- MakeBar loop START --------------------------------
00000001`3f4389d1 488d8c24c8000000 lea     rcx,[rsp+0C8h]
00000001`3f4389d9 ff1569da0400    call    qword ptr [Prototype_Console!_imp_QueryPerformanceCounter (00000001`3f486448)]

00000001`3f4389df 4c8bdf          mov     r11,rdi
00000001`3f4389e2 48897c2440      mov     qword ptr [rsp+40h],rdi
00000001`3f4389e7 4981fb002d3101  cmp     r11,1312D00h
00000001`3f4389ee 7322            jae     Prototype_Console!main+0x1a2 (00000001`3f438a12)
00000001`3f4389f0 4c895c2478      mov     qword ptr [rsp+78h],r11
00000001`3f4389f5 498bf3          mov     rsi,r11
00000001`3f4389f8 48d1ee          shr     rsi,1
00000001`3f4389fb 4d8be3          mov     r12,r11                     // these 3 lines
00000001`3f4389fe 4c895c2468      mov     qword ptr [rsp+68h],r11     // are of interest
00000001`3f438a03 48897c2478      mov     qword ptr [rsp+78h],rdi     // see MakeFoo
00000001`3f438a08 49ffc3          inc     r11
00000001`3f438a0b 4c895c2440      mov     qword ptr [rsp+40h],r11
00000001`3f438a10 ebd5            jmp     Prototype_Console!main+0x177 (00000001`3f4389e7)

00000001`3f438a12 488d8c24c0000000 lea     rcx,[rsp+0C0h]
00000001`3f438a1a ff1528da0400    call    qword ptr [Prototype_Console!_imp_QueryPerformanceCounter (00000001`3f486448)]
//- MakeBar loop END --------------------------------

如果我删除 try/catch block ，两次都是相同的。但是在它存在的情况下，编译器显然可以使用冗余 move 运算符 = 更好地优化 struct 的代码。此外，MakeFoo 时间确实取决于 TFoo 的大小及其布局，但一般来说，时间比 MakeBar 差几倍时间不取决于小的尺寸变化。

问题:

1. 它是 MSVC++2010 的编译器特定功能吗(有人可以检查 GCC 吗？)

2. 是否因为编译器必须在调用完成之前保留临时文件，它不能在 MakeFoo 和 MakeBar 的情况下“撕开它”它知道我们允许它使用 move 语义并且它“撕开它”以生成更快的代码？

3. 如果没有 try\catch block ，但在更复杂的情况下，我能否期望类似的事情有相同的行为？

Answer 1

您的测试有缺陷。当使用 /O2/EHsc 编译时，它会在几分之一秒内运行完成，并且测试结果存在很大差异。

我重试了相同的测试，但运行了 100 倍的迭代次数，结果如下(多次运行的测试结果相似):

lFoo = ( 1999999999 , 999999999 )               MakeFoo count : 16584927
lBar = ( 1999999999 , 999999999 )               MakeBar count : 16613002

您的测试未显示两种类型的分配性能之间存在任何差异。