02:47 _ilbot joined 04:17 flussence joined 07:46 camelia joined 08:19 camelia joined 12:01 tgt joined
nwc10 What would this be telling me? 13:15
(gdb) p item
$1 = (MVMCollectable *) 0x4000300400001
jnthn That the pointer is bogus, given the 1 at the end... 13:25
Just out of knowing alignment, I think we can safely say that's not a valid pointer. 13:26
13:46 FROGGS joined 14:07 jnap joined 14:10 jnap joined
nwc10 Oh, I though the 0x40030040001 pattern might have been a tell-tale about why 15:17
anyway, you too can probably have this SEGV if you do this:
paste.scsys.co.uk/285027 15:18
basically I made MoarVM run a nursery collection on every allocation
that's a SEGV in ..bin/moar --libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --setting=NULL --no-regex-lib --target=mbc --output=gen/moar/stage1/nqpmo.moarvm gen/moar/stage1/nqpmo.nqp
so, presumably (at least) one thing is not rooted 15:19
it is, of course, bloody slow
but probbly the fix for that is to redo how often full GC runs happen
15:21 ggoebel115 joined
jnthn Ooh 15:21
nwc10 if you naively always do a nursery run, then it goes SEGV because tc->thread_obj is NULL 15:23
if you just check for that, it goes SEGV fairly early. Not *sure* if that is a bug, or an assumption about how far bootstrap needs to be before the GC can run at all
hence the hack in that patch to wait until the first real nursery run before going all agressive
jnthn Yeah, it's an assumption that we have space in the nursery to bootstrap
nwc10 but really, I think that it would be better to assert or panic if the GC tries to run too early
15:24 jnap joined
jnthn Well, there's a better answer 15:24
There's a way to make the GC do directly gen2 allocation
nwc10 anyway, with the hack, it takes bloody ages but it does crash way earlier than the Rakudo setting
jnthn So we can maybe use that to make sure the bootstrap all allocates directly in gen2 and we start with a really empty nursery.
nwc10 I suspect that "Bloody ages" could be reduced if I tracked how much is allocated, and avoided second stage GC until ten-times a full nursery had run. Given that the ten times is assuming that it's 10 full nurserys 15:25
does nearly all the bootstrap survive? The loading process doesn't make temporary objects? 15:26
anyway, it's a tuning detail
jnthn No temporaries really
nwc10 the hack shows up (at least) one bug
jnthn It's tuning, but likely wroth it...
Yeah. Nice hack. :) If you don't find the actual bug, I can certainly use that to help reproduce/find it. 15:27
nwc10 I don't know if I know enough to find the bug
anyway, need tea, and the shops shut soonish
and don't open tomorrow
jnthn ok :) 15:28
In the meantime, I may have a patch that gives some amount of pain relief with setting compile time.
dalek arVM: cecf572 | jnthn++ | src/core/ (3 files):
Can clean up ->caller more quickly in many cases.

This greatly alleviates the missing closure handling optimizations in the GC so far; CORE.setting compiles in 73% of the time it previously did with this.		 15:36
timotimo oh sweet! 15:37
dalek arVM: d1a0aec | jnthn++ | src/moar.c:
Bootstrap object system directly into gen2.

  nwc10++ for analysis that led to this.		 15:44
