[Mono-dev] SHA1Managed speedups

[Sebastien Pouliot]

Hello Hector,

On Tue, 2008-04-29 at 10:42 -0500, Hector E. Gomez Morales wrote:
> Hi all:
> 
> I am working in the implementation of Git# with Igor Guerrero so we will 
> be intensive users of SHA1Managed 

Well you should no be - at least not with so many details ;-)

The right way to access cryptography in .NET is to use the Create()
(factory) methods from the base class that represent the algorithm, not
the implementation.

        I.e. you should not be using SHA1Managed (or
        SHA1CryptoServiceProvider) but SHA1.Create()

This allows the Mono (or .NET) runtime to select the right (default or
user selected) implementation for any algorithms. 

        E.g. it would let someone change the default SHA1 to a native
        (or hardware assisted) implementation without modifying any
        application.

Historical note: it also served (MS) as a workaround for a bug in
SHA1CryptoServiceProvider (fx1.x) on multithreaded servers. They simply
(for WSE 1.0) updated machine.config to use SHA1Managed instead. That
fixed the problem for every application who followed the design
correctly.

> so we will like to help in anyway to help improve sha1 performance.

Thanks! 

Ping/email me when you get ready to profile your code. We'll see how
much impact SHA1 has and, if required, check a few options from there
(but be sure to use SHA1.Create ;-)

Sebastien

p.s. yes it's been on my Gendarme todo list for quite some time :)

> Hector
> 
> 
> Sebastien Pouliot wrote:
> > Great! :-)
> > 
> > Sebastien
> > 
> > p.s. there are quite a few other options possible (I mentioned Crimson
> > before) within or outside Mono if you still need/want more performance
> > out of SHA1.
> > 
> > On Tue, 2008-04-29 at 14:36 +0100, Alan McGovern wrote:
> >>>  Please remove the unsafe keyword from both methods.
> >> Ah, sorry. I attached the wrong patch. Kangaroo had already pointed
> >> out that i had left in the unsafe keyword as part of my copy/paste
> >> from my working copy and i thought i recreated the patch when i fixed
> >> that, but obviously not.
> >>
> >>>  Please always provide numbers (and the test cases) with performance
> >>>  patches. Also compare the results with the code already in SVN (not the
> >>>  previous releases) this way we compare the patch with the gain it
> >>>  provides.
> >> The 'Big Win' in this patch is unrolling the first loop. I'll attach
> >> some numbers later giving exact details as to where the gains are as
> >> compared to SVN head.
> >>
> >>>  He asked me, more than once, to consider re-rolling the
> >>>  SHA1 code. This piece of code is often the largest one the JIT is likely
> >>>  to compile, as since it's used for assembly names it's a performance
> >>>  (JIT time) hit being transfered to most Mono applications.
> >> If the JIT cost is prohibitive to making this patch acceptable, i can
> >> test partial unrolling of all the loops. I should be able to cut the
> >> codesize by a large proportion while still getting the majority of the
> >> speed beneffits. I'll testbench that later too.
> >>
> >> Thanks,
> >> Alan.
> > 
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list