[Mono-dev] SHA1Managed speedups
Sebastien Pouliot
sebastien.pouliot at gmail.com
Tue Apr 29 14:24:16 EDT 2008
Hello Igor,
On Tue, 2008-04-29 at 13:49 -0400, Igor Guerrero wrote:
> Hi Sebastien,
>
> Thanks for your help and suggestions... I read in the chats between
> Scott and Alan about the performance gain using their SHA1
> improvements, that it was about 40%, obviously my eyes shined after
> reading that.
I've not yet seen those numbers [1], nor know with what they compare
(1.9 or HEAD) [2] or on which architecture they were executed [3].
[1] The first numbers from Alan, on Sunday using unsafe code, were
around 40% and he made more progress after that.
[2] I'm not very enthusiastic about unsafe code and I committed (i.e.
it's already in HEAD) a small patch to helps ABC removal (fields versus
local). This gained (well reduced time by) 26% on a P4 (x86 JIT).
[3] The next day I tried the same code on a 64 bit box (x86_64 JIT) and
the time reduction was 32%.
So in any case the next version of Mono will be faster - and hopefully
even more than HEAD already is.
> @hector we were doing SHA1 all wrong :(
It's not a huge problem, many applications are built like this, but it
would limit future options and, thankfully, it's an easy fix :)
Sebastien
> On Tue, Apr 29, 2008 at 12:21 PM, Sebastien Pouliot
> <sebastien.pouliot at gmail.com> wrote:
> 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
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
> --
> http://igordevlog.blogspot.com
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
More information about the Mono-devel-list
mailing list