Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-06-22

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:14 KDr2_ joined #moarvm
05:38 brrt joined #moarvm
05:43 TimToady joined #moarvm
05:58 TimToady joined #moarvm
06:40 brrt joined #moarvm
06:47 brrt good * #moarvm
06:48 brrt somewhat predictably, using the JIT local types array blows up horribly in the GC
06:48 brrt i haven't quite figured out why just yet
06:58 nwc10 start it running under valgrind and go off and make coffee?
07:03 brrt that's a decent idea, but i already know that it's a small number being interpreted as an object
07:03 brrt what i don't know if that is due to a too-small buffer being allocated
07:04 nwc10 in which case, valgrind (plus disabling the FSA) should make that obvious?
07:04 nwc10 or at lesat, give you time for more coffee
07:11 brrt can i disable the FSA?
07:11 nwc10 I think it's
07:11 nwc10 src/core/fixedsizealloc.c
07:11 nwc10 -#define FSA_SIZE_DEBUG 0
07:11 nwc10 +#define FSA_SIZE_DEBUG 1
07:12 nwc10 at least, that's what I'm building with locally
07:12 nwc10 but
07:12 nwc10 I thought that there was another thing you could do to it...
07:13 nwc10 no wait, the other way was just to say that the max sized thing for the FSA was 0, meaning that it call camee from malloc
07:14 brrt well, let's just try it out
07:14 nwc10 but looking at the code in src/core/fixedsizealloc.c I can see that the debug is more sophisticated - it comes from malloc *and* the size is checked too
07:19 brrt valgrind doesn't have much more information yet...
07:20 brrt clang y u so slow
07:29 brrt address 0x96f is not malloc'd or stack'd or whatever
07:31 nwc10 and given that was all you typed, there was no backtrace?
07:32 nwc10 as in, straight out, garbage value used as pointer?
07:32 brrt correct
07:33 brrt well, garbage marking as pointer
07:33 brrt it happens in Gc
07:58 zakharyas joined #moarvm
08:31 zakharyas joined #moarvm
09:20 timotimo with --valgrind the FSA will have redzones next to its allocations
09:20 timotimo --valgrind in moar's Configure.pl
09:22 brrt hmm, i'll try that out
09:32 timotimo what it doesn't do is to put freed pieces into a long list
09:32 timotimo valgrind does that for regular malloc
09:32 timotimo it keeps freed stuff around long to find use-after-free even if the use comes long after the free
09:59 jnthn brrt: What's in the local types array, or what exactly is it doing GC-wise?
10:00 brrt local types is how we determine which of the locals to scan
10:00 jnthn Yes
10:00 brrt i've changed the spill memory allocator to mark spilled values (which go into the local values array) as objects
10:00 jnthn Where is the spilled stuff stored?
10:01 jnthn On the stack?
10:01 brrt on the work buffer
10:01 brrt frame->work
10:01 jnthn A
10:01 brrt why
10:01 jnthn Ah
10:01 brrt because otherwise, suppose we have to trampoline, we're in big problems
10:01 jnthn OK, so you extend that with extra space to spill into?
10:01 brrt that is the intention yes
10:01 brrt but since i've changed that, it might be broken
10:01 brrt :-)
10:02 jnthn We already have a mechanism for that, iirc
10:02 jnthn (Allocating an extra reg)
10:04 brrt yeah, so, one of the challenges with that is
10:04 brrt the JIT runs far after the spesh graph building
10:04 brrt eh manipulation
10:04 brrt so it could well be that the temporary is already released prior my allocation starts
10:04 brrt (we should have a new 'high water mark' for that)
10:04 brrt which means i'm going to go ahead and do all the wrong things if i'd use that
10:06 jnthn Well, the extras are added during optimization, fwiw
10:10 brrt uhuh, still, point kind of stands
10:10 brrt :-)
10:10 brrt this is just a case of me doing something silly wrong
10:10 domidumont joined #moarvm
11:01 brrt joined #moarvm
11:06 brrt joined #moarvm
11:33 brrt joined #moarvm
11:49 AlexDaniel joined #moarvm
11:54 brrt joined #moarvm
12:06 brrt joined #moarvm
12:12 Geth ¦ MoarVM: 74ad7f7fb8 | (Timo Paulssen)++ | src/core/interp.c
12:12 Geth ¦ MoarVM: fix error message for decodersetlineseps getting non-decoder
12:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/74ad7f7fb8
12:15 jnthn In preparation for upcoming spesh improvemnet work, I'm currently working on a list of its shortcomings
12:15 jnthn https://gist.github.com/jnthn/95d0705d225ebfbad5dee0faa337624b is so far; I'm still adding things :)
12:16 brrt interesting little finding regarding my bug; i'm writing to 0x15e, not to 0x150, or 0x158
12:17 jnthn oops
12:19 timotimo oh, oh, i have one, jnthn
12:19 timotimo this pretty much piggybacks on "bad statistics":
12:20 timotimo when we have a function with multiple loops, OSR will kick in while the code runs in the first loop, and then the optimized version runs forever, even though in the second loop it could likely OSR again and gather new stats
12:20 jnthn You've seen this happen in real world code, I guess? :)
12:21 timotimo yup
12:21 timotimo i don't have good example code or measurements, though
12:22 timotimo i ought to be able to come up with an example where a function with two loops is noticably slower than two functions with one loop each and another function calling each ni turn
12:23 jnthn Yeah, I can believe it'd happen
12:24 timotimo i'm trying to find good example code to guide my jit implementation of the different encoder ops
12:25 timotimo zef installing itself gave me decoderaddbytes, now i'm also seeing read_fhb, close_fh, open_fh, getcp_s, fc, and chr
12:25 timotimo (obviously this is more than just encoder/decoder related)
12:26 jnthn Yeah, but all worth having :)
12:27 timotimo fc is very easy to add, yay
12:27 timotimo (it also only occured a single time across all processes it spawned to install zef)
12:31 * brrt notes that having a separate thread for spesh/jit work would open space for much more aggressive optimizations
12:32 jnthn brrt: that also
12:36 dogbert11 jnthn: interesting spesh writeup, looks as if there are a lot of wins to had there although I suspect none of them are LHF
12:36 dogbert11 *to be had
12:37 jnthn Added four more things
12:37 jnthn Including timotimo++'s one, which I totally hadn't thought of
12:40 timotimo how do we feel about jitting lock/unlock and semtryacquire and friends?
12:40 brrt nothing about it
12:41 timotimo well, "when should i put it into the jit" :P
12:42 dogbert11 "Since they have are called on a huge range of types..." # nitpick
12:42 TimToady joined #moarvm
12:43 dogbert11 also, what about bugs in the current implementation, will they be removed at the same time as this work is being done?
12:44 jnthn dogbert11: Yes, those could also do with going into this document to make sure we address them
12:44 dogbert11 I see three RT's with spesh in the headline
12:45 jnthn Got links?
12:45 dogbert11 m: sub foo () {$ = 42}; for ^2000000 { $ = foo }; say now - INIT now # RT #130855
12:45 camelia rakudo-moar 86e7b2: OUTPUT: «Cannot assign to an immutable value␤  in block <unit> at <tmp> line 1␤␤»
12:45 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=130855
12:45 dogbert11 there's one
12:46 jnthn wowser
12:46 dogbert11 the other are 131306 and 126364
12:47 dogbert11 there's one MoarVM issue which might apply as well: https://github.com/MoarVM/MoarVM/issues/552
12:48 TimToady joined #moarvm
12:57 timotimo all the lock ops have the reprid and concreteness checks in the interpreter at the moment
12:57 TimToady joined #moarvm
12:57 timotimo for the purpose of jitting that'd have to move into the function itself
12:57 timotimo (or be done using the exprjit)
13:00 jnthn Updated it again to now contain bugs dogbert11++ pointed out and some further points
13:02 timotimo "inforamtion" <3
13:07 jnthn fixed :)
13:07 jnthn And added two more things
13:08 timotimo running a spectest with my jit additions
13:08 jnthn Gradually running out of things to put on the list :)
13:08 jnthn oh!
13:11 jnthn Added one more big one that I forgot
13:12 timotimo oh yeah
13:13 * jnthn wonders what else there is
13:13 jnthn Though if we nail that lot then we'd be doing really quite well :)
13:18 dogbert11 will any kind off tooling have to made in order to make debugging spesh easier?
13:18 timotimo well, if we make the "new" spesh log a bit machine-readable, we'll be able to build something
13:18 timotimo jnthn already speculated an "optimization report"
13:19 dogbert11 I seem to remember that you or jnthn have written that finding spesh bugs is a real chore
13:21 jnthn dogbert11: Yeah, that's part of my "explain what we did" suggestion
13:23 Geth ¦ MoarVM: 8eb050f06b | (Timo Paulssen)++ | src/jit/graph.c
13:23 Geth ¦ MoarVM: jit a bunch more ops
13:23 Geth ¦ MoarVM:
13:23 Geth ¦ MoarVM: open_fh, close_fh, read_fhb, decoderaddbytes, fc, chr,
13:23 Geth ¦ MoarVM: getcp_s, objectid
13:23 Geth ¦ MoarVM:
13:23 Geth ¦ MoarVM: taken from bails during zef's self-installation
13:23 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8eb050f06b
13:23 dogbert11 I see it :)
13:23 jnthn Anyway, I leave that gist for further suggestions/input for now
13:24 jnthn But I think it or something like it will be my input for a spesh re-design
13:24 jnthn My idea being to try and gradually move towards the goal from what we have
13:24 jnthn Rather than to do it over
13:24 jnthn Because it's not like what we have is all bad. :)
13:25 jnthn It could just be improved quite a bit :)
13:26 * timotimo has to drive over to his old apartment and get a whole bunch of stuff out of there :|
13:26 timotimo so we can clean up fully and paint the walls and such
13:27 timotimo with temperatures as they are, this is going to be hell
13:27 jnthn :(
13:27 jnthn Yeah, it's 34C here :S
13:27 timotimo same here
13:27 jnthn Horrible
13:27 timotimo at least my care has A/C
13:27 dogbert11 17C
13:27 timotimo car*
13:28 dogbert11 34C is unbearable
13:28 jnthn dogbert11: Goodness, that's nice.
13:28 jnthn Is that typical for late June there, or just a one-off? :)
13:29 dogbert11 quite typical here in Scandinavia
13:29 dogbert11 a few degrees warmer wouldn't hurt though
13:30 jnthn When I lived in Scandinavia it was in the south of Sweden, which I guess is a bit warmer than the average :)
13:30 jnthn But still typically a few degrees cooler than it can get here
13:31 dogbert11 34C, I hope there's AC available
13:31 jnthn Alas no, 'cus it's relatively unusual for this to happen
13:31 jnthn And 34C is outside. In is more like 26C. Still too hot, but not quite so bad.
13:32 nwc10 but your commute will be breifly unbearable? :-/
13:32 dogbert11 can't you find a pub lacated in a cellar somewhere :)
13:32 dogbert11 *located
13:40 jnthn Mmm :)
13:40 * jnthn away for a bit
13:56 [Coke] No pub found, "lacated". Did you mean "lactated" ?
14:05 brrt joined #moarvm
14:13 jnthn .oO( milk stout )
14:20 brrt i have the answer to my bug
14:21 brrt who wants to know...
14:21 brrt it's actually kind of cute
14:21 brrt but
14:21 brrt i'm allocating 'on top of' the local + the space for the args
14:22 brrt but local_types is acting as if my temps get to the end of the local
14:22 brrt which is the more correct thing to do, to be fair
14:34 AlexDani` joined #moarvm
14:55 brrt with GC stress, compiling core.settings takes impossibly long
14:55 brrt but doesn't burn yet
14:57 Geth ¦ MoarVM/even-moar-jit: 65938869df | (Bart Wiegmans)++ | 5 files
14:57 Geth ¦ MoarVM/even-moar-jit: Use jit code local types array for roots
14:57 Geth ¦ MoarVM/even-moar-jit:
14:57 Geth ¦ MoarVM/even-moar-jit: Spilled values are stored, by default, in the frame work array.
14:57 Geth ¦ MoarVM/even-moar-jit: If they had been on the stack, entering the interpreter would
14:57 Geth ¦ MoarVM/even-moar-jit: destroy them.
14:57 Geth ¦ MoarVM/even-moar-jit:
14:57 Geth ¦ MoarVM/even-moar-jit: This moves those spilled values into the work array proper (they used
14:57 Geth ¦ MoarVM/even-moar-jit: to be after the args array) and ensures that the GC will properly
14:57 Geth ¦ MoarVM/even-moar-jit: trace and update them. This then ensures that the JIT compiled code
14:57 Geth ¦ MoarVM/even-moar-jit: will always have the proper values regardless of whether we call
14:57 Geth ¦ MoarVM/even-moar-jit: something that allocates memory.
14:57 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/65938869df
16:07 brrt joined #moarvm
16:12 lizmat the max we've seen outside here was 35.9
16:12 lizmat it's way cooler now
16:12 lizmat only 34  :-(
16:27 brrt that's insane :-o
16:27 brrt thunderstorms entering here
16:43 [Coke] looks like high outside here today is 27C
16:43 [Coke] weather's been all over the map here this spring/summer
16:44 [Coke] (well, spring, I guess)
16:45 lizmat previous high temp ever for 22nd June was 31.7
16:54 zakharyas joined #moarvm
16:59 domidumont joined #moarvm
17:00 ilmari we had 33°C here yesterday, but only 23°C today
17:59 jnthn Urgh, this is decidedly not the kind of weather to think in.
17:59 yoleaux 16:56Z <lizmat> jnthn: looks like nqp::create is actually assigning type objects to vivify attributes, is that correct ?
17:59 jnthn .tell lizmat Vivification happens at first access, not at creation time
17:59 yoleaux jnthn: I'll pass your message to lizmat.
18:01 nwc10 have you thought about the beer fridge?
18:11 lizmat m: use nqp; class A { has Int $.a is default(42) is rw }; my $a := nqp::create(A); dd $a.a; dd nqp::getattr($a,A,q/$!a/).VAR.default   # jnthn, then why doesn't this show 42 twice ?
18:11 camelia rakudo-moar 43c176: OUTPUT: «Int $!a = Int␤42␤»
18:15 jnthn I'll bet if you stick is rw on the attr you'll get it :)
18:15 jnthn When it's not "is ro" then we decontainerize it
18:16 jnthn And I guess the decontainerization process doesn't care for the default
18:17 * nwc10 thinks about the beer in the fridge, and the couple of crates in the L2 cache
18:17 jnthn Or something along those lines
18:18 jnthn Oh, but you did put `is rw`
18:18 jnthn That makes it stranger still
18:18 jnthn o.O
18:18 jnthn OK, I've no idea what it's doing :)
18:18 jnthn Without going on more of a debugging spree than I'm up for right now
18:19 jnthn Hang on a moment
18:20 jnthn m: use nqp; class A { has Int $.a is default(42) is rw }; my $a := nqp::create(A); dd nqp::getattr($a,A,q/$!a/)
18:20 camelia rakudo-moar 43c176: OUTPUT: «Int $!a = Int␤»
18:20 jnthn It's nothing to do with the accessor at all
18:21 jnthn In this case it's possible that attr container auto-viv just doesn't pay any attention to `is default`
18:22 jnthn fwiw, it's also entirely possible attr container auto-viv wants to go away.
18:22 jnthn And that we should initialize them explicitly during construction
18:23 jnthn Because right now we pay for it on every single attribute access
18:23 jnthn Turning them all into a branch
18:23 jnthn It made performance sense on balance back in the day
18:24 jnthn But not so much when we've a modern VM
18:24 jnthn Suspect brrt would like the JIT output much more if we did this. :-)
18:24 jnthn Though more importantly, I suspect CPUs rather would doo.
18:24 jnthn *too
18:25 jnthn Something to think about, anyways
18:25 lizmat well, it could make all object creation a lot simpler
18:25 jnthn How so?
18:25 lizmat has $.a = 42 vs has $.a is default(42)
18:26 lizmat the former would need the BUILDALL action, the latter not
18:26 lizmat or a simpler one
18:26 jnthn You're assuming BUILDALL actions are here for the longhaul :)
18:26 jnthn If we did end up making the changes I just suggested we'd pretty much have to revisit that lot anyway
18:26 lizmat well, it's a bug that "is default" is getting ignored for attributes
18:26 jnthn We'd also have to figure out some other kind of solution for attrinitted
18:27 lizmat anyways, it feels like a lot could be gained there
18:27 lizmat a lot that doesn't show in profiles much, as it's spread out a lot
18:27 lizmat anyways, dinner calls&
18:28 jnthn Happy nomming :)
18:28 jnthn And yeah, agree that a good look at object init could win us a lot
18:32 domidumont joined #moarvm
19:35 TimToady joined #moarvm
19:47 TimToady joined #moarvm
19:51 TimToady joined #moarvm
19:57 TimToady joined #moarvm
20:28 robertle I am failing to understand how register allocation etc works in moar. how/when/where are register frames created? and how is the number of registers in the frame determined?
20:30 jnthn robertle: See allocate_frame in src/core/frame.c, also MVMStaticFrame.h carries the number that are needed
20:32 robertle so do we do that for each lexical scope, roughly?
20:33 robertle that would be surprising
20:33 zakharyas joined #moarvm
20:34 brrt joined #moarvm
20:35 jnthn Yes
20:35 jnthn Well
20:35 jnthn Naively :-)
20:35 robertle naively is what I am after!
20:35 jnthn Reality is more interesting.
20:36 jnthn In that Perl6::Optimizer flattens away scopes in some cases
20:36 robertle that means a "register" is almost directly associated with a variable?
20:36 jnthn NQP::Optimizer does so far more aggressively; we can't go quite all that far with Perl 6
20:37 jnthn Though we can go further than we do
20:37 jnthn We use register and local as synonyms
20:37 jnthn A frame can have both lexicals and registers
20:37 jnthn Register = temporary working space
20:38 robertle right, and we need these as scratch space e.g. inside an expression
20:38 jnthn And is destroyed immediately when the thing returns
20:38 jnthn In some cases, lexical variables that aren't closed over are optimized into locals (e.g. registers)
20:39 jnthn The lexical space lives longer
20:39 jnthn There's no distinction at MoarVM level about which registers are scratch space and which are cases of lexical optimized into local
20:40 jnthn It only differentiates on the lifetime (can go away at return, may have to live beyond return)
20:40 robertle o how do we access registers from an outer frame? we can't just GET_REG?
20:40 jnthn You can't
20:41 jnthn Only lexicals can do that
20:41 jnthn In MVMFrame those are ->work and ->env respectively
20:41 jnthn ->work cannot be touched from anything except the bytecode in that call frame.
20:43 jnthn (This turns out to be a hugely important property for optimization)
20:46 robertle argh, I am missing more fundamental bits as well...
20:54 MasterDuke joined #moarvm
21:01 AlexDaniel joined #moarvm
21:54 MasterDuke joined #moarvm
22:59 TimToady joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary