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:06 linkable6 joined 01:04 reportable6 joined 02:04 reportable6 left, linkable6 left, evalable6 left 02:05 linkable6 joined 02:07 reportable6 joined 03:06 evalable6 joined 05:20 nebuchadnezzar joined 06:02 reportable6 left 06:03 reportable6 joined
nine timo: so far I've stayed away from Junctions, so I guess I'd have to catch up a lot to be of help 07:21
Does autothreading of junctions actually involve threads? So far I've not found anything conclusive 07:22
lizmat autothreading of junctions does **not** involve threading afaik 08:18
08:20 linkable6 left, evalable6 left 08:21 linkable6 joined
nine From a bird's eye view, the point of the new-disp architecture is to remove genericness, polymorphism and the like as much as possible by determining the result of the generic mechanism once, remember the result and collecting the set of conditions that must hold for that result to be valid in the future. 09:05
So the next time, we're at the same point, we just have to check those conditions and jump right to the previous conclusion if they still hol.d 09:06
Junction autothreading (as far as I understand it now) on the outset sounds very dispatchy. After all it is about calling routines. I do wonder however what the genericity is that we can remove with the "facts" we gather at runtime? 09:08
In a call like foo($a|$b|$c) we will always have to run foo with $a, $b and $c in turn and collect the results into a new Junction object, won't we? 09:10
lizmat yes 09:16
nine: yes
the only "complication" is that we have the *option* to actually run this in *any* order and over multiple threads 09:17
I'd say we start out without using that option (which is how it works today)
nine Incidentally that is actually where new-disp might be able to help. The whole "does it pay off to actually use multiple threads in this case?" question can only really be answered at runtime. 09:18
lizmat yup
but for this to really work, we need the capability of finding out how much CPU was used from time X to time Y *in the current thread* 09:19
nine Not sure about that. Wallclock time may be just as good or even better. What if the execution is not that CPU intensive, but needs to wait for IO? In that case parallelization is just as important. 09:20
Number of work items and time to finish one of them can be determined at runtime. And at least the number of items can be guarded. 09:21
And presumably the time is strongly correlated with the code we're running. So we can assume it to be constant.
lizmat hmmmm.... 09:22
nine In case a reader is wondering: what's the point of doing the check for how many elements in a dispatch guard instead of some classic autothread handling code? It's the same check isn't it? 09:25
But a dispatcher's result is the code to call. And with dispatchers this code can e.g. be inlined. Which is especially important if the code we're calling is kinda trivial (which it often will be). 09:26
Like `if $a | $b | $c > 3 { ... }` 09:27
lizmat fwiw, it would allow the static optimization of $foo == 1|2|3 to be removed
which would result in faster compilation times
nine Well, that may still have a place 09:28
09:57 linkable6 left 10:59 linkable6 joined 11:16 frost joined 11:22 evalable6 joined 12:02 reportable6 left
timo one important thing about junctions is that currently we have to rely on the binder to fail and then reevaluating to get the details right 12:06
lizmat ahhh.. the PositionalBindFailover stuff ? 12:07
timo not quite
that one is for when we put a seq where a Positional is required and we implicitly listify it for the user
but i have also not looked at how that is handled in new-disp right no 12:08
maybe that one is a lot more common than junction autothreading
12:43 frost left 12:48 squashable6 left 12:51 squashable6 joined 14:05 reportable6 joined 15:05 linkable6 left, evalable6 left, linkable6 joined 15:07 evalable6 joined 15:49 dogbert17 joined
dogbert17 hmm, suddenly I'm unable to build new-disp. Building rakudo ends with a bang. 15:49
Stage start : 0.000
Internal error: inconsistent bind result
at gen/moar/BOOTSTRAP/v6c.nqp:3958 (/home/dogbert/repos/rakudo/blib/Perl6/BOOTSTRAP/v6c.moarvm:)
Geth MoarVM/new-disp: 61b5f03b55 | (Stefan Seifert)++ | src/disp/boot.c
Give lang-hllize dispatcher an optional argument for language name

This makes lang-hllize suitable as a replacement for the nqp::hllizefor op.		 15:50
nine is covering his tracks...
dogbert17 perhaps I should try again ... 15:51
nine All 3 repos up to date as of...now? 15:53
dogbert17 I thinks so, trying a rebuild now ... 15:55
NQP has been built and installed. 15:56
Using /home/dogbert/repos/rakudo/install/bin/nqp-m (version 2021.07-93-gcb7404823 / MoarVM 2021.07-406-g61b5f03b5).
I hope those are the correct ones
nine looks good 15:57
dogbert17 :( I must be doing something wrong here 16:00
same error
nine I just force-pushed an amended commit in rakudo 16:02
But that probably won't fix your issue
dogbert17 aha 16:07
nine ? 16:08
dogbert17 if I'm the only one having this problem then I guess that I'm doing something wrong
nine Well....it works for me so there's just about 8 billion other people to check before we know you're the only one :D 16:09
dogbert17 I aha'ed your comment 'But that probably won't fix your issue'
but it seems to be working ... it's parsing
+++ Rakudo installed succesfully! nine++ 16:11
nine I don't think my fixed commit really did it. I'd guess it was some build artefact in the way or something like that 16:12
But whatever it was...good that you're up and running again :)
dogbert17 I saw that you were adding stuff some tough testing might be in order :) 16:14
s/some/so some/ 16:15
nine Feel free :) I certainly managed to do many more mistakes than I anticipated.
17:25 squashable6 left 17:39 squashable6 joined 17:56 squashable6 left 17:59 squashable6 joined 18:02 reportable6 left 19:16 evalable6 left, linkable6 left 19:18 linkable6 joined
dogbert17 I don't believe it, I actually found something 20:08
MoarVM oops: MVM_str_hash_entry_size called with a stale hashtable pointer
at gen/moar/Metamodel.nqp:2706 (/home/dogbert/repos/rakudo/blib/Perl6/Metamodel.moarvm:!rebuild_table)
from gen/moar/Metamodel.nqp:2714 (/home/dogbert/repos/rakudo/blib/Perl6/Metamodel.moarvm:concretization_lookup)
was running 'while ./rakudo-m -Ilib t/spec/S17-promise/start.t; do :; done' with new-disp, MVM_GC_DEBUG=1 and a 16k nursery 20:10
the culprit, at least the two times this has happened, is test #50 20:12
lizmat fwiw, that test is a common flapper for me on master
so this may not be related to new-disp
dogbert17 that's interesting
github.com/Raku/roast/blob/master/...art.t#L151 20:15
21:02 linkable6 left 21:04 linkable6 joined 22:25 linkable6 left 22:27 linkable6 joined 23:17 evalable6 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!