01:30 deep-book-gk joined, deep-book-gk left 01:52 ilbot3 joined 01:56 stmuk joined 03:24 geekosaur joined 03:25 geekosaur joined 03:29 geekosaur joined 05:46 brrt joined 05:53 GK1wmSU joined 05:54 GK1wmSU left
brrt good * #moarvm 05:57
06:06 _GK1wmSU joined 06:09 _GK1wmSU left 06:42 brrt joined
brrt one advantage of merging this week; i can start working on a stack-walker branch, without woryying about merging it in both 07:17
07:45 zakharyas joined
brrt the dolphin folks have apparently written a JIT: bwiegmans-emkapp.dev.booking.com 08:04
eh
wrong paste
dolphin-emu.org/blog/2017/07/30/ubershaders/
08:18 vendethiel- joined
jnthn Moarning, #moarvm 08:44
brrt moarning jnthn 08:45
08:52 robertle joined
ilmari brrt: they always had the JIT shader compiler, AIUI. they wrote a whole GPU emulator as a shader as well because the JIT latency was unacceptable 09:11
brrt well, that's what makes it a JIT compiler, otherwise it's just a compiler, innit 09:13
:-)
but it is really really cool work nevertheless
09:14 robertle joined
brrt it's completely irrelevant to me since i own a wii and wii u 09:14
but really cool
09:21 vendethiel joined
Geth MoarVM: 68031489de | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c
Spesh matches on exact types, so MI is no problem.

With slots it is because they are unpredictable in the face of subclasses given MI. But when matching on an exact type and getting the offset for it, as spesh does, then it's safe.
09:25
timotimo it's only the jit latency if you consider the code on the gpu to be the target, which i'd claim it isn't 09:49
because it's the gpu driver that takes ages to turn the glsl (or hlsl on directx) into whatever internal machine-code-like stuff the gpu uses 09:51
ilmari they have to JIT the TEV config to glsl first 09:53
timotimo right, but that's probably the faster step; i might have to re-read
hm, looks like you're right, the wording is a tiny bit misunderstandable 09:54
10:01 vendethiel- joined
dogbert17 jnthn: dunno if it ties in with your current work, but of the two MoarVM related bugs found during the weekend, I reported one as a MoarVM issue and the other might have already been solved by timotimo :) 10:06
jnthn This one: github.com/MoarVM/MoarVM/issues/620 ? 10:07
dogbert17 yes, that's the reported one :) 10:09
the other is hidden here, gist.github.com/dogbert17/e23c3340...da3feb18f, but can be turned into a report should you so desire 10:10
jnthn Yeah, that's worth a MoarVM issue also 10:14
dogbert17 jnthn: done github.com/MoarVM/MoarVM/issues/622 10:18
jnthn m: say 220 / 225 10:34
camelia 0.977778?
10:34 vendethiel joined
Geth MoarVM: 682b8c8694 | (Jonathan Worthington)++ | 5 files
Speed up attribute reads during invocation.

By caching the offsets when it's a P6opaque (in reality, it pretty much always is) so we don't have to call get_attribute. Profiling showed that about 3% of CORE.setting instructions during compilation go on the get_attribute calls in these functions; a profile after the change shows a drop of around 5 billion instructions when compiling CORE.setting, or about 2.2%.
10:47
MoarVM: e3c44fc042 | (Jonathan Worthington)++ | src/core/oplist
Document the various op adverbs.
MoarVM: 099764bd92 | (Jonathan Worthington)++ | 3 files
Avoid spesh log function call when not logging.