nwc10 jnthn: do food shops open on Sundays in Slovakia? 15:47
jnthn nwc10: I'm fairly sure the big tesco I lived near in the center opened for some hours on a Sunday 15:50
nwc10 ah OK. Was curious. 15:51
jnthn Maybe just until 4pm or so...
nwc10 However, I'm not missing Tesco
jnthn Forget exactly...it was 4 years ago :)
timotimo jnthn: did you measure what benefit the last commit gave? 15:55
jnthn timotimo: I'm not sure they'll be measurable... 16:00
timotimo: make test in NQP ended up coming in at 23s on the run rather than 24s before but that's likely noise
Um, though the run I just did now came in at 22s. What. :) 16:01
Reliably get 22s now. Used to get 25s reliably. I am pretty sure most of that came from the big win in cecf572 rather than the small one in d1a0aec 16:02
timotimo :) 16:17
fair enough 16:18
well, when trying to build rakudo, i get the pointer to old fromspace thingie :\ 16:41
jnthn Yeah, I didn't hunt that one down jus tyet. 16:42
FROGGS timotimo: can you check your Moar Makefile for the -On flag?
timotimo sure 16:43
-O1 -g2 16:44
er
-O1 -g3
FROGGS damn
seems only my box does build using -O1 16:45
jnthn oh holy crap
NO WONDER stage mast is slow
I just went to fix a bug I thought was probably the multi-dispatch cache's fault (not knowing about containers)
...and discovered there's no multi-dispatch cache in place at all. 16:46
That means we've been putting up with longer compiles of everything. 16:47
jnthn deals with this now, since it'll make working on everything else faster... 16:49
FROGGS \o/ 16:51
NO CRAP! HOLY WONDER!
17:08 grondilu joined
TimToady (dumping core faster)++ ;) 17:13
tadzik haha 17:15
timotimo :D 17:16
moritz hipsters were yesterday, today we have (core) dumpsters! 17:19
timotimo i dumped core before i compiled Cool.
TimToady Dumpster Dance! 17:20
moritz now my rakudo/moar-support also segfaults during setting compilation 17:37
after stage mbc
jnthn moritz: Does it actually write out the CORE.setting.moarvm? 17:38
dalek arVM: ba44826 | jnthn++ | src/6model/containers. (2 files):
Allow containers to indicate non-invoking fetch.

Will use it in implementing the multi-dispatch cache; will also need it for various other optimization related things in the future.		 17:39
arVM: 484a088 | jnthn++ | / (6 files):
Stub in multi-cache storage, layout, etc.
moritz jnthn: 11MB of it written, yes 17:40
jnthn OK, so it's an exit crash...
moritz succeeded in gdb 17:48
jnthn tssk 17:49
FROGGS: I guess that known file handle issue remains unfixed, though?
timotimo does the multi-method cache improve the run speed of nqp-moar as well? 17:51
jnthn Sure, given it's NQP run-speed that determines how long phase mast takes, given that's all NQP code. 17:55
timotimo ah, of course, that one does do multi-dispatch
you even said so above 17:56
jnthn And the dispatcher is written in NQP, which is fine if you only hit that slower path occasionally.
18:08 _ilbot joined
FROGGS[mobile] jnthn: yes, because I did not really understood the suggested fix 18:57
:o( 18:58
19:03 lizmat joined
jnthn multi cache seems to be a win 21:26
timotimo what a surprise! :) 21:33
jnthn NQP test suite here is down to 19s now, from 22s after earlier work. 21:35
timotimo oh nice :) 21:36
there, fudged it 21:37
dalek arVM: 8e20077 | jnthn++ | src/ (4 files):
Give each type a unique ID for use in caching.
 21:39
arVM: fd7c070 | jnthn++ | src/ (6 files):
Finish up multi-dispatch cache implementation.
jnthn Hm, with --jobs=12 I can get the NQP test suite down to 7s now... 21:41
:)
Good win for CORE.setting compilation too 21:46
FROGGS hehe, that sounds nice :o)
jnthn++
jnthn Here's the key numbers as things stood before my work today: 21:47
Stage parse : 141.805
Stage optimize : 20.628
Stage mast : 179.440
Here's how those are now
Stage parse : 81.131
Stage optimize : 9.668
Stage mast : 56.230
148s per build vs 343s before. 21:48
nwc10 so you've more than halved the time. Not bad.
Not at all bad. 21:49
beer?
jnthn ;)
nwc10 How does it compare to the JVM numbers for those stages on the same machine? 21:50
jnthn I'm recalling them off the top of my head here, but I think parse is around 43s, optimize is around 4s, and jast is around 26s 21:51
nwc10 OK, so only twice as fast.
jnthn Yeah, JVM is currently about twice as fast.
But Moar doesn't have any clever optimization stuff in it yet. 21:52
timotimo ooooooh yeah 21:54
and the parrot times?
parrot takes 100s for stage parse on my machine 21:55
jnthn timotimo: Don't recall those
I seem to remember Parrot was more than that for parse. 21:56
timotimo that's great! :) 21:57
though there's parts missing from the core setting for moar, no?
jnthn Not much.
It's missing...concurrency stuff, so it's not a quite fair comparison with JVM.
timotimo very nice :)
now all that's left to do is for it to not explode during building :D
jnthn I think sockets are the only thing left out and that's not that much code.
Yeah...I didn't really have the concentration to make GC bug hunting a worthwhile thing today.
timotimo didn't we remove some dynamic var stuff from the setting, too?
probably doesn't account fo rmuch
well, i'm happy :)
finding the lack of caching was a good catch
jnthn Yeah, I didn't realize we'd not got that implemented already :) 21:58
timotimo so, what do you feel like doing next?
or rather, when's the next tuitful day?
jnthn Well, I may have some time tomorrow, but gotta go to Goteborg 21:59
Will be teaching my final class of the year Mon/Tue
Then got Wed/Thu free for Perl 6 things, but should also do some Christmas shopping and prep for trip to UK to see family. 22:00
timotimo that still sounds good :)
do you have anything that you can delegate to me perhaps? something not too complicated? :P 22:01
(you know my (lack of) capability)
jnthn timotimo: Well, I'm seeing if I can get sanity tests to run at all, which may help point out things we need to work on. 22:12
dalek arVM: 3545bd2 | jnthn++ | src/core/frame.c:
Avoid premature collection of contvar clones.
 22:25
