On Thu, Jan 4, 2024 at 10:01 AM jian he <jian.universality@gmail.com> wrote:
>
> I still cannot git apply your patch cleanly. in
I don't know why you're using that -- the git apply man page even says
"Use git-am(1) to create commits from patches generated by
git-format-patch(1) and/or received by email."
Or, if that fails, use "patch".
> http://cfbot.cputube.org/ i cannot find your patch.
> ( so, it might be that I test based on incomplete information).
> but only hashfn_unstable.h influences bench_hash/bench_hash.c.
>
> so I attached the whole patch that I had git applied, that is the
> changes i applied for the following tests.
Well, aside from the added text-editor detritus, it looks like this
has everything except v11-0008, without which I still get improvement
for the pgstat hash.
> Model name: Intel(R) Core(TM) i5-14600K
> The following is tested with another machine, also listed machine spec below.
> I tested 3 times, the results is very similar as following:
> select * from bench_cstring_hash_aligned(100000); 4705.686 ms
> select * from bench_cstring_hash_unaligned(100000); 6835.753 ms
> select * from bench_pgstat_hash(100000); 2678.978 ms
> select * from bench_pgstat_hash_fh(100000); 6199.017 ms
> select * from bench_string_hash(100000); 847.699 ms
I was fully prepared to believe something like 32-bit Arm would have
difficulty with 64-bit shifts/multiplies etc., but this makes no sense
at all. In this test, on my machine, HEAD's pgstat_hash is 3x faster
than HEAD's "strlen + hash_bytes", but for you it's 3x slower. To
improve reproducibility, I've added the .sql files and a bench script
to v13. I invite you to run bench_hash.sh and see if that changes
anything.
v13 also
- adds an assert that aligned and unaligned C string calculations give
the same result
- properly mixes roleid in the namespace hash, since it's now
convenient to do so (0005 is an alternate method)
- removes the broken makefile from the benchmark (not for commit anyway)