The static inline does the check quickly, saving the overhead of the function call in the case we aren't doing spesh logging at this point.
11:04
lizmat jnthn: possibly related to this, do you have a clue why "is default()" is not honoured on attributes ? 11:05
jnthn lizmat: No, no idea why that'd be 11:06
lizmat m: class A { has $.a is default(42) }; use nqp; dd nqp::getattr(nqp::create(A),A,q/$!a/)
camelia Any $!a = Any?
lizmat it's happening at a very low level 11:07
m: class A { has $.a is default(42) }; use nqp; dd nqp::getattr(nqp::create(A),A,q/$!a/).VAR.default
camelia 42?
jnthn Probably that it isn't setting the value into the container that then later gets cloned 11:09
Just updating the container descriptor won't suffice
Note that the variable one does an assignment into the container
lizmat I've lost you 11:10
I just wanted to show that the descriptor *is* set up correctly 11:11
jnthn Yes, it is, my point was that this isn't actually very important.
lizmat but something is stoking an Any into it
jnthn Because that's only for introspection by runtime
lizmat I think it's *very* important
jnthn You can think what you want, but I know how it works :P
The mechanism in both cases is that we clone a "prototype" Scalar 11:12
In Variable.pm where the var default trait is, we have this line:
# make sure we start with the default if a scalar
$var = $default if nqp::istype($what, Scalar);
That is not, however, taking place in the is default trait for Attribute 11:13
lizmat hmmmm
ok,
jnthn The question being, how we do it :)
Ah, right
Attribute has a $!auto_viv_container
So we need to make sure it ends up assigned into that 11:14
Ah, and it can be done in the Attribute default trait in traits.pm
lizmat ok, I will take it from there then :-)
jnthn The solution will be something like adding: 11:15
my \cont := $attr.container;
nqp::assign(cont, $defualt) if nqp::istype(cont, Scalar) 11:16
or
my $cont := $attr.container;
$cont = $defualt if nqp::istype(cont, Scalar)
Saves an nqp op and should be equally good code :)
(Saves using one, I mean; it'll generate nqp::assign underneath)
lizmat ack, lemme try :-) 11:17
Geth MoarVM: 9720819b96 | (Jonathan Worthington)++ | src/core/frame.c
Reduce duplication and simplify logic in invoke.

By making the codepaths where we have a specialization already and where we don't have a specialization share most of their code. This also gets rid of the found_spesh flag.
11:20
jnthn Meanwhile, lunch :)
bbiab
nine ssh cmsfrontend-public.atikon.io 11:32
timotimo nine: wrong channel again? 11:34
nine Yeah, brane didn't register, that this doesn't really look like normal shell output. 11:35
Woke up at 5 in the morning because the roller shutters didn't close and I can't sleep when it's too much light. Turns out my WiFi router which hosts the controller software has got a broken flash or something. Rebooted into an openWRT version that shouldn't have been on that thing for half a year. 11:36
timotimo whoops 11:37
i, too, can't sleep when there's light; even a little will prevent me from falling asleep, and a bit more than that will easily wake me up 11:38
stmuk we are using a cheap car sunshade to block summer light from the window 11:46
timotimo my shutters are human-powered 11:47
nine Well sometimes that is an advantage indeed :) 11:54
jnthn back 12:04
brrt \o 12:05
jnthn Darn it. Some update seems to have screwed things up such that when the auto-logout-because-you-were-inactive thing happens, you just get a black screen and, mouse cursor moving aside, a totally unresponsive system :/ 12:06
Occasionally get hangs coming out of hibernate mode too. 12:07
Don't miss the Windows dev expereince at all but I miss the stability :P :P
brrt are you on linux now?
timotimo auto-logout, you mean suspend to ram or just a screen locker?
jnthn brrt: yeah 12:08
timotimo: Just screen locker :/
timotimo that's not nice
brrt part of 'stability' is dealing with the bugs you know rather than the bugs that you don't though :-P
timotimo though there's a variety of screen lockers to choose from :D
what kind of DE are you running?
jnthn timotimo: Whatever Ubuntu comes without of the box :) 12:09
timotimo oh
brrt i always feel like windows is less stable (in my hands) than windows is, but i think i'm ignoring a lot of things that you'd notice :-)
eh, second windows should be linux :-P
jnthn tbh I don't even care what it is, in so far as I use the command line + chromium and that's about it :P
timotimo the ubuntu devs have been brewing their own X replacement for a while that's not gotten any traction outside of ubuntu where you're basically forced to use it :P
ilmari did they actually switch to it by default? 12:10
timotimo i think they very recently dropped mir development
brrt ymmv, but you might find fedora to be more polished.
adn then agian, you might not care
ilmari has fedora switched to wayland yet? 12:12
jnthn Wow, another 3 billion instructions off as a result of the previous two commits :)
timotimo i'm still running xorg, but i believe if you install fedora regularly you'll get a gnome3 on wayland now 12:14
i started out with the xfce4 spin
brrt wonders how many bitcoin can be mined with all the instructions jnthn has saved
yeah, wayland is standard by now
i notice a very occasional bug in Qt integration, but other than that
jnthn Current project: trying to heap-allocate frames that'll obviously get promoted there anyway 12:16
nine jnthn: so you're already outdating the blog post you just wrote?
brrt and how will you know how obvious that is?
jnthn Yeah :P
brrt: Well, my Plan A is to mark ops that force it (done) and have the bytecode validation note if it seems such an op (done), and then use that flag (doing it now) 12:17
I think spesh can in the future try to be more accurate
Boom, sigsegv 12:29
lizmat misses RabidGravy 12:33
[Coke] soooo much burnout since y2k. 12:35
jnthn Hm, nearly got it to work, just some SEGV in a few spectests 12:43
timotimo you must know how much it costs to promote frames during core setting compile? 12:48
jnthn About 2.15% of CPU cycles
ho, interesting 12:49
Was hyper.t flappy?
Just tracked down the SEGV in it and...it wasn't anything new
Just uncovered
Zoffix wasn't a flopper for me 12:51
timotimo curious 12:53
i'm going to look closer at the high occurence of memset during Terminal::Print thing 12:54
jnthn I guess it coulda shown up in various places 12:57
Plus a second one I just found 12:58
Geth MoarVM: ae86ef0620 | (Jonathan Worthington)++ | src/core/frame.c
Ensure allocd_work and allocd_env are zeroed.

