diakopter ilmari: I'm confused 00:00
maybe you thought I wrote KB/s 00:01
geekosaur no, ilmari is pointing out that in many areas 2.4G is so congested that you can't get any kind of wifi performance out of it 00:03
diakopter ohhh. well I'm in Mountain View, CA at the moment XD
there's around 30 visible SSIDs in range
TimToady at least it looks like we'll get 1Gb Google fiber in the next three years 00:04
(in MV, I mean) 00:06
diakopter I'm at $work at Castro & Evelyn; but yes, I was on the secret backup wifi network, not the normal throttled one for the worker masses 00:07
then again, to be throttled at 10Mb/s per user isn't that bad 00:08
in other news, my dumb Google Fi phone (Nexus 6P) hasn't received the May 2016 OTA security update yet :( :( :( 00:10
it's a conspiracy
geekosaur fwiw I haven't gotten it on my 5X yet either 00:16
timotimo oh diakopter is here! 00:18
did you see i did the thing where you suggested you would make the qast operations mappers take less memory with their closures and whatnot 00:19
00:22 cognominal joined
timotimo you can find the commit in a branch in nqp 00:31
in case you were wondering
there's more wins to be found there, i suppose. there's still more than 300,000 bytes used by frames that are closures in that region. i expect we could store the closed-over values compactly in a hash and have a simple lookup-thingie installed for every mapped op
01:48 ilbot3 joined 01:49 cognominal joined 02:15 zakharyas joined 05:36 domidumont joined 05:40 domidumont joined 06:04 domidumont joined
jnthn moarning o/ 09:47
timotimo hey jnthn
how are you today?
jnthn Not so good, but maybe it improves with more tea... 09:54
timotimo ah, tea. the nectar of the gods 09:57
or something
jnthn My body is doing that "oh you went to bed earlier to deal with your lack of sleep...how cute...let's lay awake some hours" thing :/ 09:59
timotimo i lay awake for a long time yesterday and today, but there was no "go to bed earlier" trigger to that 10:00
nine Yeah, bodies are funny like that. I always sleep tworst when I'd need it most. 10:02
timotimo ugh, i can imagine that
jnthn wonders if he's smart enough to improve reframe at all today... 10:03
nine jnthn: if not, a review of github.com/MoarVM/MoarVM/pull/364 is probably much less exhausting :) 10:07
jnthn :) 10:08
Yeah, especially given turning on a little more debugging seems to suggest that somehow an MVMArray is ending up containing references to past fromspaces...
timotimo i don't see a/the commit that addresses jnthn's line comment there
but it's probably in there somewhere 10:09
nine timotimo: the commit changed. I don't know why github still displays the old version. Fix is here: github.com/MoarVM/MoarVM/pull/364/...1890460R39 10:10
timotimo good!
10:18 arnsholt joined
jnthn nine: Did some review 10:21
konobi jnthn: did you have a peek at libck at all? 10:30
jnthn konobi: Had a quick look...it has some useful things 10:34
konobi ah, cool... there's also an academic paper or two behind it too. Also on the website i believe 10:37
goes into details like multicore effeciency, lock tradeoffs, etc. 10:38
jnthn argh...why oh why does a bug have to show up exaclty in the intersection between gc, continuations, and stack->heap callframe promotion... 10:45
nwc10 because it has shares in whisky distilleries?
jnthn The first two are a headache individually :P
dalek arVM/reframe: a3d01de | jnthn++ | src/gc/collect.c:
Fix crash when GCing an ended thread.
 11:05
arVM/reframe: 6d4e5d9 | jnthn++ | src/gc/roots.c:
Cope with MVMROOTing a call stack frame.

This fixes various crashes when adding temproots to the worklist.
jnthn Those two we rather easier to find/fix at least :)
jnthn sets off another spectest run over lunch to see how much those two fixes fixed 11:18
bbiab
11:54 TimToady joined
dalek arVM/even-moar-jit: 85e1f7c | brrt++ | tools/jit-comparify-asm.pl:
use labels instead of offsets in prettyfing asm

