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:03 reportable6 left 00:41 squashable6 left 00:42 squashable6 joined 01:04 reportable6 joined
[Coke] with jnthnwrthngtn's suggested 'dd' addition to the SEEN, action, we get: 01:20
Array @*SEEN = []
0
There is a *lot* going on here, might be easiest to get dwarring involved to golf. 01:33
in html::canvas, there is a lot of 'self!call(...' - there is no method 'call' in the class or its parent. How does this work? 01:46
... dammit. :) 01:47
there is a method !call, but of course I was searching for 'method call' or somesuch.
02:04 linkable6 left, evalable6 left 02:06 evalable6 joined 02:07 linkable6 joined 02:43 frost joined 03:43 linkable6 left, evalable6 left 03:44 linkable6 joined, evalable6 joined 04:54 frost left
Nicholas good *, #moarvm 06:01
06:02 reportable6 left 06:03 reportable6 joined
Nicholas major coffee bootstrapping crisis - where is the lid to the Aeropress? 06:32
finally found it - it had fallen into the dishwasher and was hiding in the shadows and confusing shapes below the lower level
nine Nicholas: how did you solve that before coffee?? 06:46
Nicholas yes, this is the problem 06:47
some level of cheating (in a jar)
also, "brute force search"
not that effect a search, as this was the second pass of the dishwasher 06:48
effective
07:03 linkable6 left, evalable6 left 07:04 linkable6 joined 07:44 brrt joined
Nicholas good *, brrt 07:51
brrt: you might easily know the answer to colabti.org/irclogger/irclogger_lo...09-27#l399 07:52
nine MasterDuke: we don't use r12-r15 precisely because they are callee saved and our standard prologue does not save them! So if you want to use them, you have to manually save them to the stack. So far we've been able to avoid that cost. 08:02
Of course if despite having to save and restore those registers, you get fewer memory accesses by using them, by all means please do so. 08:04
Nicholas I liked the trick described in that speed limit doc of spilling into MMX regsters 08:05
08:05 evalable6 joined
Nicholas (I think I have described this correctly) 08:05
nine Sounds like I need to continue reading that then :)
MasterDuke nine: but is it safe to refer back to `WORK[sc]` after a call? e.g., `mov ARG2, WORK[sc]; call &some_thing; mov ARG2, WORK[sc]; call &another_thing;` 08:07
nine MasterDuke: err...yes, because WORK is in a callee saved register 08:08
MasterDuke good, i was interpreting something correctly then
nine So it's actually r12 and r15 that we don't use
not r12-r15
08:09 frost joined 08:10 frost left
MasterDuke heh. `MoarVM panic: Memory allocation failed; could not allocate 103079215120 bytes`, i did something wrong... 08:11
`Cannot find method 'stages' on object of type NQPRoutine`, i'm on a roll... 08:12
nine Totally random and unhelpful error messages aka "the joy of working low-level"
08:16 brrt left 08:17 brrt joined
brrt \o 08:17
08:18 frost joined
brrt Nicholas, MasterDuke: the answer is that I map a few common variables to callee-save registers 08:18
like, the thread context; I think in the past, the compilation unit, the VM register offset base 08:19
if you use a callee-save register, note that you have to stash and restore them in the pro- and epilogue, so they make that particular piece of code larger
mind also, that if you use 'push' and 'pop', you'll change the location where, in a 'call', we'll place the return address, and we rely on that in a few places 08:20
MasterDuke i just got around explicitly having to use them by just referring back to WORK[foo] a couple times 08:21
brrt :-)
that works
MasterDuke gist.github.com/MasterDuke17/7925f...8c9e7e089e are the two working versions. how do people vote? 08:24
nine How do they do on performance? 08:29
MasterDuke haven't tested that yet 08:32
brrt immeasurable probably :-P
MasterDuke i didn't notice any difference in a rakudo build or a spectest. but then again, i've a bunch of ops jitted on this branch now and haven't noticed anything, these likely aren't very hot if they haven't been jitted already 08:34
i'm really just hoping for the accumulation of marginal gains here, doubt we'll see much directly as a results of these 08:35
08:49 frost63 joined 08:52 frost left, frost63 left
jnthnwrthngtn moarning o/ 09:23
Nicholas \o 09:24
brrt moarning jnthnwrthngtn 09:36
jnthnwrthngtn o/ brrt
Nicholas I have LTA news. zef goes SEGV on new-disp with MVM_SPESH_NODELAY=1 09:49
This is a regression from master
#0 0x00007ffff74598f0 in MVM_interp_run (tc=0x555555758d90, initial_invoke=0x7ffff75c4f05 <toplevel_initial_invoke>, invoke_data=0x5555558542f0, outer_runloop=0x0) at src/core/interp.c:5554 09:50
#1 0x00007ffff75c505f in MVM_vm_run_file (instance=0x555555758210, filename=0x5555557581b0 "/home/nick/Sandpit/moar-g/share/perl6/runtime/perl6.moarvm") at src/moar.c:505
#2 0x0000555555555cc0 in main (argc=6, argv=0x7fffffffe958) at src/vm/moar/runner/main.c:474
(gdb) p check
$1 = (MVMObject *) 0x0
this is not that much to go on.
nine Nicholas: what exactly does it take to reproduce? 09:54
Nicholas that was
gdb --args /home/nick/Sandpit/moar-g/bin/rakudo -I. bin/zef --force-install install .
in a git clone of zef
(only needs the --force-install because I'm trying to repeat it after having it work out OK with master) 09:55
nine MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1?
Nicholas I have sll og MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 MVM_SPESH_CHECK_DU=1 dry
gah
all of MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 MVM_SPESH_CHECK_DU=1 set
ooh, but a clean source checkout (so none of the debug macro changeS) 09:56
nine Gah...my rr is broken: Assertion `false' failed to hold. Unhandled ptrace event PTRACE_EVENT_CLONE(3) 09:59
And compiling a newer version fails with: at_threadexit.c:13:3: error: ‘pthread_setspecific’ expecting 1 byte in a region of size 0 [-Werror=stringop-overread]
Nicholas remove glasses before banging head on desk 10:00
rr on the machine I built this on hits an assertion
I have 2 more I can try on
nine Simple solution for rr: ccmake and disable building of tests 10:03
Nicholas implied from this is that you can replicate the SEGV? 10:05
nine Indeed! Though actually rr is not that helpful anyway. call MVM_dump_bytecode(tc) reveals the nature of the problem: 10:07
gist.github.com/niner/aaa91435d6f7...7beaf41f63 we're at line 00043, reading loc_101_obj, which hasn't been initialized to anything
jnthnwrthngtn Based on [Coke]++'s investigation I tried to get a repro of the HTML::Canvas issue in terms of just CSS::Properties; alas, no luck 10:10
nine: Uhh...that dump looks full of it 10:11
Ohh 10:12
Look around line 6
The bytecode dumper doesn't understand sp_resumption
That said, the part in question looks about right
(As in, correctly disassembled) 10:13
Hm, the DU chain checker is meant to make things like this "impossible" if it doesn't complain
Nicholas: Is MVM_SPESH_CHECK_DU really an env var? I thought that had to be set in a header 10:14
Nicholas jnthnwrthngtn: it seems that you are correct. 10:15
nine jnthnwrthngtn: ah, right. I can teach the bytecode dumper 10:16
jnthnwrthngtn: thanks for the explaining comments in oplist :)
jnthnwrthngtn OK, so maybe the DU checker wasn't actually enabled? 10:17
Nicholas indeed not
jnthnwrthngtn Ah. Worth a try wiht it.
This looks like exactly the kind of bug it'd catch
OK, good news on HTML::Canvas: turns out if I just install all the deps without running their tests, I can actually repro the bug 10:19
No doubt thanks to [Coke]++ golfing things down
Nicholas \o/
10:28 frost joined
jnthnwrthngtn Missing guard. 10:32
heh, turns out that HTML::Canvas will even pass its tests with missing native deps :) 10:39
Will spectest and push the fix
10:41 ggoebel_ left
Nicholas jnthnwrthngtn: correctly building with `+#define MVM_SPESH_CHECK_DU 1` doesn't change my zef SEGV :-( 10:45
jnthnwrthngtn Darn 10:46
I can repro the segv here, fwiw 10:47
OK, HTML::Canvas fix pushed, wiki page updated
Geth MoarVM/new-disp: 5435cd8136 | (Stefan Seifert)++ | 4 files
Teach the bytecode dumper about sp_resumption

sp_resumption also has a variable number of arguments, so it needs special handling.		 10:56
nine Updated my gist with the correct dump output
sena_kun jnthnwrthngtn++ 10:57
jnthnwrthngtn nine, Nicholas Try it with MVM_SPESH_PEA_DISABLE=1 10:59
nine jnthnwrthngtn: works just fine
jnthnwrthngtn Inlining disabled would hide it too, by not allowing the opportunity for a scalar replacement 11:01
11:02 ggoebel_ joined
jnthnwrthngtn sp_fastcreate r5(9), liti16(48), sslot(16) 11:02
[Annotation: INS Deopt Inline (idx 18 -> pc 414; line 17)]
sp_bind_o r5(9), liti16(40), r0(1)
sp_p6oget_o r16(1), r5(9), liti16(8)
[Annotation: INS Deopt One Before Instruction (idx 17 -> pc 402; line 17)]
sp_guardjusttype r16(2), r16(1), litui32(17)
set r6(1), r5(9)
return_o r6(1)
This is the end of the specialization of `item`, which we inline. The fastcreate escapes pre-inline, but doesn't post-inline 11:03
It's a curiosity that it realizes that it can get away with sp_bind_o but, an instruction later, takes the slightly slower sp_p60get_o 11:05
(Assumes non-mixin vs. maybe mixin type)
So we're maybe missing an opportunity there
I'm pretty sure it's reading a different attribute than it's writing there, though. 11:06
Ah, I can even guess what this is 11:07
The fastcreate will be creating a readonly Scalar container wrapping the return value because it's Iterable
The get will be reading the descriptor, which is null, which means the scalar is readonly, and guarding on that 11:08
Anyway, the problem is that we have a read of an attribute that's never initialized, and scalar replacement fails to insert a null op to make sure the register in question is properly nulled out 11:09
Lunch; if nobody beats me to it, I'll fix up the scalar replacement afterwards 11:12
11:13 squashable6 left 11:16 squashable6 joined
nine I think I beat you....to lunch ;) 11:27
[Coke] Nicholas: coffee bootstrap... maybe keep an emergency Foldgers or k-cup. 11:36
jnthnwrthngtn++ # so glad I didn't have to figure out more guts of H::C 11:38
[Coke] belatedly remembers generic Foldgers is "Instant" coffee. 11:39
11:48 ggoebel_ left 11:50 brrt left
lizmat OOC, isn't that Folgers ? 11:52
[Coke] ... english consontants are weird. Yes, you're right, of course. 11:54
... consonants!
12:02 reportable6 left 12:05 reportable6 joined 12:08 brrt joined
jnthnwrthngtn back 12:08
brrt back, too 12:09
jnthnwrthngtn I see no commits. Guess it's pea time...
12:14 ggoebel_ joined
[Coke] jnthnwrthngtn: so how did you diagnose the H::C issue? 12:29
jnthnwrthngtn [Coke]: Once I reproduced it, added some logging of descriptor and other bits just before it reported the type check error 12:36
[Coke]: But I was already getting a bit suspicious it was going to be about the scalar assignment dispatch program, because it was doing ++ on an array element but was using an implementation that doesn't expect auto-viv, but the postfix:<++> candidate it was in is precisely one that does auto-viv 12:38
(I didn't quite realize this last night when looking at it, but spotted it when looking at it afresh this morning.) 12:39
Nicholas, nine: I think I have a patch for the scalar replacement bug afflicting zef. In fact, the more-pea work that I should return to sometime soon also attacks this issue in a more involved way. 12:41
But I'll do a much simpler solution for now
NQP builds/tests fine (with nodelay and blocking), currently doing Rakudo and spectest 12:42
nine jnthnwrthngtn: sounds good :) 12:43
And interesting to know that there's more-pea in the works :) 12:44
12:45 frost left
jnthnwrthngtn It pre-dates new-disp, but I think it's time to dust it off 12:54
Nicholas new-disp hasn't shipped yet :-) 12:55
12:56 brrt left
jnthnwrthngtn I didn't mean "today" :-) 12:58
nine ah, tomorrow then :D 12:59
Geth MoarVM/new-disp: 72abab6ae8 | (Jonathan Worthington)++ | src/spesh/pea.c
Don't read unwritten registers after SR

