git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Linus' sha1 is much faster!

From
Paolo Bonzini <bonzini@gnu.org>
Date
Aug 17, 2009, 17:20 UTC
Message-ID
<4A899152.8070607@gnu.org>
In-Reply-To
<alpine.LFD.2.00.0908171228570.6044@xanadu.home>
Show 19 quoted lines
> my first version of
> get_be32() was a macro that did this:
>
> #define SHA_SRC(t) \
>    ({ unsigned char *__d = (unsigned char *)&data[t]; \
>       (__d[0]<<  24) | (__d[1]<<  16) | (__d[2]<<  8) | (__d[3]<<  0); })
>
> With such a construct, gcc would always allocate a register to hold __d
> and then dereference that with an offset from 0 to 3.  Whereas:
>
> #define SHA_SRC(t) \
>     ({   unsigned char *__d = (unsigned char *)data; \
>          (__d[(t)*4 + 0]<<  24) | (__d[(t)*4 + 1]<<  16) | \
>          (__d[(t)*4 + 2]<<   8) | (__d[(t)*4 + 3]<<   0); })
>
> does produce optimal assembly as only the register holding the data
> pointer is dereferenced with the absolute byte offset.  I suspect your
> usage of inline functions has the same effect as the first SHA_SRC
> definition above.
Yes, that's what happens.
Paolo
Previous: Nicolas PitreNext: George Spelvin
Message 4 of 7 in “Re: Linus' sha1 is much faster!”
  1. George SpelvinAug 17, 2009
  2. Nicolas PitreAug 17, 2009
  3. Nicolas PitreAug 17, 2009
  4. Paolo BonziniAug 17, 2009
  5. George SpelvinAug 17, 2009
  6. Nicolas PitreAug 17, 2009
  7. George SpelvinAug 17, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.