jit-comparifiy-asm.pl is intended to make jit frames diffable. This is easier and more readable using labels rather than code offsets.		 12:13
jnthn back 12:22
12:45 brrt joined
brrt good afterlunch jnthn 12:46
jnthn :) 12:48
jnthn found a continuations problem
Hopefully *the* continuations problem
gah, alas not the only one 12:49
moritz :/
continuations are like politics: not just a single problem
jnthn Well, the "poli" is a clue there's gonna be more than one... :P 12:51
brrt lets not discuss polytics in polyte compani 12:52
dalek arVM/reframe: da178fb | jnthn++ | src/core/continuation.c:
Optimize away a loop we no longer need.

Was needed when we had to fiddle with refcounts, which we no longer do.		 12:54
arVM/reframe: a06891f | jnthn++ | src/core/continuation.c:
Missing MVMROOTs in continuation invoke.
arVM/reframe-jit: 6c6acd2 | brrt++ | src/jit/compile.c:
Add entry label out of range check

This should allow us to spot weirdness somewhat earlier.		 13:03
brrt this lets the JIT crash at the expected place, just checked rather than within the code segment itself 13:04
jnthn :) 13:09
dalek arVM/reframe: c6b8c93 | jnthn++ | src/core/exceptions.c:
Missing MVMROOT in exception throwing.
 13:12
brrt i already know, fwiw, that the jit entry label points into the caller
jnthn Turns out the second issue wasn't continuations themselves. 13:13
Just that gather/take happen to make a ton of exceptions.
In loops
Can't believe I missed that one when putting the stack -> heap promotion code in :/ 13:14
Into S06 in spectest and looking good. 13:18
jnthn crosses fingers
brrt hmmpf, all of this looks bog-standard 13:30
hmm, waitaminute
jnthn OK, that spectest runs is waaay better :)
brrt nope, its not OSR 13:31
dalek arVM/reframe: 48df567 | jnthn++ | src/core/frame.c:
Add a missing heap force operation.

Seems we don't hit it in the whole spectest, and perhaps can't, but better to just do the promotion rather than error out in case we end up being able to do this at some future point.		 13:41
nwc10 jnthn: without that least MoarVM patch, ASAN gets all spectests to pass, apart from t/spec/S17-supply/syntax.t which bails out with "Aborted" after ok 52 - did we throws-like X::ControlFlow? 13:48
1..3
which I think is an assert() failure about mutexes or somesuch
jnthn nwc10: hm, odd
Oh...
Yeah, that's not new.
nwc10 and I've seen it before
I think it will be timing related, because ASAN ends up alterning race conditions 13:49
jnthn On my "to fix" list, though not in this branch...
nwc10 yes, IIRC it's a master bug, and not new.
oh, except if I run it under gdb it passes 13:50
dalek arVM/reframe: de11e29 | jnthn++ | src/ (4 files):
Clean up GC debugging support.

Bring various debugging support bits under one flag, and adds what I have been using locally to debug some bits, so it's there to turn on in the future.
brrt good chance i've found the (a) reframe-jit bug 13:52
jnthn \o/ 13:54
Wow, we might get this merged soon, then :)
A little closer to release than I first hoped, but we've still a week... 13:55
dalek arVM/reframe: 08ce118 | jnthn++ | src/gc/debug.h:
Have GC debugging off by default.
 13:56
jnthn tries stuff with an optimized build 13:58
dalek arVM/reframe-jit: e6b0809 | brrt++ | src/jit/emit_x64.dasc:
Assign jit entry label prior to invoking

sp_findmeth may be invokish if the spesh slot does not mathc the object type. We assigned the jit entry label after getting the return value from MVM_6model_find_spesh, which is 1 if it invoked. This used to be no problem because FRAME (r12) used to point to the current frame at all times, but that is no longer true now. Fixed by moving the assignment prior to the invokish, as in other cases.		 13:59
brrt all is not ready yet 14:04
jnthn Ah, but closer? :) 14:05
brrt yes 14:06
we finish compiling CORE.setting, but crash in the tests 14:07
although... maybe i should rebase on your current branch
jnthn Yeah, quite possibly...I dunno when you branched off
I just discovered that we seem to have issues with NativeCall callbacks on Moar HEAD
nwc10: Dunno if you `make test` in your testing and also see that? 14:08
nwc10 t/04-nativecall/08-callbacks.t ........... Dubious, test returned 1 (wstat 256, 0x100) 14:12
Failed 8/8 subtests
oh yes, it has almost escaped the top of that window
brrt reframe-jit fails everything currently 14:13
jnthn brrt: After rebasing? 14:15
brrt everything in nativecall
aye
jnthn Ah
brrt not everything outside of nativecall
with segv
jnthn :)
brrt should be reasonably easy to figure out...
jnthn Yeah, I think I see what's going on with NativeCall too
14:16 domidumont joined
jnthn grmbl, no, still bust 14:25
nwc10 ASAN says "SEGV"
jnthn Any backtrace? 14:26
nwc10 not much: paste.scsys.co.uk/513626 14:28
dalek arVM/reframe: 0fa45a1 | jnthn++ | src/core/ (3 files):
Fix native callbacks after frame refactors.

