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.
Nicholas Servus, #moarvm 06:52
nine Zers 06:53
MasterDuke morning 07:31
nine Ah, a traditionalist! 07:37
MasterDuke a monolinguist 07:41
nine nine@sphinx:~/rakudo (rakuast_wip *)> RAKUDO_RAKUAST=1 ./rakudo-m -Ilib -e 'use Test; diag("NYI"); done-testing;' 08:18
# NYI
1..0
lizmat mogge 08:36
nine Next step to unlock Test's functionality will be real support for coercion types. Till now I've only enabled them in the parser, but they don't coerce anything yet. 08:53
lizmat nine++ ++nine 08:59
I think I found an issue in the regex engine:
m: say "aabbcc" ~~ / b ** 0..3 / # this is wrong, I think
camelia ｢｣
lizmat m: say "aabbcc" ~~ / b ** 1..3 / # this goes to 2 09:00
camelia ｢bb｣
jnthnwrthngtn Looks buggy to me, I'd bet on a semi-predicate issue 09:06
lizmat ok, so buggable I guess :-) 09:23
MasterDuke looks like git's sha1 implementations are slightly slower than ours 10:56
japhb Well that's surprising. 14:23
nine > RAKUDO_RAKUAST=1 ./rakudo-m -Ilib -e 'use Test; ok(1); done-testing;' 15:25
ok 1 -
1..1
Thanks to support for "is copy" on parameters :)
japhb nine++ # Go nine, go nine! 15:35
MasterDuke ok, after some more correctly-done benchmarking, git's sha1 implementation is the same speed as our current one. which is also the same or faster as the other random implementations i was able to test. the outlier is openssl's, which is a bunch faster 19:55
however, bringing in openssl is a big dependency
so unless someone speaks up and says they think it would be worth the cost/complications of using openssl, i'm going to leave this experiment concluding that no change in our sha1 implementation is needed 19:57
lizmat unless you can lift the sha1 code out of the openssl distro ? 20:00
MasterDuke it doesn't look terribly easy. and i believe the main reason they're faster is they gen platform/cpu specific asm 20:01
lizmat ah... ok... that looks like the difference then :-) 20:02
so... wouldn't that imply that writing the sha code in nqp would make it automatically scale up for the cpu in use ? :-) 20:03
MasterDuke i think it'll be hard to beat the C implementation we have 20:09
what would probably make more sense is to switch to a faster algorithm, if there is a faster one for our use case. but that would cause every precomp file in existence to be invalidated, so maybe we don't want that 20:12
japhb They're already invalidated every time we install a new Rakudo 20:14
MasterDuke fwiw, in a my benchmark `use nqp; my $a = "src/core.c/Int.pm6".IO.slurp; my $b; my $s = now; $b := nqp::sha1($a) for ^10_000; say now - $s; say $b`, the most expensive function at half the time is MVM_string_utf8_encode_substr. next is a sha1 related function at 25%, then next is a spesh function with only 1.3%
oh right. maybe i'll experiment with a different algorithm then 20:15
lizmat yeah, each Rakdo compile gets its own precomp files 20:16
$ cleanup-precomp
Freed 678,739,528 bytes from 7 repositories.
japhb Wait, why is utf8 *encode* chewing so much time?
MasterDuke github.com/MoarVM/MoarVM/blob/mast...on.c#L3200
lizmat that would be the .slurp I'd say?
japhb lizmat: Wouldn't that be *decode*?
lizmat nqp::sha1 takes a Str 20:17
*not* a Buf
you could argue that having nqp::sha1 taking an int array, would make things a lot faster
as one could then slurp the file as :bin 20:18
and then just feed it the Buf
afk&
japhb OH, I see, yeah, the slurp is decoding, and then the sha1 is encoding first. GAH
Yeah, what lizmat said.
lizmat MasterDuke: if you're looking at making nqp::sha1 more useful, having it take an REPR VMArray would be the trick, I'd say 20:19
afk&
MasterDuke hm, i can give that a try 20:23
ugh, it does have some ecosystem use gist.github.com/Whateverable/42287...da409e62a5 20:25
japhb MasterDuke: I can see a couple ways out of that, both of which depend on a new MoarVM op: 1. Wrap the new MoarVM op into a new nqp::op, and change the callers that would get advantage from the VMArray version. 2. Rewrite the nqp::op to call the appropriate MoarVM op depending on the type/REPR of the argument. 20:32
MasterDuke yep 20:39
MasterDuke if the MVMString storage_type is not MVM_STRING_STRAND, can i just hash the body.storage directly instead of utf8 encoding it? 20:42
japhb I think that would only work for MVM_STRING_GRAPHEME_ASCII 20:45
MasterDuke right, i guess synthetics and such would be a problem 20: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!