Otherwise they may be junk which will break OSR by causing it to try and free a bogus pointer.
13:00
MoarVM: a539212457 | (Jonathan Worthington)++ | src/spesh/log.c
Handle log getting full between making entries.

This could occasionally lead to a NULL pointer dereference.
13:04 ggoebel joined
jnthn Seems I've a working patch to allocate on the heap straight off in some cases 13:05
callgrind is measuring its worthiness
Seems to knock some seconds off spectest though
13:10 zakharyas joined
timotimo nice 13:13
jnthn The callgrind takes ages but at least it takes less ages than it used to :) 13:15
timotimo fewer ages* 13:16
:P
jnthn *groan*
So I realized over the weekend that there's actually a much simpler solution to getting most of our Perl 6 pass-a-thing-in-a-container dispatches and inlines back 13:21
Than the super-clever alias analysis
Which we'll want some of anyway for doing EA but still 13:22
We know the type tuples, including deconts, of our callees
We can also stash those away at the callsite too 13:23
Then, provided it's stable, we can trace back from the args to where there's something that fetches the arg and, provided it's a deopt-able instruction, insert a decont + guard there
The decont would then be subject to the fetch lowering 13:24
And the guard a normal STable one
jnthn sets about figuring out the details of that 13:25
Also, going to make decont a deoptonepoint so we get guards on it 13:27
Which will also get us some Perl 6 spesh mojo back
I like how this guard splitting also naturally means we only enforce the content of the container when we care, whereas before we always did it
Oh dear. Things get *worse* after my patch. Hmm. 13:43
Oh, hmm 13:47
Of course, since I marked exception
But there's loads of code like
nqp::die(...blah...) unless $foo
hm, though I forgot to mark die 13:48
lizmat
.oO( I always use die to mark )
13:49
or dye rather :-) 13:50
dogbert17 jnthn: yes hyper.t was flappy 13:52
jnthn dogbert17: OK, hopefully no longer on HEAD :)
dogbert17 :) 13:55
TBH, I've only had it flop once or twice 13:58
lizmat news.perlfoundation.org/2017/07/gra...perl-.html # jnthn++ 14:04
Zoffix w00t \o/ jnthn++
timotimo cool 14:05
jnthn is quite relieved by this 14:07
Some weeks back I got told it was approved. So I didn't take on $other-work so I could focus on Perl 6 for the summer and dug in. Then got a mail some days later saying some legal process needed to be completed first before the approval could be posted. I figured eh, I'll just get on with stuff, guess it's just a couple more days. Took some weeks in the end. TPF++ for sorting it out, anyways. 14:09
Geth MoarVM: c7be0ee7f5 | (Jonathan Worthington)++ | src/spesh/stats.c
Fix a typo.
14:12
MoarVM: c5be4dd59a | (Jonathan Worthington)++ | 3 files
Move checking part of force_to_heap into an inline

