I put 1.00 pre-release code in: http://www.hashcash.org/source/current/ this may have some effect on the approach you use to short-cut the code outside of SHA1_Transform, as the count has been separated from the random/collision avoidance field. Hopefully if anything it should make things faster as the counter is simpler (no random offset, just incrementing counter). Not sure if we want to fold in speed improvements into pre 1.0 or not. If people are going to continue using perhaps, but on the other hand better to move forwards. Note 1.00 code does not read version 0 stamps; that is something that will probably put in. Also note that on redhat I compile with -DOPENSSL which then uses openssl assembler optimized SHA1 rather than my C optimized SHA1. Hmm but I don't see any evidence of this left in hashcash-0.33.spec, perhaps that got taken out at some point by accident. (Several people contributed .spec file improvements to work on Mandrake, etc as well with one .spec). Adam On Thu, May 27, 2004 at 08:55:44AM +0100, Jonathan Morton wrote: > > Eliminating the huge overhead that this reveals would result in a 50% > > performance boost, even with no CPU-specific optimisations. (Probably > > less on x86, since the hashing function takes relatively longer there, > > but still significant.) > > Excuse me while I eat my own words. :) > > I just finished writing the first round of "libfastmint" routines, and > discovered that far from being only *slightly* improved, I've achieved > a *doubling* of performance on x86. I'm seeing a steady 2 million > hashes per second on my 1.6GHz Athlon-XP, which is a long way up from > last week.