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

RE: [PATCH] Put sha1dc on a diet

From
DSDan Shumow <danshu@microsoft.com>
Date
Mar 2, 2017, 01:31 UTC
Message-ID
<CY1PR0301MB21073D82F4A6AB0DAD8BF1FCC4280@CY1PR0301MB2107.namprd03.prod.outlook.com>
In-Reply-To
<CA+55aFz4ixVKVURki8FeXjL5H51A_cQXsZpzKJ-N9n574Yy1rg@mail.gmail.com>
I played around tweaking the code a bit more and I got our performance down to a 2.077182x slowdown with check and a 1.055961x slowdown without checking.  However, that slowdown is basically with the check turned off through our API.  If I rip extraneous code for storing states and checking if we are doing collision detection out, I can reach performance parity with the block-sha1 implementation in the Git codebase, which basically tells me that is about as good as I can do for optimizing the C code.
SHA1 is more amenable to assembler implementation because its use of rotations, which are notoriously difficult to access through C code.  And as this happens in the inner loop of the function, the inline asm tends to not cut it.  This is one of the reasons that the OpenSSL SHA-1 runs like a scalded monkey, compared to the C implemenations.  Marc and I have also discussed using SIMD operations to speed up the UBC checks, which could definitely help achieve better performance, but is highly dependent on processor support.  It will take some time to do either a SIMD implementation of the UBC checks or an assembler implementation.
At this point, I would suggest that I take the C optimizations, clean them up and fold them in with the diet changes Linus has suggested.  The slowdown is still 2x over block-sha1 and more over OpenSSL.  But it is better than nothing.  And then if there is interest Marc and I can investigate other processor specific optimizations like ASM or SIMD and circle back with those performance optimizations at a later date.
Also, to Johannes Schindelin's point:
> My concern is about that unexpected turn "oh, let's just switch to C99 because, well, because my compiler canehandle it, and everybody else should just switch tn a modern compiler". That really sounded careless.
While it will probably be a pain, if it is a requirement, we can modify the code to move away from any c99 specific stuff we have in here, if it makes adopting the code more palatable for Git.

Thanks, Dan

Previous: Linus TorvaldsNext: Junio C Hamano
Message 23 of 36 in “Put sha1dc on a diet”
  1. Put sha1dc on a dietLinus Torvalds, Mar 1, 2017
  2. Junio C HamanoMar 1, 2017
  3. Linus TorvaldsMar 1, 2017
  4. Jeff KingMar 1, 2017
  5. Junio C HamanoMar 1, 2017
  6. Johannes SchindelinMar 1, 2017
  7. Junio C HamanoMar 1, 2017
  8. Linus TorvaldsMar 1, 2017
  9. Johannes SchindelinMar 1, 2017
  10. Linus TorvaldsMar 1, 2017
  11. Jeff KingMar 1, 2017
  12. Duy NguyenMar 2, 2017
  13. Johannes SchindelinMar 2, 2017
  14. Linus TorvaldsMar 2, 2017
  15. Jeff HostetlerMar 2, 2017
  16. Linus TorvaldsMar 2, 2017
  17. Johannes SchindelinMar 2, 2017
  18. Johannes SchindelinMar 2, 2017
  19. Jeff KingMar 1, 2017
  20. Linus TorvaldsMar 1, 2017
  21. Jeff KingMar 1, 2017
  22. Linus TorvaldsMar 1, 2017
  23. Dan ShumowMar 2, 2017
  24. Junio C HamanoMar 2, 2017
  25. Dan ShumowMar 4, 2017
  26. Jeff KingMar 13, 2017
  27. Jeff KingMar 1, 2017
  28. Jeff KingMar 13, 2017
  29. Marc StevensMar 13, 2017
  30. Linus TorvaldsMar 13, 2017
  31. Marc StevensMar 13, 2017
  32. Jeff KingMar 13, 2017
  33. Marc StevensMar 13, 2017
  34. Marc StevensMar 16, 2017
  35. Jeff KingMar 16, 2017
  36. Dan ShumowMar 16, 2017

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.