Re: libfastmint update 20040915

> the patch seems to work well. i built and installed 1.08 with x86 and  
> have a 0% failure rate when minting stamps (attempting to mint a zero  
> bit stamp still hangs).

That's odd, I just tried minting zero bits on Linux and OSX, and they  
both worked fine.

chromi@hydrogen hashcash-1.08 $ ./hashcash -m -b0 foo bar baz  
[email protected] [email protected]
hashcash token: 1:0:040916:foo::32rZloGRpnk1AP/M:0000000000000000000
hashcash token: 1:0:040916:bar::aNjjdhdnZNZGgNCo:0000000000000000000
hashcash token: 1:0:040916:baz::AW6dZamEckwdgpaS:0000000000000000000
hashcash token:  
1:0:040916:[email protected]::D+WYjp0B4C/Y4q7u: 
00000000000000000000000000000000000000
hashcash token: 1:0:040916:[email protected]::JL0khE+9gOrRUqw3:000000000

Why anyone would legitimately want to do that is beyond me.  But since  
I can't reproduce the problem here, it's up to you to track it down.

> using the patched version (x86 build) my best minter is:
>
>   2299204 AMD64/x86 MMX Standard 1x2-pipe *
>     Solution:  1:22:040404:[email protected]::0123456789abcdef:000000Tu1n
>     Iterations: 7831665
>     Time taken: 3.406
>
> which, according to this benchmark, does a *SLIGHTLY* faster job of  
> going through more iterations(???), but the same build actually slowed  
> down all of the ANSI minters (perhaps because there are more  
> iterations?).

You're looking at the wrong numbers.  The "iteration rate", to the left  
of the core name, is the important number, and is calculated from both  
the iteration count and the time taken.  The stats at the end of the  
benchmark run, predicting minting times for different sized stamps, are  
all based on the iteration rate.

The benchmark test string was changed in the patch, to make it count in  
the optimal position (which is now also used in the actual minter  
function).  It happens to take longer to find the solution with the new  
string, but the iteration rates can still be validly compared, because  
both the time taken and the iteration count are taken into account.   
Note that the new version will generally have higher rates than  
previous versions, so Adam will probably want to refresh his collection  
of benchmark scores.

(Suggestion to Adam:  reduce verbosity of the benchmark to level 2 by  
default, which would avoid this confusion.  Perhaps -svv would produce  
the extra stats, which are more helpful for debugging than for normal  
use.)

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email protected]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.