Re: [PATCH 0/4] Add a compile-time option to use the new, very fast sha1dc Rust crate
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 29, 2026, 07:30 UTC
- Message-ID
- <xmqqa4p0jz0d.fsf@gitster.g>
- In-Reply-To
- <pull.2240.git.1790610691.gitgitgadget@gmail.com>
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 18 quoted lines
> I stumbled across this new Rust crate last week. Its performance numbers are > quite impressive. Naturally, I want to make use of this and get for Windows, > which is used on many monorepos where this makes a real difference: In a > pretty fast and loose test, I verified that a git index-pack runs roughly > three times faster solely due to using those SIMD-based optimizations! > > As a safety precaution, because this sha1dc crate is quite new, I wanted to > introduce an escape hatch: core.sha1dcBackend=c, but turn it on by default, > which is the reason for the three additional patches. Should these patches > be undesirable for the Git project? I would not be mad at all if they were > simply dropped. > > Johannes Schindelin (4): > libgitcore: add `sha1dc` as an optional feature > sha1dc: allow selecting the C backend without rebuilding > pthread: provide `pthread_once()` shims for Windows and for > NO_PTHREADS > sha1dc: make `sha1dc_init()` thread-safe
The feature sha1dc_choose() means that you can between Rust and C implementations of sha1dc pick at runtime and I was confused by the "compile-time" in the topic title, which is misleading. From the end-user's point of view, being able to choose between the two at runtime gives them a lot bigger value, even though from the point of view of the developer who added the feature to allow users to do so, that feature being a compile-time choice might matter more.
How close are these two implementations? Do they implement the same idea but the details may differ? Do they both faithfully implement what the same paper wrote and given the same fudged input they will always detect the attempted attack the same way?