[hashcash] Re: libfastmint integration attempt (in progress gets stuck in loop)
- From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Wed, 4 Aug 2004 16:29:36 +0100
Well I tried calling hashcash_fastmint and hacking a bit of hashcash
code around to support that quickly.
minor issue: hashcash_fastmint does not track how many iterestions it
took, but the existing command line code displays that (in verbose
mode)
(I worked around by timing hashcash_fastmint, and calculating from
that and the speed measurement how many tries it would have done:-)
As long as it doesn't go into repeat mode, it should be possible to
read and decode this from the counter field. There's example code to
do this in the benchmark routine. I'm not terribly sure how useful a
metric this is, however, outside of benchmarking.
bigger issue: I tried calling hashcash_benchtest(0) in
hashcash_per_sec, but it takes about 5 seconds elapsed which is a bit
slow for a cached-but-calculated on the fly if not set C macro type of
thing.
Which is why I didn't suggest using it that way.
Could we use a smaller iteration count and much higher resolution
timer?
I don't know where to get a cross-platform CPU-time-only timer that has
higher resolution than clock(). Wall-time timers are a dime a dozen.
You can reduce the bit count by all means, but the benchmark will then
have worse resolution - which, admittedly, may not matter very much for
typical applications.
I had some x86 asm code somewhere to get real ticks. Of course issue
there is you don't know the CPU rate.
And, I assume, it measures wall time rather than CPU time. The CPU
rate could always be calculated by comparing the ticker to a standard
timer. There's also the issue that the ticker may not be available on
all CPUs, particularly the older ones that don't have CPUID. It's also
not a cross-platform solution, which is important here.
minor issue: hashcash_fastmint is recursive, and I think the stack
gets deeper very 8 mins or so on my machine. Should be a way to do
this non-recursively.
Yes, I'll think about this. It's about every 12 minutes on my TiBook,
and most modern OSes have quite deep stacks, so (for the time being)
any reasonable bit count shouldn't run out of space.
(Still quietly laughing at the P4 needing 500% of the clock speed to
get 135% of the performance of the G4. I really should try to write
the SSE2 core at some point though, as it'll probably level the playing
field considerably. I need hardware to test with, though.)
btw the "best bits of collision so far" is kind of interesting
progress measure and might be worth incorporating into output/progress
indicator at some point.
Perhaps I could introduce a callback function, which gets called
occasionally from inside the minter. That would get you the iteration
count and bits-so-far metrics neatly enough. I could also arrange for
it to be called unconditionally on completion, so you end up with the
final number of iterations.
And lastly I've no doubt bodged something as it gets stuck chews CPU
and doesn't output anything. I made a minor change to libfastmint.c
verbosity (was still outputting something with verbosity 0). If
anyone feels like fixing that, please be my guest :-)
The benchmark works at my end with pr7, so try recompiling from
scratch. There's something wrong with the minting routine, though, and
I'll work on that.
--------------------------------------------------------------
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:
