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.
00:07 reportable6 left 00:09 reportable6 joined 00:38 uzl[m] left 00:39 AlexDaniel left, crystalfrost[m] left, psydroid left 01:04 uzl[m] joined 01:06 frost joined 01:22 psydroid joined 01:33 AlexDaniel joined 01:55 crystalfrost[m] joined 02:43 Kaipei left 04:06 Kaipei joined 05:26 reportable6 left, coverable6 left, evalable6 left, statisfiable6 left, tellable6 left, committable6 left, nativecallable6 left, greppable6 left, quotable6 left, bloatable6 left, notable6 left, releasable6 left, bisectable6 left, sourceable6 left, benchable6 left, unicodable6 left, shareable6 left, linkable6 left 05:27 evalable6 joined, benchable6 joined, bloatable6 joined, releasable6 joined, committable6 joined 05:28 unicodable6 joined, greppable6 joined, sourceable6 joined, coverable6 joined, bisectable6 joined, nativecallable6 joined, notable6 joined 05:29 statisfiable6 joined, shareable6 joined, reportable6 joined, linkable6 joined, quotable6 joined, tellable6 joined 05:47 samcv left, samcv joined 06:07 reportable6 left 06:10 reportable6 joined
Nicholas Servus, #moarvm 06:52
nine Zers 06:53
06:55 nine left 06:56 nine joined
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
09:42 linkable6 left, evalable6 left, evalable6 joined, linkable6 joined 10:21 Altai-man left 10:24 sena_kun joined
MasterDuke looks like git's sha1 implementations are slightly slower than ours 10:56
12:06 tellable6 left, benchable6 left, committable6 left, releasable6 left, greppable6 left, quotable6 left, coverable6 left, reportable6 left, statisfiable6 left, unicodable6 left, notable6 left, nativecallable6 left, bisectable6 left, evalable6 left, linkable6 left, sourceable6 left, bloatable6 left, shareable6 left 12:07 tellable6 joined, sourceable6 joined, statisfiable6 joined, benchable6 joined, unicodable6 joined, reportable6 joined 12:08 notable6 joined, evalable6 joined, nativecallable6 joined, quotable6 joined, releasable6 joined, shareable6 joined, bloatable6 joined 12:09 bisectable6 joined, coverable6 joined, greppable6 joined, committable6 joined, linkable6 joined 13:03 vrurg_ joined 13:05 vrurg left 14:05 vrurg_ is now known as vrurg
japhb Well that's surprising. 14:23
14:27 frost left
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 :)
15:29 evalable6 left, linkable6 left 15:31 linkable6 joined, evalable6 joined
japhb nine++ # Go nine, go nine! 15:35
17:52 vrurg left 18:06 vrurg joined 18:08 reportable6 left 18:10 reportable6 joined 18:11 vrurg left 19:11 notable6 left, shareable6 left, benchable6 left, greppable6 left, tellable6 left, committable6 left, bisectable6 left, nativecallable6 left, releasable6 left, linkable6 left, sourceable6 left, statisfiable6 left, coverable6 left, bloatable6 left, quotable6 left, unicodable6 left, evalable6 left, evalable6 joined 19:12 benchable6 joined, committable6 joined, bisectable6 joined, notable6 joined, unicodable6 joined 19:13 tellable6 joined, statisfiable6 joined, linkable6 joined, sourceable6 joined, greppable6 joined, shareable6 joined 19:14 quotable6 joined, coverable6 joined, releasable6 joined, nativecallable6 joined, bloatable6 joined 19:40 vrurg joined 19:44 vrurg left
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
20:41 vrurg joined
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
20:46 vrurg left
MasterDuke right, i guess synthetics and such would be a problem 20:52
21:31 sena_kun left 21:32 sena_kun joined 23:59 vrurg joined