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:02 reportable6 left 00:04 reportable6 joined 00:09 squashable6 left 00:11 squashable6 joined 01:01 patrickb left 01:11 japhb left, japhb joined 01:48 kjp left 02:15 jgaz joined 03:20 evalable6 left, linkable6 left 03:22 evalable6 joined 04:22 linkable6 joined 05:22 quotable6 left, nativecallable6 left, reportable6 left, sourceable6 left, tellable6 left, committable6 left, shareable6 left, notable6 left, unicodable6 left, linkable6 left, coverable6 left, benchable6 left, evalable6 left, bisectable6 left, releasable6 left, bloatable6 left, greppable6 left, squashable6 left, statisfiable6 left 05:23 coverable6 joined 05:24 shareable6 joined, reportable6 joined, statisfiable6 joined 05:25 linkable6 joined, nativecallable6 joined, quotable6 joined, evalable6 joined 06:03 reportable6 left 06:04 frost joined 06:23 notable6 joined 06:24 benchable6 joined, tellable6 joined 06:25 sourceable6 joined 07:03 reportable6 joined 07:23 greppable6 joined 07:25 unicodable6 joined, bisectable6 joined 07:26 squashable6 joined 07:57 frost left 08:02 linkable6 left 08:05 linkable6 joined 08:24 releasable6 joined, committable6 joined 09:01 jgaz left
nine This is suprising: 3KLOC in the static optimizer, but what we don't optimize is branches with constant conditions. Thus my constant \debug = 0; if debug { ... } does carry an unexpected runtime cost. 09:57
All the more surprising since it looks kinda trivial to do. It even worked on my very first try (which actually makes me a bit nervous about it) 09:58
dogbert17 nine: are there any noticable improvements? 11:01
nine dogbert17: I have too many half-finished local changes to properly test 11:23
11:23 bloatable6 joined
nine But with "is pure" traits for NQP routines, p6callmethodhow constant folding and conditional constant folding all implemented something like uint.^unsigned ?? nqp::atpos_u(...) !! nqp::atpos_i(...) will now be optimized to just nqp::atpos_u(...) 11:31
So...win? Unfortunately not :/ Because Blob is generic, so instead of uint which is a NativeHOW with a pure unsigned method, the optimizer sees T which is a GenericHOW. 11:32
So while this was a fun exercise, I'll have to go the native_array route with a custom ^parameterize method 11:38
lizmat meh 11:42
12:02 reportable6 left, reportable6 joined
nine Huh....after moving methods into appropriate roles and adding $?CLASS.^add_role(T.^unsigned ?? UnsignedBlob[T] !! SignedBlob[T]); to Blob's role body, printing fails with "encode requires a native int array". Apparently we lose the native size along the way 13:21
lizmat meh again 13:22
nine Normally there's a ^set_array_type call on Blob followed by utf8. But now it's Blob followed by UnsignedBlob. It's not set anymore on utf8. 13:58
I don't really understand where things go wrong, but at least I have a fix anyway: teach the RoleToRoleApplier to copy over array_type just like the RoleToClassApplier does 14:22
Next up: Multi method 'AT-POS' with signature :(Buf:D: int \pos, *%_) must be resolved by class Buf because it exists in multiple roles (UnsignedBlob, UnsignedBuf) 14:23
timo time for "is default"?
nine Doesn't seem to help 14:26
FWIW the "is default" trait is not documented for this purpose anyway 14:30
And the docs saying "cause a compile-time error, which can be solved by providing a method of the same name in the class" is rather unhelpful as well. There is a reason for _not_ having these methods in the class in the first place
14:38 jgaz joined
timo hm, add a proto somewhere? 14:43
nine Replacing ::?CLASS with ::?ROLE seems to help 14:49
Though I'm not sure how Rakudo finds the right method this way. After all the resulting class does both roles 14:52
timo and both are in there? 14:56
15:11 jgaz left
nine I guess so. So far it works, so I don't feel like investigating further. 15:21
make test looks good. spectest yields a ton of "MVMArray: atpos U32 expected int register" like errors
Because e.g. class native_i does PredictiveIterator # Class for iterating native int arrays and nqp::list_i 15:25
Yes, int arrays. Not uint arrays which we're also using them for 15:26
# Expected: Cannot unbox 101 bit wide bigint into native integer 16:08
# Got: Cannot unbox 101 bit wide bigint into native integer in mp_get_int64
Ah, yes...
Bad VM, giving more information...
MasterDuke did you make the change to the error message? looks like something i would have done 17:07
nine yes I did 17:08
MasterDuke ah
i'm pretty sure i've done something exactly like that while attempting to debug the gmp branch on windows 17:09
[Coke] I can volunteer to clean up roast if you have a branch for that change. 17:16
(where clean up == make those error checks partial matches instead of exact)
17:44 CaCode joined 17:55 squashable6 left 17:57 squashable6 joined 18:02 reportable6 left 18:05 reportable6 joined
nine I may have gotten a little grumpy earlier due to the numerous road blocks. Luckily that was nothing a few more passing tests and indian cuisine can't fix :) 18:22
[Coke] I'm also happy to buy any core developers a curry whenever they need it. :) 19:08
19:12 TempIRCLogger left, Geth left
bartolin just for the record (since Geth the loggers seem to be away): I unfudged one test for the JVM backend: github.com/Raku/roast/commit/3dfb6eb044 19:38
Nicholas \o/ 19:39
good *, JVM
bartolin oops, wrong channel! but good *, MoarVM 19:40
20:59 discord-raku-bot left 21:00 discord-raku-bot joined 21:14 nebuchadnezzar left
nine .tell jnthnwrthngtn I'm trying to fix our handling of unsigneds (mostly in arrays). So far 20 files changed, 508 insertions(+), 188 deletions(-) in MoarVM, 13 files changed, 1249 insertions(+), 264 deletions(-) in rakudo. New uint box type, several new ops, enough trickery to avoid runtime cost. 21:42
tellable6 nine, I'll pass your message to jnthnwrthngtn
nine .tell jnthnwrthngtn I wonder: am I actually on the right track? So far we've coped by mostly ignoring the signed/unsigned distinction, just like a hardware CPU does. The only difference to the VM is that we're trying to throw appropriate errors for overruns. Is all the added complexity and volume worth that? Or should we maybe push those boundary checks to HLL instead? 21:43
tellable6 nine, I'll pass your message to jnthnwrthngtn
MasterDuke nine: by "push boundary checks to HLL" do you mean in something like AT-POS? 21:53
22:08 RakuIRCLogger left, Geth joined, RakuIRCLogger joined 22:10 TempIRCLogger joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!