Since quite often - increasingly so if we allocate directly on the heap - the answer will be that it's already promoted.
jnthn I think more checks were part of the added cycles, but there's no getting away from the other numbers: we really are causing a lot more GC
So a static approach isn't going to fly, I don't think 14:13
I guess takeclosure must happen more conditionally in NQP than I expected
I guess it makes sense given it can flatten more aggressively
Guess I'll try a dynamic approach :) 14:14
brrt that smells like it's going to want a counter 14:15
jnthn Yeah
Nice thing is, we already have one
An invocations counter
So if I also count in the heap promotion code 14:16
I guess we can stop counting once the frame is specialized also
oh, even easier, just latch once it's promoted 14:22
Mmmm...fresh watermelon jice 14:27
*juice
timotimo so ... water? :) 14:32
dogbert17 tried to check out MoarVM master and rebuild it. It worked but when running 'perl Configure.pl --gen-moar --gen-nqp --backends=moar' I get SEGV's 14:33
14:33 travis-ci joined
travis-ci MoarVM build failed. Jonathan Worthington 'Move checking part of force_to_heap into an inline 14:33
travis-ci.org/MoarVM/MoarVM/builds/259383987 github.com/MoarVM/MoarVM/compare/a...be4dd59a61
14:33 travis-ci left
jnthn Hm, maybe my pulling apart of stuff into commits didn't quite go to plan :) 14:33
dogbert17 :) 14:34
jnthn Not sure why htough
dogbert17 perhaps one important change didn't make it through 14:35
jnthn Dunno. After latest round of changes I also see segv 14:36
dogbert17 tries ASAN 14:38
jnthn oh duh duh duh
dogbert17 ASAN:SIGSEGV 14:39
=================================================================
==9221== ERROR: AddressSanitizer: SEGV on unknown address 0x00000006 (pc 0xb566b9a0 sp 0xbfdf2070 bp 0xbfdf6328 T0)
AddressSanitizer can not provide additional info.
#0 0xb566b99f in MVM_interp_run /home/dogbert/repos/rakudo/nqp/MoarVM/src/core/interp.c:304
#1 0xb59d2d3a in MVM_vm_run_file /home/dogbert/repos/rakudo/nqp/MoarVM/src/moar.c:331
jnthn I somehow got the conditional totally backwards
14:40 ilmari[m] joined
dogbert17 has done that more times than I want to admit 14:40
Geth MoarVM: 4a92691268 | (Jonathan Worthington)++ | src/core/frame.h
Correct inverted conditional.
jnthn timotimo: It turns out the juice is a pink/red color and quite sweet :) 14:43
dogbert17 and .... the SEGV has mysteriously disappeared :) 14:44
nine Amazon++ # sending a replacement for my faulty router without making a fuzz about me running openWRT on it. 14:47
jnthn Hm, wallclock numbers aren't immediately encouraging after my change, but could be noise. Also, increasing heat in the office thanks to heatwave outside. :/ 14:48
nine Though I had some funny 10 minutes on the phone with the helpdesk lady how faught with their system which needed confirmation of my payment data but did not accept the correct one (despite amazon.com showing the exact same numbers)
lizmat which is why I run my spectest bench at 5am in the morning or so :-) 14:49
ilmari as opposedt to 5am in the afternoon or 5pm in the morning? 14:50
jnthn Well, callgrind can give me better numbers 14:51
Much of what I'm doing is within noise so far as wallclock goes
ah, a chrome tab was hungry 14:55
jnthn offers his latest to callgrind
lizmat ilmari: ah, indeed 5 in the morning :-)
ilmari lizmat: am/pm sucks, just use 24h time :) 14:56
lizmat ok, I run my spectests at 0500 :-)
ilmari I remember seeing "02:30 pm" somewhere recently, which is just weird 14:57
who the hell uses leading zeros with 12h time?
15:10 brrt joined 15:12 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Correct inverted conditional.' 15:12
travis-ci.org/MoarVM/MoarVM/builds/259395289 github.com/MoarVM/MoarVM/compare/c...9269126861
15:12 travis-ci left
jnthn yay :) 15:13
dogbert17 callgrind?
jnthn No, the travis report agreeing with the earlier fix
callgrind still grinding
I'm already working on the next thing while it does so :)
dogbert17 saving even more cycles? 15:16
jnthn Well, that's the eventual goal, for now just getting spesh to propagate information about type tuples seen in callees back to their caller's callsite, so we can do better optimization 15:19
This is more for Rakudo than NQP, though, so will be looking less at CORE.setting compilation during it 15:21
15:31 MasterDuke joined
japhb timotimo: What is "the high occurence of memset during Terminal::Print thing"? 15:32
jnthn++ # Memory use and performance hacking 15:33
jnthn Gahhh. :( Latest version of the frame promotion changes are even worse. 15:34
lizmat knows that feeling 15:35
:-(
MasterDuke i've been experimenting with making MVMString.num_graphs an MVMuint64 (instead of MVMuint32) 15:40
yoleaux 27 Jul 2017 18:37Z <AlexDaniel> MasterDuke: I'm going to take a nap now, butā€¦ bots are broken :) Feel free to investigate: github.com/perl6/whateverable/issu...-318444466
27 Jul 2017 18:38Z <AlexDaniel> MasterDuke: well, not completely broken, but a chance of getting MoarVM panic when you do something is really high.
MasterDuke however, there are lots of places where some MVMint64 value is compared against num_graphs (or something similar, like a substring length)
i supposing introducing an MVMint128 would not be the preferred solution 15:41
jnthn No. 15:45
Ok, with thresholds tweaked the wallclocks look better 15:49
MasterDuke right, i'm thinking that a bunch of checks will get/have to go away at the moar level (e.g., if (length < 0) { MVM_exception_throw_adhoc() } else { })
and such a check would have to be moved up to the nqp/rakudo level 15:50
jnthn Uh
No
I mean, we have to do checks at VM level to make sure we don't go writing over the ends of buffers and stuff
MasterDuke well, i mean convert the MVMint64 parameter to an MVMuint64 15:51
jnthn Oh
Yeah, that we can do
Though
A lot of the reason we have MVMint64 is because we receive the value in an i64 register 15:52
And so it's passed that way from the interp 'cus that's how the interp sees it
MasterDuke yeah, and uints aren't handled well
which was also something i had tried to start on a fix for, but didn't make much progress
but Zoffix has also mentioned he might work on it 15:53
anyway, afk for probably until tomorrow, but will backlog if there are any further thoughts/comments 15:54
16:08 brrt joined
jnthn Urgh, no, things are even worse. Doesn't make much sense. :/ 16:29
nwc10 step away from the keyboard and check the stock level in the beer fridge?
jnthn Either the predictor is really wrong, or we must have frames that start out getting promoted a lot and then cease to be
nwc10 any test cases that the rest of us can play with?
Geth MoarVM/frame-heap-prediction: 2184a05861 | (Jonathan Worthington)++ | 3 files
Allocate frames on heap that will need promotion.

By trying to use existing promotions as an indicator. This somehow seems to end up doing *worse* for the CORE.setting build, however it looks like it helps `make spectest` wallclock time a bit (though it's all within noise).
16:34
jnthn There's waht I tried
Off home now
17:06 robertle joined 18:40 praisethemoon joined
timotimo japhb: profiling moarvm while running the examples from that library gives a surprising amount of time spent in memset 18:41
nwc10 jnthn: frustratingly ASAN makes no comment 18:46
but I'm guessing that wasn't the problem. It was "why is this slower?" 18:47
timotimo yeah, it was
we might want to debug-printf stats about what exact frames used to get promoted (how often) and which frames are now being pre-promoted and post-promoted 18:48
nwc10 oh gosh it's fast when you build O2 rather than ASAN :-) 18:49
japhb timotimo: Interesting. Maybe because of all the 2D-array slinging or the string joinging or the I/O? There's a lot of copying between backing buffers and the screen grid, and then outputting massive strings of grid updates to the TTY. 20:04
(Terminal::Print::Grid should show a fair number of low-level and high-use actions.) 20:05
If you're seeing it in the particle-rendering code, that gets even more interesting, because there's a particle-to-grid-cell collation pass.
21:04 mtj_ joined
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/07/31/...r-smaller/ 21:22
timotimo cool. fprinting the numbers that take part in the "if" for resolving annotations makes the "use of uninitialized value" messages go away 22:35
23:29 bisectable6 joined, quotable6 joined, committable6 joined, evalable6 joined, coverable6 joined, greppable6 joined, unicodable6 joined, bloatable6 joined, benchable6 joined, statisfiable6 joined 23:51 sivoais joined 23:52 https_GK1wmSU joined 23:55 https_GK1wmSU left