Add missing stack->heap and rooting, and make stack->heap promotion cope with nested runloops.		 14:46
jnthn There we go 14:48
reframe is 1,149 additions and 876 deletions over 77 files 15:08
diakopter finally github fixes its pricing 15:15
(per user instead of per repo)
nwc10 jnthn: build and test run won't be finished before I need to leave to catch the train 15:23
it's in "stage mast"
make test is "All tests successful.". 15:26
Now starting spectests
nwc10 afk
jnthn Plenty of follow-up optimizations/improvements, but will do those after the merge of reframe :) 15:36
nine jnthn: pull request updated: github.com/MoarVM/MoarVM/pull/364 15:44
dalek arVM: 222115d | niner++ | docs/gc.markdown:
Add docs about MVMROOT courtesy of jnthn++'s excellent blog
 15:47
arVM: 4115a67 | niner++ | / (8 files):
Implement loadbytecodebuffer OP

Usefull for loading mbc from an in-memory buffer.
MoarVM: f9b7e4d | niner++ | / (10 files):
MoarVM: Implement loadbytecodefh
MoarVM:
MoarVM: Usefull for loading mbc from an already opened file handle allowing for us
jnthn nine: Merged, danke
nine Yeah! Thanks :) 15:48
jnthn It *seems* moving ->env to be allocated on the new callstack will be pretty straightforward. 15:49
->work will be a different matter.
Anyways, time for some rest :) 15:53
17:15 patrickz joined
diakopter but is it faster XD 17:22
timotimo well, it gets us rid of one extra allocation per stack frame construction 17:24
17:25 domidumont joined
nwc10 jnthn: Result: PASS 17:32
timotimo ooooh, enat
neat*
that's not a spectest, is it?
nwc10 spectest from origin/reframe 17:33
timotimo neat!
time to try a spectest with a bit of gc torture?
diakopter jnthn: one idea (for optimizing ->work): you could use 4 bits of the object header to store "custom alloc size" flag/size. Basically a way to allocate space for an object whose size will remain the same throughout its lifetime, but will vary across instances. If all four bits are 1, use the standard size from the STable (as it does now). Otherwise use the 4 bits' value as an index to a table on the STabl 18:22
e with custom size classes 18:23
19:25 dalek joined 19:33 vendethiel joined
geekosaur hm, google finally released the hounds^WMay update 20:02
diakopter geekosaur: not to me :( :( I guess I gotta wait "up to two weeks" 20:03
geekosaur I got it on N5 and N7 literally within the past 10 minutes 20:04
5X hasn't got it yet though
diakopter *cry*
20:50 TimToady joined
timotimo now i've got code that removes the need for closures for at least core mapped ops (not hll mapped ops so far) 21:17
i'll make a sensible measurement now, hopefully 21:19
OK, so before the very first patch in that series, nqp-m -e 'nqp::say("hi")' gave me 14146.222222 maxresidentk on average 21:23
after my latest patch, it's now only 13557.538462 maxresidentk
in between it was 13809.866667 maxresidentk 21:24
m: say "percentage-wise that's { 13809.866667 / 14146.222222 } in between and { 13557.538462 / 14146.222222 } at the end"
camelia rakudo-moar a31ab3: OUTPUTĀ«percentage-wise that's 0.976222941382 in between and 0.95838579723 at the endā¤Ā»
timotimo i'm not 100% satisfied with the code, so i'll PR it again to see what others think 21:25
gist.github.com/timo/0dfba0c72f065...latest-txt 21:36
no big closures any more! (but only in nqp)
diakopter wow, bigger difference than I would've imagined 21:39
(in memory)
timotimo oh?
well, you could have told me before i put this work in :P
hm. actually, it wasn't that much work
so i suppose the pay-off is enough compared to the work i put in
diakopter well maybe, if it carries over to rakudo I suppose 21:40
timotimo it does, but only partially, as rakudo uses the hll ops 21:41
the hll ops mechanism, that is
but also, it only has a small amount of hll ops it registers
diakopter ohhhh wait, you mean the closure mapped ops in the mast compiler
yes oh I definitely expected at least that much improvement 21:42
timotimo ah, you see, the 01 and 02 files are from rakudo, the 03 file is from nqp
that must be why it seems much better :D
timotimo points that out more clearly in the text files 21:43
what other thing were you expecting i'd improve? :)
m: say "rakudo got an improvement of { 65352 / 65996 }" 21:47
camelia rakudo-moar bffc3a: OUTPUTĀ«rakudo got an improvement of 0.990242ā¤Ā»
timotimo much smaller win, nusurprisingly :(
diakopter nothing in particular I guess. I think it's a good patch 21:48
timotimo you haven't seen the new patch :\ 21:49
diakopter er
XD where is the new patch
timotimo it's in the gist now 21:50
next thing i'll try is to hee how often moarop and op are the same thing, and maybe not put an entry into the op hash in that case 21:51
diakopter I think the lesson here is that automatic optimization has a long way to go 21:59
XD
timotimo er ... i guess? 22:00
anyway, it seems like more than 2/3rd of ops have the same $op as they have $moarop
so, i'd call that a win
i could even share decont arrays between ops, i don't think there's many different ones at all 22:01
really, those strings are all in the string heap anyway, but i figure it'll at least make the hash a bit more compact 22:02
especially since ou rhashes always have a bit of extra free storage allocated for their entries even if we could in theory shrinkwrap them for perfect size at some point during run time 22:03
32 + 29736 bytes 22:04
that's the size of the op-to-moarop hash before that particular optimization
surprisingly big, if you ask me
then again, it has more than 500 entries 22:05
m: say 29736 / (1063 / 2)
camelia rakudo-moar bffc3a: OUTPUTĀ«55.947319ā¤Ā»
timotimo 55 bytes per entry isn't gigantic 22:06
it's big, but not end-of-the-world big
32 + 7392 bytes 22:08
diakopter MVM_op_counts = 800
coooool
timotimo m: say "the hash shrunk to { 7392 / 29736 }x its size, by { 7392 R- 29736 } bytes" 22:09
camelia rakudo-moar bffc3a: OUTPUTĀ«the hash shrunk to 0.248588x its size, by 22344 bytesā¤Ā»
timotimo "wow, 22 kilobytes saved" ... ...
diakopter timotimo: this is, like, worrisome: github.com/MoarVM/MoarVM/commit/10...7e4916f674 22:10
timotimo but it's really quite neat that the heap analyzer lets us find stuff like this
diakopter: enh. could be worse. this is only about fact discovery, and literal_facts has another switch/case that will just return: when it doesn't know an opcode
diakopter (agreed)
hm 22:11
timotimo but yeah. that it got in there is very misfortunate
guess who put it in there ;) 22:12
it was me, of course
don't let the little ones play without proper oversight
psch better stops stumbling through nqp-j then :P 22:13
timotimo no, nqp-j will blow up if you do something wrong ... or at least it would do so much earlier than moar would
psch oh, i've had plenty of moments where things looked fine far longer than they should've... :) 22:14
timotimo ugh, even with our test suite we're basically flying blind :\ 22:20
arnsholt C is notoriously bad about letting you blow entire legs off without telling you, though
timotimo :< 22:21
should have built moarvm in rust, clearly
diakopter hah, it had barely appeared 22:22
arnsholt IMO, the best thing to do when programming in C is to realize that you're going to make all kinds of stupid allocation bugs and the like and use all the tools at your disposal to root them out as fast as possible 22:23
So things like asan and valgrind, clang static analyzer, etc. become really important
And just plain old tests
timotimo right, we use asan and valgrind most of the time
psch yeah, i like that about "learn the c the hard way", too 22:29
they introduce valgrind in like chapter 2 or something 22:30
timotimo that's very wise
i wonder where exactly the nativecall-related code-gen should hang 22:59

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!