Re: Don't trust your optimizer :-)

On Nov 9, 8:52 pm, "Martin B." <0xCDCDC...@gmx.at> wrote:


That was... Informative :-(.

Being in C++, I typically use a class, whose ctor takes the start,
and dtor traces out the timing. I wonder now, does this help? To be
honest, I see no reason why it would, compiler could be (or get)
smart enough to slap constructor and destructor call together.

But... Using the function you gave here and this code on VS 2008
Pro:

extern double foo (int iterations); // in another file
int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
  clock_t start=clock();
  foo(10000);
  printf("%d\n", clock()-start);
  return 0;
}

The above gives:

int _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
00B61000 push esi
  clock_t start=clock();
00B61001 mov esi,dword ptr [__imp__clock (0B6209Ch)]
00B61007 push edi
00B61008 call esi
00B6100A mov edi,eax
  foo(10000);
  printf("%d\n", clock()-start);
00B6100C call esi
00B6100E sub eax,edi
00B61010 push eax
00B61011 push 0B62198h
00B61016 call dword ptr [__imp__printf (0B62098h)]
00B6101C add esp,8
00B6101F pop edi
  return 0;
00B61020 xor eax,eax
00B61022 pop esi
}
00B61023 ret

I reckon, two call esi are calls to clock(), there's a call to
printf etc., but the important thing is: ___there's no call to foo
at all___ (I checked the assembly output, too). And in fact, in the
assembly output in VC thread, there's no call to foo either (and
calls to clock() can't be reordered at all, since there's nothing to
reorder :-).