Geth MoarVM: ugexe++ created pull request #1894:
Configure dyncall for arm64 on Windows		 00:12
timo i think we should look into something one step up from C preprocessor macros but not as far as C++ to make something like "specialized string ops funcs per storage type". maybe a .c.in that we expand with a perl or even raku script (as long as we put the generated code into source control that would be fine) 00:32
C preprocessor macros are pretty annoying in that you have to put \ at the end of every line, and of course when debugging it all counts as just a single line, so you can't properly single-step through it 00:33
Geth MoarVM: ugexe++ created pull request #1895:
Enable experimental c11 atomics on MSVC		 00:35
ugexe gist.github.com/ugexe/a4aedf6bfc8f...babf9360a9 - this is what i have so far to spin up an arm windows 11 vm using an arm toolchain on an apple silicon host and why i've been creating those prs 00:50
i like that i can just use winget to install all the microsoft msvc and git stuff. it is unfortunate winget installs an x86 perl so i had to use like 4 commands to install a precompiled arm64 perl from some randos github 00:53
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/01/20/2025-...-released/ 12:59
MasterDuke hm. the moarvm changes to use a different hash function for our string hash code were pretty trivial. but the nqp build dies almost instantly: 19:35
Unhandled exception: No dispatcher registered with ID 'boot-code'
   at <unknown>:1  (src/vm/moar/stage0/ModuleLoader.moarvm:<dependencies+deserialize>)
 from <unknown>:1  (src/vm/moar/stage0/nqp.moarvm:<dependencies+deserialize>)
assuming i didn't do anything incorrectly in moarvm, is this still going to be a bootstrapping annoyance? 19:36
lizmat boot-code is one of the dispatchers supplied by MoarVM, is it not? 19:37
according to the doc in github.com/rakudo/rakudo/blob/main...#boot-code it is 19:38
MasterDuke debug print i added: `hash for 'boot-code' == 7465411439051489383` 19:42
so it is calculating hashes (i.e., they're not all 0 or the same value)
but it's not going to be the same value as it was with the original hash function 19:43
lizmat ah, you mean: hash the dispatch name
ah, yes, that would be a bootstrapping annoyance 19:44
MasterDuke the print i added was in MVM_string_compute_hash_code()
lizmat feels like you're going to need some temporary scaffolding there, trying the old hashing if the new one failed 19:45
until NQP got bootstrapped, then remove scaffolding again, only using the new hash algorithm?
MasterDuke would this change break all precomps? 19:46
if it just invalidated them that'd be ok, but i wouldn't want errors
lizmat sheap c "boot-code" 19:47
229 boot-code
MasterDuke i'm not even sure where the scaffolding needs to go, nqp i guess? 19:47
lizmat looks like at least the core setting keeps the dispatcher names as strings
feels to me the scaffolding should be in MoarVM, as that does the hashing? does it not ? 19:48
timo i believe these dispatchers are all completely internal to moar and should not rely on nqp at all? 19:50
lizmat yeah, and externally dispatched by name, not hashes ID 19:51
timo MVM_disp_syscall_setup should run on instance startup
it uses string_ascii_decode_nt, maybe that didn't get changed for your hash changes?
or you're missing changes for fixkey hashes? 19:52
MasterDuke i get a different error if i disable the hash code check in MVM_string_equals 19:53
Unhandled exception: chars requires a concrete string, but got null 19:54
   at <unknown>:1  (src/vm/moar/stage0/ModuleLoader.moarvm:<dependencies+deserialize>)
timo is there a branch i could look at?
MasterDuke but MVM_args_perform_flattening also sorts via hash code 19:55
github.com/MasterDuke17/MoarVM/tre...of_siphash 19:56
MasterDuke MVM_args_perform_flattening looks like maybe it shouldn't matter, since the sorting is just to not pollute a cache 20:18
timo the error "requires a concrete string but got null" happens because MVM_find_sc_by_handle with the handle "__6MODEL_CORE__" is returning null 20:19
MasterDuke `hash for '__6MODEL_CORE__' == 5285849711074998674` 20:20
oh, i'm getting a bunch of different values for that!? 20:21
timo 3 1 3dce8bce6b8d516d (15) 0x20000592550 __6MODEL_CORE__ 20:22
it's definitely in there
different values in the same execution? 20:23
MasterDuke oh wait, of course i am, i'm seeding with random
let me double check it's not different in the same execution 20:24
hm, added tc to the print and definitely getting different values with the same tc pointer 20:27
tc = 0x3a384020000, hash for 'boot-code' == 6762424055001201415
tc = 0x3a384020000, hash for 'boot-code' == 4838451069062238869
tc = 0x5609c020000, storage_type = 2, hash for 'boot-code' == 15145260379189473548 20:29
tc = 0x5609c020000, storage_type = 0, hash for 'boot-code' == 2991972996574593375
MVM_STRING_GRAPHEME_8 vs MVM_STRING_GRAPHEME_32 20:30
timo are you sure rapidhash_withSeed does the same thing when feeding piecewise as when feeding in one go? 20:31
oh, right
yeah that won't work, of course. i could have thought of that
the graphemes all have to be upgraded to 32bit 20:32
MasterDuke ugh
timo i think we have a special version for feeding a buffer of 8bit values that are supposed to pretend to be 32bit
MasterDuke ? 20:33
timo check what IN_SITU_8 did before your commit
it had this grapheme view struct where it took two 8bit graphemes at a time from the in_situ blob, stored them into the two slots of a 64bit big 32bit-per-slot array 20:34
and then it uses "add64bits" on the stuff it just created
MasterDuke yeah. i thought we'd be able to hash everything all at once in addition to using a faster hash function, but i guess that's not possible 20:35
timo but alas ... 20:37
MasterDuke hm, what should we do when s_len == 0? 20:52
timo doesn't matter as long as it doesn't easily collide with something you can have as a string? 20:54
could be just the secret seed?
hum. that sounds like a bad idea?
MasterDuke rakudo just built. updated my branch 20:57
all tests pass 21:02
and crazy, m-test takes 28s and m-spectest is only 10s slower 21:03
oh wait, nm, mixing time on desktop and laptop
m-test is 28s on laptop (on battery), 38s on desktop 21:04
m-spectest is 221s on laptop (on battery), 199s on desktop 21:07
Geth MoarVM: MasterDuke17++ created pull request #1896:
Use rapidhash instead of siphash for string hashes		 21:48
ugexe oh, the arm windows dyncall commits aren't in an official release yet either 21:49
official dyncall release
timo oh! 21:52

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!