MasterDuke some random numbers from adding prints to MVM_string_utf8_decode() to perhaps inspire ideas 02:43
when compiling CORE.c: 02:44
     14 decoding 12 bytes into 12 GRAPHEME_8 chars
     14 decoding 67 bytes into 67 GRAPHEME_8 chars
     16 decoding 11 bytes into 11 GRAPHEME_8 chars
     37 decoding 30 bytes into 10 GRAPHEME_32 chars
     60 decoding 3 bytes into 1 GRAPHEME_32 chars
    145 decoding 86 bytes into 86 GRAPHEME_8 chars
    577 decoding 106 bytes into 106 GRAPHEME_8 chars
    659 decoding 16 bytes into 12 GRAPHEME_32 chars
    705 decoding 4 bytes into 1 GRAPHEME_32 chars
   1330 decoding 15 bytes into 13 GRAPHEME_32 chars
   1330 decoding 16 bytes into 14 GRAPHEME_32 chars
   1410 decoding 2 bytes into 1 GRAPHEME_32 chars
   2443 decoding 14 bytes into 12 GRAPHEME_32 chars
   2727 decoding 13 bytes into 11 GRAPHEME_32 chars
  14933 decoding 12 bytes into 10 GRAPHEME_32 chars 02:45
when running `raku -e 'my $s = 0; my $R = "rakudo/README.md".IO; my $L = "rakudo/LICENSE".IO; for ^2_000 { $s += $R.slurp.lines.elems; $s += $L.slurp.lines.elems; }; say $s;'`: 02:46
     14 decoding 11 bytes into 9 GRAPHEME_32 chars
     14 decoding 12 bytes into 12 GRAPHEME_8 chars
     14 decoding 15 bytes into 13 GRAPHEME_32 chars
     16 decoding 11 bytes into 11 GRAPHEME_8 chars
     23 decoding 3 bytes into 1 GRAPHEME_32 chars
     37 decoding 30 bytes into 10 GRAPHEME_32 chars
     41 decoding 12 bytes into 10 GRAPHEME_32 chars
     70 decoding 14 bytes into 12 GRAPHEME_32 chars
   2000 decoding 8651 bytes into 8646 GRAPHEME_32 chars
   2000 decoding 8902 bytes into 8902 GRAPHEME_8 chars
now, what do these numbers inspire for optimization ideas? 02:47
there have been lots of new fast utf8 decoding libraries in the past couple years. i think most aren't using/doing NFG, but can we adopt and adapt them for a fast path and easily+quickly fall back to what we have now if/when they hit an NFG case? 02:51
coleman what does NFG case mean 02:52
MasterDuke normal form grapheme. and i'm not 100% sure i'm making sense 02:53
coleman I randomly found this function-tracer today github.com/namhyung/uftrace?tab=re...se-uftrace 03:00
MasterDuke oh, that looks interesting 03:02
coleman I've played with bpftrace, but it's super low level. This seems to have more useful stuff built in. Needs a couple of compiler flags and that's it. 03:03
To be honest I don't know how to get it in the mix with raku->nqp->moarvm 03:04
MasterDuke well, just running it with -P sort of works for raku 03:15
but i think it's not following the fork/exec in the runner
coleman yeah i was thinking you need to wrap the nqp runner 03:18
how is that invoked?
if it is one place, that is. maybe the runner is invoked from many places. i don't know, myself 03:19
MasterDuke `uftrace record -e -l -a -P . -- uftrace record -e -l -a -P . -- raku -e 'say "hi"'` gives a segfault from uftrace, but i do actually get some useful information from `uftrace report` after 03:24
doh, errant double paste
the recordings are large, i think ~500mb for `say "hi"` 03:26
coleman Filtering options? github.com/namhyung/uftrace/blob/m...on-options 03:37
timo can we try how using only 8 bits out of 32 for our strings impacts collisions, if at all? 16:43
i feel like we should be able to at least use the storage of 32bit in situ or blob directly with the hash function instead of 32bit at a time? 16:58
if we're smart?
i guess calling _withSeed multiple times with the output of the previous call isn't the same as running the hash with the same input but at once 16:59
i guess siphash used to have the "finish" function split out, so we could do what we did even with strands-based strings 17:00
and rapidhash has it built into rapidhash_internal at the end and can't be split out
[Coke] we can apply the rapidhash update right after release, and I'll trigger a blin run with it 17:04
jdv thats so low level youd think spectest would cover, no? 17:06
timo yeah we don't expose the hash value of a string to user space in any way, i think it shouldn't cause trouble in user code if it doesn't blow up any spec tests 17:08
[Coke] .... ok 17:15
I'm happy to defer to jdv there.
jdv be my guest;) its just so resource intensive and itd be caught on the normal run if it somehow broke something. 17:17
[Coke] normal run already done 17:25
jdv i meant the next one but i saw that, cool. is it all figured? 17:46
[Coke] If we're not 100% sure, let's wait til post release. 17:54
Always fine to have something queued up for the next one 17:55
lizmat hmmm... the REA harvester just crashed with: 17:58
MoarVM oops: Unknown spesh arg guard opcode -1172811872 reached
[Coke] O_o; 18:01
timo lizmat: arm, right? 18:34
lizmat apple silicon indeed
timo that kind of thing should be fixed by my moarvm commit from ... uhh 18:35
that one pull request about arm freezes
same underlying issue, but the error message i put in would otherwise have been a freeze 18:36
so, moar version please, and maybe upgrade to very latest?
BBIAB
lizmat it *is* the very latest 18:39
Welcome to Rakudo™ v2024.12-49-gb4d798329.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.12-22-gcaf97bf07.
(the harvester runs on my dev machine) 18:40
timo oh it was never merged? 21:25
you will want atomic_accesses_to_spesh_arg_guard
lizmat I will wait until after the release :-) 21:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!