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 > <[EMAIL PROTECTED]> 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@lists.ximian.com > > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > > > _______________________________________________ > > Mono-devel-list mailing list > > Mono-devel-list@lists.ximian.com > > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list > > > > > -- > http://igordevlog.blogspot.com > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/mono-devel-list _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list