22:29 colomon joined
dalek arVM: 5ea206f | jnthn++ | src/core/frame.c:
Don't spew state var warning.

Tests will show up their not-done-yet well enough.		 22:36
jnthn timotimo: OK, so...hmm
timotimo: If you run a bunch of the tests in t/00-parrot and t/01-sanity, they pass. Not all, but many. 22:37
timotimo: But prove --exec=perl6-m t/00-parrot t/01-sanity always reports "No plan found in TAP output" :(
timotimo: Feel free to look into that, also to look into any of the test failures 22:38
FROGGS: You may also have some ideas on the prove issue...could be something specific to a certain kind of handle? 22:41
timotimo i can look, but right now i've had a few drinks :)
jnthn np, doesn't have to be now :) 22:43
timotimo i'm running an unoptimized moar now, i get until trying to build Test.pm 22:44
i just got the last version related commit and will try rebuilding
i couldn't run any of the sanity tests yet
jnthn yeah, you can't "make test" but you can perl6-m t/00-parrot/01-... 22:46
timotimo yes, i was trying that 22:47
i got an error that seemed like it should have been a warning
use of blah in numeric context mumble mumble
i'll try again in a minute
FROGGS compiles
jnthn Yeah 22:48
Warnigns somehow end up as errors
Not sure why
timotimo ah, good. now i can run the sanity tests 22:49
i also can't make m-test because m-install doesn't run to completion :)
t/01-sanity/01-tap.t .. ok 22:51
All tests successful. 22:52
i can do that with prove -e './perl6-m' t/01-sanity/01-tap.t'
but it sometimes fails
jnthn Hm, odd...
It always fails here
timotimo tried it with -v? 22:53
jnthn t\00-parrot\02-op-math.t ..
Ƀ┐
No subtests run
...
FROGGS when we run under prove, then stdout/stderr is piped rather than a tty, right? 23:05
prove perl6-m t/01-sanity/01-tap.t 23:06
perl6-m ............... > Failed to seek in filehandle: 9
ohh, -e missing
ahh, all subtests pass, but nonzero exit status 23:07
104s stage parse.... I like it :o) 23:17
parrot needs at least 10s more here
I think that this could cause problems: gist.github.com/FROGGS/422a82ea138d3fe14833 23:39
dunno how to fix it though 23:40
dalek arVM: 3940115 | jnthn++ | src/core/frame.c:
Avoid looking at uninitialized memory.

  FROGGS++ for reporting.		 23:43
FROGGS umm, that was quick
ohh, the error message has changed! 23:44
before, it just said: Unhandled exception: Cannot invoke this object 23:45
now: Unhandled exception: Cannot invoke this object (REPR: Uninstantiable, cs = 0)
and valgrind is clean
jnthn Oops, didn't mean to commit that extra debugging info in the patch... 23:48
Ah well, does no harm.
FROGGS correct :o)

Powered by Cro and the Raku® Programming Language.

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

Thank you!