Question

在对我的旧异常类层次结构进行一些升级以利用一些C ++ 11功能时，我做了一些速度测试并且遇到了令人沮丧的结果。所有这些都是通过x64bit MSVC ++ 2010编译器，最高速度优化/ O2完成的。

两个非常简单的struct，两个按位复制语义。一个没有移动赋值运算符（为什么你需要一个？），另一个 - 用。两个简单的内联函数，按值返回新创建的这些struct的实例，这些实例将分配给局部变量。另外，请注意try/catch阻止。这是代码：

#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块，则两次都相同。但是在它存在的情况下，编译器明确地使用冗余移动运算符= struct更好地优化代码。此外，MakeFoo时间取决于TFoo及其布局的大小，但一般来说，时间比MakeBar的时间差几个，而时间不依赖于小尺寸的变化。

问题：

是否是MSVC ++ 2010的编译器特定功能（有人可以检查GCC吗？）？
是因为编译器必须在调用完成之前保留临时值，在MakeFoo的情况下它不能“撕开它”，并且在MakeBar的情况下它知道我们允许它使用移动语义并将其“分开”，生成更快的代码？
我可以期待没有try\catch阻止的类似事情的相同行为，但是在更复杂的情况下？

Answer 1

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

我重试了相同的测试，但运行了100倍的迭代次数，结果如下（测试的几次运行结果相似）：

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

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

异常，移动语义和优化：在编译器的怜悯（MSVC2010）？

1 个答案: