Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
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!