japhb Anyone know offhand what hash algorithm we're using to hash keys in MoarVM's map/hash implementations? 00:58
Currently deep diving some info about relatively recent hash algorithms, so curious which (if any) we're using. 00:59
ugexe rapidhash github.com/MoarVM/MoarVM/commit/62...192812b7c8 01:05
02:25 sourceable6 left, notable6 left, shareable6 left, notable6 joined, quotable6 left, unicodable6 left, committable6 left, greppable6 left 02:27 committable6 joined, bloatable6 left, linkable6 left 02:28 shareable6 joined, sourceable6 joined, greppable6 joined, unicodable6 joined, quotable6 joined 02:29 bloatable6 joined, linkable6 joined
japhb thx 02:52
Voldenet huh, rapidhash benchmarks suggest that xxh3 is faster on most common PCs 10:37
and gxhash is a lot faster 10:39
in fact xxh3 is so standard that it's packaged into .net8 10:45
11:41 librasteve_ joined
Geth MoarVM: MasterDuke17++ created pull request #1959:
Bump rapidhash to v3
11:55
13:58 librasteve_ left
japhb It's frustrating how benchmarks age, such that comparisons are only a snapshot in time, with the most active implementations switching leadership positions on the regular. 16:22
This could of course be solved by someone benchmarking All The Things at a consistent interval, but most of the people who do that sort of thing don't do an all-inclusive suite, or have an axe to grind about certain algorithms and rather than just marking them in the results, don't test them at all .... 16:23
Witness the number of benchmarks that don't include anything (like gxhash) that's dependent on particular CPU features, or don't include any hash that doesn't have seeds of a certain size, or what have you. 16:25
FWIW Voldenet I *suspect* xxh3 is getting special treatment not just because it's a good performant hash (which AFAICT it is), but also because it was written by the same guy who created LZ4, zstd, and I suspect OpenZL (I know he's a contributor, but I don't know if he wrote the core) 16:29
Geth MoarVM/main: 204a73098b | MasterDuke17++ (committed using GitHub Web editor) | 2 files
Bump rapidhash to v3
Voldenet I would bet that the lib gets special treatment, it just feels funny to me that rapidhash presented benchmarks that show it as slower 16:35
[Coke] GAH 16:36
Voldenet while smhasher benchmarks show rapidhash as slightly faster
[Coke] Folks, are we really pushing a change to moarvm with a week to go AFTER I've started the blin run?
Voldenet and on amd ryzen cpus no less
[Coke] .seen masterduke 16:37
tellable6 [Coke], I saw masterduke 2025-09-18T21:16:20Z in #raku-dev: <MasterDuke> dinner &
[Coke] kills the blin run
[Coke] shuts down the VM so he's not paying for it. :| 16:38
Voldenet otoh on intel CPUs rapidhash has half the throughput than xxh3 for some reason 16:39
Geth MoarVM/revert-1959-update_rapidhash_to_v3: 9d79b310f2 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Revert "Bump rapidhash to v3"

This reverts commit 204a73098bc5d3e34db467c85cb2d6b3ac7991de.
16:42
MoarVM: lizmat++ created pull request #1960:
Revert "Bump rapidhash to v3"
MoarVM/main: 70225c6b5e | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Revert "Bump rapidhash to v3" (#1960)

This reverts commit 204a73098bc5d3e34db467c85cb2d6b3ac7991de.
lizmat [Coke]: sorry, was a little over eager doing something :-( 16:43
Geth MoarVM/revert-1960-revert-1959-update_rapidhash_to_v3: a61094c65c | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Revert "Revert "Bump rapidhash to v3" (#1960)"

This reverts commit 70225c6b5efd10aa2c930982f2cfebf4e7073ba7.
MoarVM: lizmat++ created pull request #1961:
Bump rapidhash to v3
16:44
lizmat [Coke]: sorry for the noise :-(
[Coke] no worries! 16:48
Geth MoarVM: MasterDuke17++ created pull request #1962:
Bump libtommath to 1.3.0
17:56
japhb [Coke]: Apologies for starting something; I was just studying and pontificating .... 21:26
[Coke] heee. no worries, everything is fine. 21:56