Hello Art,

On Fri, 24 Oct 2003 16:59:05 GMT, Art Martz <artmartz (AT) triad (DOT) rr.com>
wrote:
It is good that you fixed the screen updates and removed some of the
platform specific code.

I looked at your new version it still has the following issues:

1) Uses TIME() to measure things
This is too course on fast machines, will not work across midnight and
more importantly is *wall* clock time not cpu time leading to
inconsistent results. Use SYSTEM(9) instead it was put in for this
task.
2) Tests are too long, other processes on the machine are more likely
to interrupt screwing up the results.
3) Keys interact badly with hash algorithm.
Not sure if you meant this but your keys are of the form:
ABCDABCDBENCHMARK.PICK
where ABCDABCD are the only part that varies among the records. The
traditional pick hash function i think is 32 bit limited and right
biased meaning for long keys it is important that the rightmost part
is variable.
4) Even fixing 3) the keys seem to resonate(alternating empty groups
and grossly overflowed groups) with the hash algorithm.
5) For some reason you use RND() as part of the record, i don't think
anyone does but good random numbers are hard to produce....this
shouldnt be counted as part of your write time. Also this means you
cannot later read back records as a check.
6) You create dict items '1', '2','3' etc what happens if you want to
benchmark 'SELECT JUNK WITH 1 = 1' What exactly would you get?

- Robert

Robert Colquhoun wrote:

This was designed to be the only thing the system is doing. Not on a
live production system. You need *some* control of the environment for
repeatable results. Since the overall run time should ideally be in the
5-30 minutes range, I don't really think system(9) vs. time() is *that*
big of a deal. I don't have a problem with changing it, I just don't see
much change in the results by doing so.

Well, I was trying to avoid all this (back umpteen years ago when I
first borrowed (stole) some code to start this bench). I'd be interested
in any other comments from anybody else about how to best generate IDs
that hash evenly thru a properly sized D3 style hashed file. Randomize
both the left *and* the right sides of the key?

Art

Art Martz wrote:
[snip]
Sequentialize the right side of the key.
Don't randomize anything (including left
side of key) for repeatable results.

I'd use sequential item IDs, all numeric, same length,
padded on left with zeroes. Trite, but adequate.

Then, set your modulo to 10 for a perfect hash! =`;^>

-- frosty

The actual hashing algorithm isn't that tough. Just add the binary of the
bytes of the key and divide by the modulo of the file and add 1. In a file
with a modulo of 7, item ids like 1ABCDEF, 2ABCDEF and 3ABCDEF all hash into
different groups.

Mark

"Art Martz" <artmartz (AT) triad (DOT) rr.com> wrote