Re: Why Git is so fast

* "Shawn O. Pearce" <spearce@spearce.org> writes:
|>      4) The "static inline void hashcpy(....)" in cache.h could then
|>         maybe be written like this:
|
| Its already done as "memcpy(a, b, 20)" which most compilers will
| inline and probably reduce to 5 word moves anyway.  That's why
| hashcpy() itself is inline.

  But would the compiler be able to trust that the hashcpy() is always
  called with correct word alignment on variables a and b?

  I made a test and compiled git with:

    make USE_NSEC=1 CFLAGS="-march=core2 -mtune=core2 -O2 -g2 -fno-stack-protector" clean all

  compiler: gcc (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) 4.3.3
  CPU: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel

  Then used gdb to get the following:

(gdb) disassemble write_sha1_file Dump of assembler code for function write_sha1_file: 0x080e3830 <write_sha1_file+0>: push %ebp 0x080e3831 <write_sha1_file+1>: mov %esp,%ebp 0x080e3833 <write_sha1_file+3>: sub $0x58,%esp 0x080e3836 <write_sha1_file+6>: lea -0x10(%ebp),%eax 0x080e3839 <write_sha1_file+9>: mov %ebx,-0xc(%ebp) 0x080e383c <write_sha1_file+12>: mov %esi,-0x8(%ebp) 0x080e383f <write_sha1_file+15>: mov %edi,-0x4(%ebp) 0x080e3842 <write_sha1_file+18>: mov 0x14(%ebp),%ebx 0x080e3845 <write_sha1_file+21>: mov %eax,0x8(%esp) 0x080e3849 <write_sha1_file+25>: lea -0x44(%ebp),%edi 0x080e384c <write_sha1_file+28>: lea -0x24(%ebp),%esi 0x080e384f <write_sha1_file+31>: mov %edi,0x4(%esp) 0x080e3853 <write_sha1_file+35>: mov %esi,(%esp) 0x080e3856 <write_sha1_file+38>: mov 0x10(%ebp),%ecx 0x080e3859 <write_sha1_file+41>: mov 0xc(%ebp),%edx 0x080e385c <write_sha1_file+44>: mov 0x8(%ebp),%eax 0x080e385f <write_sha1_file+47>: call 0x80e0350 <write_sha1_file_prepare> 0x080e3864 <write_sha1_file+52>: test %ebx,%ebx 0x080e3866 <write_sha1_file+54>: je 0x80e3885 <write_sha1_file+85>

0x080e3868 <write_sha1_file+56>: mov -0x24(%ebp),%eax 0x080e386b <write_sha1_file+59>: mov %eax,(%ebx) 0x080e386d <write_sha1_file+61>: mov -0x20(%ebp),%eax 0x080e3870 <write_sha1_file+64>: mov %eax,0x4(%ebx) 0x080e3873 <write_sha1_file+67>: mov -0x1c(%ebp),%eax 0x080e3876 <write_sha1_file+70>: mov %eax,0x8(%ebx) 0x080e3879 <write_sha1_file+73>: mov -0x18(%ebp),%eax 0x080e387c <write_sha1_file+76>: mov %eax,0xc(%ebx) 0x080e387f <write_sha1_file+79>: mov -0x14(%ebp),%eax 0x080e3882 <write_sha1_file+82>: mov %eax,0x10(%ebx)

  I admit that I am not particular familar with intel machine
  instructions, but I guess that the above 10 mov instructions is the
  result for the compiled inline hashcpy() in the write_sha1_file()
  function in sha1_file.c

  Question: would it be possible for the compiler to compile it down to
  just 5 mov instructions if we had used unsigned 32 bits type?  Or is
  this the best we can reasonable hope for inside the write_sha1_file()
  function?

  I checked 3 other output of "disassemble function_foo", and it seems
  that those 3 functions I checked got 10 mov instructions for the
  inline hashcpy(), as far as I can tell.

0x080e3885 <write_sha1_file+85>: mov %esi,(%esp) 0x080e3888 <write_sha1_file+88>: call 0x80e3800 <has_sha1_file> 0x080e388d <write_sha1_file+93>: xor %edx,%edx 0x080e388f <write_sha1_file+95>: test %eax,%eax 0x080e3891 <write_sha1_file+97>: jne 0x80e38b6 <write_sha1_file+134> 0x080e3893 <write_sha1_file+99>: mov 0xc(%ebp),%eax 0x080e3896 <write_sha1_file+102>: mov %edi,%edx 0x080e3898 <write_sha1_file+104>: mov %eax,0x4(%esp) 0x080e389c <write_sha1_file+108>: mov -0x10(%ebp),%ecx 0x080e389f <write_sha1_file+111>: mov 0x8(%ebp),%eax 0x080e38a2 <write_sha1_file+114>: movl $0x0,0x8(%esp) 0x080e38aa <write_sha1_file+122>: mov %eax,(%esp) 0x080e38ad <write_sha1_file+125>: mov %esi,%eax 0x080e38af <write_sha1_file+127>: call 0x80e1e40 <write_loose_object> 0x080e38b4 <write_sha1_file+132>: mov %eax,%edx 0x080e38b6 <write_sha1_file+134>: mov %edx,%eax 0x080e38b8 <write_sha1_file+136>: mov -0xc(%ebp),%ebx 0x080e38bb <write_sha1_file+139>: mov -0x8(%ebp),%esi 0x080e38be <write_sha1_file+142>: mov -0x4(%ebp),%edi 0x080e38c1 <write_sha1_file+145>: leave 0x080e38c2 <write_sha1_file+146>: ret End of assembler dump. (gdb)

  So, maybe the compiler is doing the right thing after all?

  -- kjetil