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 B1B3773A05C0ED0176787A4F1574FF0075F7521E vs 3C8B9F4B983AFA9F644D26E2B34FA3E03A2BEF16, i think that's sufficiently different 01:13
what i am trying to figure out now is why the implementation i copied from git's source is giving different results... 01:14
it seems to be a bit faster than ours. however, nqp::sha1 actually spends most of the time in MVM_string_utf8_encode_substr when you sha1 a large string (like the contents of a source file) 01:25
but making that faster seems quite a bit more involved. and i think is going to require something i've brought up before, which is making more specific functions. currently the grapheme iterator checks the string's storage type at every call 01:26
it should predict perfectly, but it would be even faster not to have that at all...
jnthn, nine, timo, japhb, etc: any ideas for how to make MVM_string_utf8_encode_substr faster? my thought right now is something like creating MVM_string_gi_get_grapheme_for_(32|ascii|8) functions, but i'm open to other suggestions 01:28
vrurg jnthn: Do you actually mind merging github.com/rakudo/rakudo/pull/5117? 21:41
MasterDuke looks like git's sha1 implementation does different padding, but i'm not sure why 22:05
hm, and the outputs don't even seem to match if i don't pad either... 22:08
jnthn vrurg: I'll try and look at it tomorrow; I'm finally free from $dayjob for a while 23:16
vrurg: If I still haven't commented on it tomorrow, just merge it
vrurg jnthn: Thanks! I wanted it because stumbled upon an error without any location. Debugging is kind of a nightmare then. :) 23:17