Sometimes when we perform scalar replacement, we encounter a read of an attribute prior to a write of the attribute. In such a case, we should not emit a read of an unwritten register, but instead "read" the correct default value for the attribute type in question.		 13:00
jnthnwrthngtn I think we're at the point of not having merge blockers any longer. 13:02
I know there's some discussion about if we should merge or if we should somehow conflate this with a main branch name switch. 13:03
Nicholas rebase! "minitrue" the two commit-revert pairs in nqp
jnthnwrthngtn Yes, rebase is the obvious next step
Nicholas is it worthwhile taking out all the NQP-version bump commits? (I appreciate that this is work, although I think that git filter-branch can do it, or rebase -i) 13:04
As the commit hashes "don't exist" any more.
nine jnthnwrthngtn: thanks to the patch I now understand what you meant exactly :)
jnthnwrthngtn I think we perhaps want to merge and then separately do the branch name change; iiuc, github will re-target PRs and so forth, whereas if we just say "new-disp is main now", I don't think that would happen?
Nicholas I don't know (for sure) but I think that decoupling the two seems safer 13:05
jnthnwrthngtn Yeah, to me also.
nine safe++
lizmat safe++ indeed 13:06
jnthnwrthngtn If Rakudo is doing the name change we should do it in MoarVM and NQP too; it's bad enough for the muscle memory without them being inconsistent :)
Nicholas I liked nom ;-)
jnthnwrthngtn Me too, but some people want everything boring :P
nine Nicholas: in hindsight, we could have skipped the nom -> master switch, yes :) 13:07
jnthnwrthngtn Anyway, if it doesn't disrupt anyone, I'll work on the rebases now?
nine fine with me
Nicholas go for it 13:08
(or drink tea first?)
jnthnwrthngtn OK, I don't see any reverts in the MoarVM commit history, so don't think there's any obvious "fix in post" here 13:10
Nicholas nqp had 2, unsure about rakudo 13:11
2 pairs that I could spot
jnthnwrthngtn Conveniently, the MoarVM version bumps in NQP all conflicted during the rebase, so I could just skip them as I went :) 13:14
Nicholas lazyness for the win 13:15
jnthnwrthngtn Also dropped those 2 commit/revert pairs
Dropped the bumps in Rakudo too, don't see any reverts to tidy up 13:19
Building everything, then will push, along with version bumps in each 13:20
nine Probably going to be the largest push in MoarVM history, isn't it? :) 13:21
jnthnwrthngtn Did the diff stat with master and it says:
171 files changed, 20413 insertions(+), 12157 deletions(-)
I suspect the Unicode database updates might be bigger :P 13:22
nine Use number of commits as the metric ;) 13:23
jnthnwrthngtn 573 for MoarVM :) 13:24
Geth MoarVM/new-disp: 573 commits pushed by 9 authors
review: github.com/MoarVM/MoarVM/compare/7...e9451ff6a0
nine \o/ 13:25
jnthnwrthngtn Just occurred to me that if I push version bumps now, and then we merge, then the merge commit will be between them
Which is probably not idea
OK, the rebases are all pushed. 13:26
Tests are clean
OK, now we just need enough agreement about merging this, I guess. :) 13:29
[Coke] Nicholas: (main separate) makes sense. 13:32
nine Is this an issue? 13:34
t/spec/S06-advanced/dispatching.rakudo.moar (Wstat: 0 Tests: 6 Failed: 0) TODO passed: 1-2
[Coke] I'll do one more windows build.
nine TODO passed: 1-2
jnthnwrthngtn nine: No, I'll unfudge them once we merge 13:35
Nicholas 573 just to unfudge 2 tests? :-)
jnthnwrthngtn nine: It's something new-disp has fixed that was broken on master, so the opposite of a problem :)
Nicholas 573 *commits* just to unfudge 2 tests? :-)
jnthnwrthngtn Nicholas: Many of them were not to have to fudge most of the rest :P 13:36
[Coke] ... we're nothing if not committed?
vrurg There's more passing in dispatching.t. It's just a canary test which signals that time has come to unfudge the rest.
jnthnwrthngtn vrurg: There's more passing, although not yet everything (some callwith issues, which I aim to sort out later this week) 13:37
Although since those were almost certainly busted on master too, I don't think it's a merge blocker 13:38
vrurg Absolutely not. :)
nine Ran nqp and rakudo test and stresstest normally, with spesh blocking and with spesh blocking + nodelay without issue. 13:44
I am GO for launch!
[Coke] nmake install failed on windows just now 13:54
gist.github.com/coke/7cc6dede0664d...6eb514d1cd - it's actually during the install 13:55
on this command: "C:\sandbox\rakudo-disp\rakudo-m.exe" --ll-exception "C:\sandbox\rakudo-disp\tools\build\install-core-dist.raku" "C:\sandbox\rakudo-disp\install\share\perl6\core" 14:00
jnthnwrthngtn That error seems to lack an actual error :S 14:01
nine error: no error
[Coke] I am in my previous checkout. removed nqp/install dirs, git pull --rebase'd rakudo, ran configure with --gen-nqp=new-disp --gen-moar=new-disp --backends=moar --mmoar-option=--debug 14:02
s/checkout/clone/
I'd like to merge back on a high note, but am confident we can sort this out before release. 14:04
I'll do a git clean and try one more time. 14:06
vrurg nine: BTW, "error: no error" is legit for `throws-like` test family. :) 14:16
[Coke] TIL VERBOSE_BUILD=1 14:19
vrurg [Coke]: if you need it permanent in Makefile do Configure.pl --no-silent-build 14:22
[Coke] still occurs after a git clean 14:28
doing a bisect. 14:30
vrurg thank you - I'll probably just use env var. 14:31
(only want it when something is broken)
is there a rakudo dev tool that manages the 3-repo bisect? 14:34
(looks like it's not rakudo with the issue, it's nqp, so trying to figure out the right bisect here is going to be challenging. :) 14:35
er, nqp or moarvm
14:36 brrt joined
[Coke] added the windows issue to release blocker 14:44
MasterDuke it might be nice to put in some "artificial" bumps for ease of bisecting 14:46
[Coke] ... we could do it after the fact, ooh. 14:49
sneaky
nine For putting in artificial bumps after the fact, you need to figure out which nqp commit to use for which rakudo commit and same with MoarVM and nqp. But if you do that, why not just use this logic directly during the bisect? 14:51
[Coke] could be optional behavior for the bisect: use bumps (default) or bisect all the things. 14:53
huh. I see some windows specific commits in moarvm from jimmy that I don't remember testing..
will be difficult to manually do this bisect, will see if I can go the other route and golf the error on HEAD 15:11
nine You could also do the usual tests: run with --ll-exception, MVM_SPESH_DISABLE=1, etc. 15:22
15:25 brrt left
[Coke] failure is in $REPO.install ... (I moved the creation of the Distribution::Hash first.) 15:28
good call. MVM_SPESH_DISABLE=1 works. 15:29
nine Ok, so maybe you can narrow it down with MVM_SPESH_INLINE_DISABLE, MVM_SPESH_OSR_DISABLE or MVM_SPESH_PEA_DISABLE? 15:30
Does MoarVM's tools/jit-bisect.pl work on Windows? 15:31
[Coke] works with MVM_SPESH_INLINE_DISABLE=1; does that mean I don't have to try the others? 15:32
nine Can still be interesting 15:35
MasterDuke the primitive version of scsetobj seems to be slightly, but measurable faster 15:37
nqp: my $a := nqp::createsc("a"); my int $i := 0; my int $s := nqp::time; while $i++ < 10_000_000 { nqp::scsetobj($a, $i, $i) }; say(nqp::div_n(nqp::time() - $s, 1000000000e0)); say(nqp::scobjcount($a))
camelia 1.704378852
10000001		 15:38
MasterDuke locally i get ~1.35 for the non-jitted at all version, ~1.25 for the function call, and ~1.22 for the primitive
[Coke] works with INLINE disabled, with OSR disabled, or PEA disabled (assume 1 disables and 0/blank enables). only disabled one at a time, but each worked. 15:46
dogbert17 I get this warning from gcc: 15:49
src/spesh/disp.c:406:59: note: expected ‘MVMOpInfo *’ {aka ‘struct MVMOpInfo *’} but argument is of type ‘const MVMOpInfo *’ {aka ‘const struct MVMOpInfo *’}
406 | MVMDispProgram *dp, MVMuint16 res_idx, MVMOpInfo *res_info) {
is it bogus? 15:50
nine [Coke]: I wouldn't bet on that assumption
[Coke]: and I'd have won that bet. There's actually code that was inteded to do the 1/0 distinction, but it's faulty: if (!spesh_osr_disable || !spesh_osr_disable[0]) 15:52
Since spesh_osr_disable is a string, spesh_osr_disable[0] will be an ASCII character. And '0' is 48 which is true 15:53
Oh. Could also be that the !spesh_osr_disable[0] is a poor man's !strlen(spesh_osr_disable), since for a zero-length string, there'd be the \0 in the first char slot 15:59
16:03 ggoebel_ left, ggoebel_ joined 16:14 brrt joined 16:18 ggoebel_ left, ggoebel_ joined 16:25 ggoebel_ left
[Coke] oof 16:27
I could try again with unsets.
16:31 ggoebel_ joined
[Coke] OSR_DISABLE - fails; PEA_DISABLE - fails ; INLINE_DISABLE - fails; SPESH_DISABLE - works. 16:34
that's individually, with set to 1 vs. unset.
nine So it's something rather basic. Have you tried jit-bisect.pl? 16:41
Oh, and MVM_JIT_DISABLE?
The JIT is at least something where the OS matters
[Coke] JIT_DISABLE also works 16:43
jnthnwrthngtn Then it's the JIT. 16:44
If this used to work not long ago, that means only changes under src/jit/ in MoarVM need to explored.
*to be
[Coke] nine: are there docs on using jit-bisect? 16:47
ok, maybe it's doing something now... (perl ...bisect.pl rakudo-m.exe err.raku <arg>) 16:49
if bisect doesn't help i'll try cherry picking reverts of src/jit 16:50
nine [Coke]: What about MVM_JIT_EXPR_DISABLE=1? If that doesn't help, we know it's in the lego JIT. Which further narrows down the candidates 16:55
[Coke] jit-bisect: the program is quite alright 17:03
... crap. presumably because I left JIT_DISABLE on. :P
jnthnwrthngtn dogbert17: I'm putting together a blog post about new-disp, and think you mentioned having some scripts that saw nice speedups; if so, a) any rough numbers, b) may I mention it? 17:20
brrt [Coke]: jit-bisect.pl should probably clear JIT_DISABLE? 17:33
[Coke] ok. 17:35
brrt: yup, looks like.
brrt hmm
it might not work
17:39 linkable6 left, evalable6 left 17:41 evalable6 joined
MasterDuke brrt: any idea why i'm getting the error seen here with that template gist.github.com/MasterDuke17/0fba0...96a170ffa6 ? 17:43
brrt probably not but I can have a quick look 17:44
MasterDuke i get the same error if i stick a `(flagval` after the first `ifv` 17:45
brrt oh, `(ifv (flagval ... )` is wrong
it says:
- wanted flag (boolean result)
- got reg (integer value)
17:45 patrickb joined
brrt flagval converts boolean => integer 17:45
it's not C, it doesn't accept if(1) 17:46
MasterDuke ah
hm, removing it now errors with `Use of uninitialized value $want in string eq at tools/expr-template-compiler.pl line 298, <STDIN> line 1817.`
brrt heh 17:47
MasterDuke oh, does ifv have to have both a 'then' and an 'else'? 17:48
probably should be a `when` 17:49
brrt ehm...
yeah
arguably the template compiler could handle the variants of `if` automatically
MasterDuke using when for the second ifv gives `do: Got void wanted ? at tools/expr-template-compiler.pl line 300, <STDIN> line 1817` 17:50
brrt dov
MasterDuke that's what i have, same error if i switch to do 17:51
brrt oh, it's `let`
i... thought the let expander handled that case
of picking the right one
MasterDuke i don't have to have the let, i could just put (^stable $2) instead of the $st 17:52
but afk for a while
brrt ok... 17:53
.tell MasterDuke it really does have to be `letv:` because I apparently don't handle it by type inference
tellable6 brrt, I'll pass your message to MasterDuke
brrt I suppose type inference was unreliable
dogbert17 jnthnwrthngtn: the best I have seen is master 25s, new-disp 7s 18:02
18:03 reportable6 left
dogbert17 that's a rather small script, i.e. approx 10 lines of code 18:05
another script, not mine, that I use for testing is this, github.com/rakudo/rakudo/issues/1421, which, on my system runs for 10s on new-disp but 15 on master 18:07
[Coke] still dies with MVM_JIT_EXPR_DISABLE set 18:12
dogbert17 in general I've only seen one script which was slower, most are 10-30 percent faster, some even faster. I few shows no measurable difference 18:14
I believe you saw some noticable improvements in Cro and lizmat has seen healthy improvements in test-t 18:21
lizmat yeah, test-t is about 20% faster 18:25
the --race version is maybe 2% slower, probably on account of larger startup time 18:26
18:28 brrt left
dogbert17 I suspect that we'll be able to close a bunch of issues when new-disp is merged 18:50
19:04 reportable6 joined
lizmat this just on #raku: [20:48:31] dwarringHTML::Canvas tests now passing on new-disp 19:04
dogbert17 yay 19:05
19:11 dogbert17 left 19:15 dogbert17 joined
dogbert17 just noticed that harness6 is broken on master and new-disp 19:30
No such method 'd' for invocant of type 'Seq' 19:31
in sub listdir at t/harness6 line 125
lizmat if it's broken on both, that's no blocker :-)
dogbert17 indeed, was trying to test the speed difference between harness5 and 6. Guess I'll have to wait. 19:33
lizmat but a blocker for 2021.10
Nicholas rakudo isn't using GH workflows to do CI testing, is it? Because this sort of stuff could probably be validated (after the commit is pushed) 19:34
19:40 ggoebel_ left 19:42 linkable6 joined 19:46 ggoebel_ joined 20:06 patrickb left 20:07 patrickb joined
nine [Coke]: so it must be one of the commits that touches src/jit/x64/emit.dasc. Should be easy to just revert them individually and see if it fixes anything. They are pretty independent 20:19
[Coke] oh, that narrows it down even more, I was trying everything that touched src/jit. 20:20
danke.
20:34 patrickb left 21:34 linkable6 left, evalable6 left 21:35 linkable6 joined
[Coke] is there a repo for the triple bisect tool we were talking about? 22:00
tempted to write something quick that gets the triple based on 'last commit on day X' 22:01
timo it's not in moarv/tools/ right? 22:02
22:35 linkable6 left, evalable6 joined
MasterDuke . 22:35
tellable6 2021-09-28T17:53:45Z #moarvm <brrt> MasterDuke it really does have to be `letv:` because I apparently don't handle it by type inference
MasterDuke .tell brrt thanks, i'd forgotten there was a letv. that plus a fix for an actual error i'd made elsewhere and it's working 22:36
tellable6 MasterDuke, I'll pass your message to brrt
23:35 linkable6 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!