[hashcash] Re: status of hashcash version 1?

  • From: Jonathan Morton <chromi@xxxxxxxxxxxxxxxxxxxxx>
  • To: hashcash@xxxxxxxxxxxxx
  • Date: Fri, 30 Jul 2004 02:54:59 +0100

I guess the best thing to do is to measure once (e.g. at package install
time), and store the result for which alternative is the best, right? 

Ick.  I was hoping either the test was fast enough to run always, and
the CPU detection was also v. fast.

The CPU detection is extremely fast, and accurate enough to be useful on the machines I've had the chance to test. As I mentioned, it's done as a matter of course as part of initialisation. I find it usually selects the fastest core by itself, or one within a few percent of the fastest, on the most common x86 and PowerPC platforms.

(M68K support is still iffy - I need to get a GNU system running on one of my old Macs, and write an assembler version of the core to boot. ARM, SPARC and other relatively register-rich architectures with good compiler support are expected to work similarly well to PowerPC, but are untested as yet.)

The benchmark method is probably too slow to use on every run, unless it is done once for a significant batch of work. However, it is the most accurate way possible of selecting the right core.

Suggested compromises:

- For runs with a trivial amount of work to do (under 16-20 bits?), use static CPU detection to avoid overhead. For larger bit counts and/or larger batches of stamps to compute, run the full benchmark. This is a classic latency/throughput tradeoff.

- Run the full benchmark if a previous-result store is missing, invalid, or out of date. This takes advantage of the fact that hardware usually changes infrequently. However, it breaks slightly if the same user runs multiple hardware configurations from a single filesystem, as I do (to some extent) with my Athlons and Pentium-MMX.

- A hybrid of the two above approaches may be appropriate. The store can be disabled for machines with read-only storage or a highly heterogeneous hardware environment, while still being useful for machines with a more typical configuration.

--------------------------------------------------------------
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:

  1. Home
  2. hashcash
  3. Archive
  4. 07-2004