[hashcash] Re: libfastmint update 20040915
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Thu, 16 Sep 2004 07:46:39 +0100
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
chromi@xxxxxxxxxxxxxxxxxxxxx foo@xxxxxxxxx
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:chromi@xxxxxxxxxxxxxxxxxxxxx::D+WYjp0B4C/Y4q7u:
00000000000000000000000000000000000000
hashcash token: 1:0:040916:foo@xxxxxxxxx::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:foo@xxxxxxx::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: chromi@xxxxxxxxxxxxxxxxxxxxx
website: http://www.chromatix.uklinux.net/
tagline: The key to knowledge is not to rely on people to teach you it.
Other related posts:
