github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:00 MasterDuke joined, MasterDuke left, MasterDuke joined 01:06 sena_kun left 02:25 BeaconAlumna left 03:42 Kaiepi left 03:46 Kaiepi joined 03:58 Kaiepi left 04:04 Kaiepi joined 04:38 Woodi joined 04:58 Kaiepi left 04:59 Kaiepi joined 05:11 Kaiepi left 05:17 Kaiepi joined 05:23 Kaiepi left, Kaiepi joined 06:11 Kaiepi left 06:21 Kaiepi joined 06:22 domidumont joined 07:07 patrickb joined 07:57 zakharyas joined 07:58 Kaiepi left 08:01 Kaiepi joined 08:08 sena_kun joined 08:18 brrt joined 08:27 Kaiepi left 08:28 Kaiepi joined 09:01 zakharyas left
jnthn o/ 09:16
timotimo \o
i'll reboot my machine after having installed what seems like a few months worth of updates
and we're back 09:20
jnthn :) 09:21
I can replicate the "tests are alright without the JIT" here on my office machine too. Hmm.
ooh, the plot thickens 09:23
Think it's OK with the expression JIT disabled too
timotimo so the exprjit is missing some update for recent changes perhaps? 09:24
jnthn ooh, I *did* an expr jit change
I musta screwed it up
(template: sp_p6oget_o 09:25
- (let: (($val (load (add (^p6obody $1) $2) ptr_sz)))
- (if (nz $val)
- $val
- (^vmnull))))
+ (load (add (^p6obody $1) $2) ptr_sz))
Basically, wanted to remove the null check
timotimo i mean it doesn't look wrong to me 09:26
jnthn Trying with that reverted
ah, still failures 09:27
That was the only expression JIT change in my branch 09:28
timotimo odd. perhaps there's some assumption somewhere else that's now being violated 09:29
you can try the jit bisecting tool
jnthn Yeah, feels like it
jnthn waits for the bisect tool's verdict :) 09:47
OK, it found it (apparently), what output do I get? 09:50
09:51 brrt left
jnthn ah, there's a file wiht the frame/bb number :) 09:51
timotimo if i remember correctly it also gives you a diff between the jit versions? or maybe you have to objdump and diff it yourself? it's been quite a while 09:53
09:54 domidumont left
jnthn Not sure, and I'm a tad dubious about the results, since I think maybe the test is affected by hash randomization 09:54
timotimo ah damn 09:55
we don't happen to have a way to turn hash randomization off at build time?
jnthn Not a good one, I don't think 09:56
I can hack it in though
OK, it came out the same anyway 10:04
grrr, I really don't get what's going on here :S 10:14
You'd think disabling expr jit templates to cut out more of the block that's broken would help, but it doesn't at all
timotimo we could try waiting for brrt
jnthn Yeah, I think I'll see if brrt++ can help 10:15
And in the meantime just disable expr jit for running tests :)
timotimo aye
jnthn What I want to do next is rebase my more-pea onto this branch
timotimo in the future: write a confprog that turns off expr jit for just that one frame that's broken ;) ;)
oh yes!
jnthn And see if things work as nicely as I hope
I may first rebase this branch on master, though 10:16
timotimo good call
jnthn oh, it's already up to date
oh, it's the Rakudo one that isn't, OK :)
10:16 Kaiepi left
Geth MoarVM/more-pea: 47 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/6...a889604707		 10:25
MoarVM/more-pea: f558d3dd2a | (Jonathan Worthington)++ | src/spesh/pea.c
Recognize sp_bind_o_nowb in PEA
 10:26
MoarVM: Kaiepi++ created pull request #1114:
Implement freemem and totalmem ops		 10:39
10:40 Kaiepi joined 11:36 Kaiepi left 11:37 Kaiepi joined 11:39 domidumont joined 11:45 Kaiepi left 11:50 ggoebel left 11:51 Kaiepi joined 11:59 Kaiepi left 12:00 Kaiepi joined 12:28 BinGOs left, BinGOs joined
Geth MoarVM/p6o-setup: 4fddd3a298 | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c
Set facts on generated object registers

To improve the optimizations that can then be performed on them.		 12:35
MoarVM/p6o-setup: a700e01c15 | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c
Re-use spesh slots in P6opaque opts

None of these need a distinctive slot of their own. Avoids quite a lot of duplicate slots.
MoarVM/p6o-setup: be9811cb99 | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c
Don't emit setup for vivify-on-access attributes
jnthn Turns out more-pea was missing some rather important facts :)
timotimo adding facts seems really easy to miss :) 12:37
12:37 Kaiepi left 12:38 Kaypie joined 12:39 Kaypie left 12:40 Kaypie joined
Geth MoarVM/more-pea: 48 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/f...26992e087d		 12:45
jnthn Another rebase, to get the facts
Now it explodes very loudly because...when I put in materialization I didn't check for if any of the attributes were also objects that need materialization :) 12:46
Which was on my todo list, I just didn't have an example that reproduced it
13:01 brrt joined
brrt \o 13:01
jnthn: can haz JITbug? 13:02
jnthn brrt: Yes; you need the p6o-setup branches in MoarVM and Rakudo. Spectest with MVM_SPESH_BLOCKING=1 (and perhaps with a small nursery to provoke more crashes). 13:04
There's crashes, and they vanish with MVM_JIT_EXPR_DISABLE=1
It looks like use of outdated pointer or missing wb 13:05
brrt hmmm
Ok, I'll build and see what happens
jnthn Ah, and moar with --debug to get assertions checked, since it's often triggering an assertion failure 13:06
brrt virtually always compiles moar with --debug
I have no idea how fast moar really is :-p
jnthn Well, if it were fast enough already we'd not be doing all this work ;) 13:08
brrt If it was fast enough, we'd still have bugs to fix :-P 13:13
have I told the plan of the linear IR refactor already? 13:14
timotimo i've seen a post about it on the tpf blog
brrt yes, that thing 13:15
:o I can't configure NQP?
"Can't locate object method "note" via package "NQP::Config::NQP" at /home/bart/Code/nqp/tools/lib/NQP/Config/NQP.pm line 35." 13:16
jnthn git submoduloe update? 13:17
Kaypie ^ this on nqp and rakudo 13:38
then make distclean and ./Configure.pl again 13:39
oh i'm late
13:43 AlexDaniel joined
Geth MoarVM/more-pea: 87d0e6fe28 | (Jonathan Worthington)++ | src/spesh/pea.c
Materialize implicated objects

When we have an object that we materialize, it may have attributes that are also objects we need to materialize. Do that.		 13:45
jnthn Darn, still segv... 13:46
Grr, what on earth has it done.. 13:53
Hm, maybe lost an alias while eliminating a guard. 14:02
timotimo because the guard was from rx to ry? 14:06
brrt oh, that's the thing 14:14
Geth MoarVM/more-pea: 9ba8e10733 | (Jonathan Worthington)++ | src/spesh/pea.c
Track aliasing by a settified guard
 14:25
jnthn Darn, and now it's correct it doesn't successfully deal with the scalar containers... 14:26
PEA: considering frame 'new' (348) 14:27
PEA: replacement of Scalar impossible due to PHI
timotimo ;( 14:28
jnthn Huh, the PHI is due to an introduced frame handler coming out of nowhere o.O 14:34
oh, there's the inline boundary marker, hmm 14:36
m: say 2147483648.base(2) 14:46
camelia 10000000000000000000000000000000
jnthn m: say 2147483648.base(2).chars
camelia 32
timotimo is that how much faster some code got? :) :) 14:59
jnthn No, just checking it really works as a bit mask :P 15:00
timotimo ah
jnthn Tssk, so the PHI that it grumbles about doesn't even exist by the final output; 15:01
Tssk, so the PHI that it grumbles about doesn't even exist by the final output
oops, up key + edit isn't an IRC thing :P
timotimo :) 15:02
Geth MoarVM/more-pea: 5a2151a431 | (Jonathan Worthington)++ | src/spesh/optimize.c
Eliminate dead instructions before PEA

Since otherwise we can end up with dead PHIs and other things that cause PEA to bail out.		 15:14
MoarVM/more-pea: c01456cd92 | (Jonathan Worthington)++ | src/spesh/pea.c
Report register blocking PEA
jnthn Ah, back to segv :P 15:15
15:17 brrt left
dogbert17 jnthn: are you working on two MoarVM branches at the same time or have you merged them? 15:32
timotimo i believe more-pea was rebased on top of p6o-setup maybe? 15:34
Geth MoarVM/more-pea: 432b05334b | (Jonathan Worthington)++ | src/spesh/pea.c
When guard is on eliminated allocation, delete it

Instead of turning it into a zombie `set`.
jnthn dogbert17: p6o-setup is probably an expr jit bug away from mergability, whereas more-pea is quite a bit further off :)
OK, hurrah, finally, it eliminates the scalar allocations in the Point object 15:35
dogbert17 that sounds very promising 15:38
jnthn Well, both eliminates them and doesn't explode :) 15:39
So now in the point benchmark, per iteration, it elimiantes the Point object itself, both Scalar containers of its attributes, the Hash wrapper (but not the VM-level hash inside of it) and two intermediate Int objects 15:45
Spectest is very explosive, alas.
dogbert17 BOOM 15:46
jnthn Ah, actually not so awful 15:48
16:18 Kaypie is now known as Kaiepi
jnthn Hm, I guess the EA can do everything that box/unbox pair elimination can do, and having that in a post-inline pass after PEA also means PEA doesn't get to see decompositions that it would work with 16:20
So probably that logic can go away
Bit of a refactor though...bit tired to dig into that right now 16:27
Geth MoarVM/more-pea: 4c41ad121c | (Jonathan Worthington)++ | src/spesh/pea.c
Correct a comment; sena_kun++
 16:28
dogbert17 jnthn: perhaps it's time for a cold beverage? 16:30
16:31 patrickb left
jnthn This is odd...Think so :) 16:31
Ah, I see what it's doing 16:32
But yeah, later
Cool... 16:43
Silly complex number program: my $total-re = 0; for ^10_000_000 { my $x = 5 + 2i; my $y = 10 + 3i; my $z = $x * $x + $y; $total-re = $total-re + $z.re }
3.2s without PEA
0.81s with PEA 16:44
m: say 0.81 / 3.2
camelia 0.253125
jnthn And it doesn't seem to be dealing with Num allocations yet, so there's more to win
oh, no, I guess complex uses native num :) 16:45
So not
But it eliminates all 3 scalars in the loop ($xy, $y, $z), two Complex allocations, and gets rid of 5 guards. 16:47
sena_kun gist.github.com/Altai-man/307a095d...8a243bd8af <- is it a correct transcription? 16:50
ah, nope
fixed an operator 16:51
cannot run the perl6 version to compare times though. :P 16:52
m: say 3.12 / 8.54 16:53
camelia 0.36534
jnthn sena_kun: Yes, that looks right
sena_kun even on 2019.03 perl 6 is faster for me, though, 3~ seconds vs 8.5.
jnthn I tried a Perl 5 one but it's still running...I musta got something wrong in this 16:54
Huh, just 100,000 iterations takes 6.35s 16:55
sena_kun in 5?
jnthn Yes 16:56
sena_kun ooc, can you run py gist above on your machine?
jnthn use Math::Complex; my $total_re = 0; for (1..100_000) { my $x = 5 + 2*i; my $y = 10 + 3*i; my $z = $x * $x + $y; $total_re = $total_re + $z->Re }; say $total_re
6.36s here 16:57
m: say 0.81 / 6.36 16:58
camelia 0.127358
jnthn m: say 6.36 / 0.81
camelia 7.851852
sena_kun this is a win. :) 16:59
jnthn I guess Python is a more fair thing to compare against than Perl 5, given it's built in rather than a module.
Ah, the python one actually is 5.71s if you transcribe it a tad better 17:03
Can do x = complex(5, 2)
Ruby has them built in too, and it clocks in at 7.69s 17:04
sena_kun still not beats a 3.12 on vanilla 03.
jnthn Indeed, I wasn't expecting that 17:05
Found a faster way to write it in Perl 5, which gets it down to 2.1s for the 100,000 iterations 17:09
3m27s for the ten million iterations 17:13
dinner & 17:18
17:29 robertle joined 17:31 patrickb joined 17:33 brrt joined 18:18 Kaiepi left, Kaiepi joined 18:20 domidumont left 18:24 MasterDuke left 18:29 MasterDuke joined, MasterDuke left, MasterDuke joined
timotimo wow 18:33
MasterDuke timotimo: any opinion on github.com/MoarVM/MoarVM/pull/1111 ? ok as is? if so, wait until after the next release to merge? 19:04
19:08 squashable6 left 19:11 squashable6 joined
timotimo i'm not actually sure if the results are totally correct 19:16
i mean i don't see why the code would be wrong, either. not that i have spent a lot of time looking at it
19:17 brrt left
MasterDuke i haven't found out a good way to do any sort of deterministic before/after comparison 19:18
timotimo yeah :(
20:11 robertle left 20:25 brrt joined
brrt jnthn: haven't had the chance to debug it yet 20:28
jnthn brrt: No worries, it may well be smart to merge that after this month's release anyway :) So if it takes some days to get around to it, no worries. 20:34
21:33 AlexDaniel left 21:44 AlexDaniel joined 22:11 brrt left 22:21 AlexDaniel left 22:39 patrickb left 23:57 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!