Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-12

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

All times shown according to UTC.

Time Nick Message
00:04 vendethiel joined #moarvm
00:29 vendethiel joined #moarvm
01:03 colomon joined #moarvm
01:11 vendethiel joined #moarvm
01:29 colomon joined #moarvm
02:22 colomon joined #moarvm
02:36 colomon joined #moarvm
04:02 FROGGS_ joined #moarvm
04:03 rurban joined #moarvm
05:03 nebuchad` joined #moarvm
05:06 btyler_ joined #moarvm
05:09 betterwo1ld joined #moarvm
05:19 vendethiel joined #moarvm
06:23 vendethiel joined #moarvm
07:10 virtualsue joined #moarvm
07:34 vendethiel joined #moarvm
07:36 lizmat joined #moarvm
07:53 Ven joined #moarvm
07:55 rurban joined #moarvm
08:08 FROGGS joined #moarvm
08:15 brrt joined #moarvm
08:25 zakharyas joined #moarvm
08:44 vendethiel joined #moarvm
08:53 virtualsue joined #moarvm
09:02 virtualsue_ joined #moarvm
09:13 lizmat joined #moarvm
09:14 kjs_ joined #moarvm
09:21 kjs_ joined #moarvm
09:35 lizmat joined #moarvm
09:38 vendethiel joined #moarvm
09:45 Ven joined #moarvm
10:22 vendethiel joined #moarvm
10:39 kjs_ joined #moarvm
10:41 donaldh joined #moarvm
10:43 kjs_ joined #moarvm
11:08 dalek joined #moarvm
11:22 vendethiel joined #moarvm
11:35 lizmat joined #moarvm
12:13 kjs_ joined #moarvm
12:19 vendethiel joined #moarvm
12:23 [Coke] joined #moarvm
12:28 Ven joined #moarvm
12:51 kjs_ joined #moarvm
13:16 kjs_ joined #moarvm
13:25 ShimmerFairy joined #moarvm
13:27 virtualsue left #moarvm
13:43 vendethiel joined #moarvm
13:52 kjs_ joined #moarvm
15:01 jnthn oh no, the MSVC build is busted...
15:02 vendethiel joined #moarvm
15:04 jnthn timotimo: I'm very confused why MVM_spesh_graph_create duplicates logic that's already in MVM_spesh_alloc?
15:05 jnthn Oh, but it divides the buffer size by 4...
15:06 Ven joined #moarvm
15:10 Ven joined #moarvm
15:11 * jnthn cleans things up a bit
15:13 Ven_ joined #moarvm
15:14 Util joined #moarvm
15:17 dalek MoarVM: 5824c03 | jnthn++ | src/spesh/graph. (2 files):
15:17 dalek MoarVM: Clean up/improve spesh mem allocation.
15:17 dalek MoarVM:
15:17 dalek MoarVM: Do the "first block is smaller" optimization in one place. Also remove
15:17 dalek MoarVM: the artificial size limit on spesh allocations. As a side-effect, fix
15:17 dalek MoarVM: the MSVC build.
15:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5824c03f5b
15:18 Ven joined #moarvm
15:42 kjs_ joined #moarvm
16:05 jnthn Aww, I think the patch that disabled lazy deserialization a while ago may actually have also caused duplicate work...
16:35 Ven joined #moarvm
16:49 japhb jnthn: Was the lazy deserialization bug ever figured out (separately from fixed, I mean just the "diagnosed" part)?
16:55 jnthn japhb: No :(
17:00 vendethiel joined #moarvm
17:04 avuserow joined #moarvm
17:06 jnthn japhb: Also it may have been a bug that got fixed in the meantime
17:29 lizmat meanwhile, startup has deteriorated from .205 to .247 on my machine
17:29 lizmat :-(
17:29 jnthn Ugh
17:29 jnthn Any idea what caused it?
17:29 jnthn A local patch I have here makes it somewhat worse, also. But I've not pushed that.
17:29 lizmat I was looking at that yesterday and thought I bisected it down to a set of 3 nqp commits
17:30 jnthn I've got a really weird pre-comp test fail as a result of fixing a different pre-comp bug.
17:31 lizmat NQP revision bump -2015.02-68-g2e5e413
17:31 lizmat +2015.02-73-gd362467
17:31 lizmat is what seemed to be the one when I last looked at it yesterday
17:31 * lizmat continues backlogging
17:36 * jnthn takes a break for dinner
17:38 avuserow joined #moarvm
17:40 vendethiel joined #moarvm
18:49 vendethiel joined #moarvm
18:53 zakharyas joined #moarvm
19:01 jnthn Think I figured out the bug...
19:01 jnthn We cache SC indexes in object
19:01 jnthn And STables
19:02 jnthn And if you move the object to a new SC due to repossessio, I'm not sure it's doing the update...
19:03 jnthn Hm, or maybe not
19:03 jnthn bbiab
19:13 kjs_ joined #moarvm
19:45 timotimo jnthn: now you make the first spesh memblock huge and the rest tiny? :)
20:18 jnthn timotimo: Huh, I don't think I got it backwards?
20:18 jnthn size_t buffer_size = g->mem_block
20:18 jnthn ? MVM_SPESH_MEMBLOCK_SIZE
20:18 jnthn : MVM_SPESH_FIRST_MEMBLOCK_SIZE;
20:18 jnthn If we have a mem block already, the next one sould be the normal size, otherwise use the smaller size for the first one.
20:18 timotimo +#define MVM_SPESH_FIRST_MEMBLOCK_SIZE 32768
20:18 timotimo +#define MVM_SPESH_MEMBLOCK_SIZE       8192
20:18 timotimo :)
20:18 jnthn oh, darn
20:18 timotimo s'ok
20:19 jnthn Yeah, those numbers want to be the other way around
20:19 jnthn timotimo++
20:19 jnthn Do you want to fix, or shall I?
20:19 timotimo i have another commit in a branch that ramps up the spesh block size in three steps
20:20 timotimo because my measurements showed that about half of all spesh graphs ended up allocating only the first 50% of the second block :)
20:20 timotimo though if it's just barely above 50%, having a third step in there would actually make it *worse*
20:21 kjs_ joined #moarvm
20:22 jnthn At some point it's maybe not worth the code complexity.
20:22 jnthn Also we should retire dead-end specialization attempts at some point too
20:22 jnthn Not to mention compute the specializations on a different thread... :)
20:24 kjs_ joined #moarvm
20:27 rurban joined #moarvm
20:34 timotimo i've been thinking about retiring spesh things that haven't had the chance to get finished for a long time
20:34 timotimo i just don't really know what to hang it off ot
20:34 timotimo of*
20:34 jnthn Me either, so I decided to kick it down the road until a larger re-work
20:36 * timotimo has kind of forgotten what things he could maybe be doing
20:37 jnthn Could you add JIT support for the getregref_* ops, maybe?
20:38 jnthn Well, and you might want to take some of the localref work off my hands in general...
20:38 timotimo at some point you were saying we could kick the decont_all thing from our code-gen of nativecall invocation?
20:39 jnthn Only as part of a bigger re-visit of how we handle native invocation.
20:39 timotimo OK
20:40 jnthn But yeah, getting lex -> loc stuff in Perl6::Optimizer able to handle more cases again would help with perl6-bench's results
20:40 jnthn Other thing you might like to look at
20:40 jnthn uh, no, forget that :)
20:40 timotimo i could; i didn't look at the references things at all yet, so i don't have sufficient clue how to make the optimizer happier yet
20:41 jnthn Well, at the moment we can't take a refernce to a register
20:41 jnthn I mean, moar can
20:41 timotimo jvm can't?
20:41 jnthn But I didn't implement scope localref
20:41 jnthn No, JVM we can't, we'll have to just not lower.
20:42 jnthn But we shouldn't not do an optimization possible on one backend jsut 'cus the other doesn't have it.
20:43 timotimo right; did you mean scope localref isn't implemented on moar yet?
20:43 jnthn I meant that moar has the things we need in order to implement QAST::Var with scope localref
20:44 jnthn And on JVM we won't be able to do that - or at least, if we do it won't beat the current scheme we have for lexicals.
20:44 jnthn I was expecting to add something to HLL::Backend so the optimizer can ask if the backend supports localref scope
20:45 timotimo that seems like a very simple thing to do, just a little method
20:45 jnthn Right, that bit is easy.
20:45 timotimo would the optimizer turn a QAST::Var of some scope into a localref scoped var?
20:45 timotimo or is that for the code-gen to do?
20:45 jnthn Implementing localref scope in the QAST -> MAST is more.
20:45 jnthn Perl6::Optimizer will turn some things with lexical scope into having local scope if it can prove it's safe.
20:45 timotimo i remember that part from last year :)
20:46 jnthn However, if it sees a lexicalref anywhere then it now backs out of the optimization.
20:46 jnthn Which is a bit unfortunate given
20:46 jnthn my int $i = 0; ...while loop using $i that would love it to be local... say($i); # passes it by reference.
20:59 timotimo can nqp benefit from the references stuff at all?
20:59 timotimo i think i've asked this question before
21:01 jnthn Doesn't really need it
21:01 timotimo OK
21:04 dlem joined #moarvm
21:05 dlem o/
21:06 dlem jnthn: Thanks a lot for the session on Tuesday, inspiring stuff!
21:06 jnthn dlem: Welcome; I had fun doing it. :)
21:06 timotimo jnthn: currently we skip the variable (or rather: the block) if we see a lexical that's been refered to by a lexicalref; am i right in assuming that if the var had been declared lexicalref from the start, it'd be fine?
21:07 jnthn timotimo: Not really in so far as we don't lower those declarations at all either, afaik.
21:07 dlem jnthn: I had a thought afterwards (probably a really stupid one :) which I'd like to pass by you.
21:08 FROGGS[mobile] joined #moarvm
21:09 jnthn dlem: Sure.
21:09 dlem We discussed automatic destruction of objects upon leaving a scope.
21:09 dlem And then I remembered that you talked about escape analysis.
21:10 dlem Would it be possible to strike two flies with one swat, as we'd say in Norway? :-)
21:11 dlem If you're going to store objects in a temporary area outside of the GC, I reckon you'll have to destroy the objects in the temporary area when leaving the scope anyway.
21:11 timotimo jnthn: i'm not 100% sure how this is supposed to play out :\
21:12 jnthn dlem: Thing is that escape analysis is very much an optimization, so relying on it for semantics is likely a bad idea.
21:13 jnthn dlem: And many, many things can thwart it.
21:13 dlem I see. Well, I couldn't resist asking :-)
21:13 jnthn It *is* an interesting thought
21:14 jnthn It'd be possible to design a programming langauge that relied on escape analysis for its semantics, I guess, but I suspect doing so ties your hands in a lot of other ways. :)
21:15 dlem I for one wouldn't mind if I had to enable optimizations to get the "Perl 5" behavior here.
21:16 timotimo but you're not guaranteed to get the perl 5 behavior even with the optimization
21:16 dlem If the escape analysis worked perfectly, why not?
21:17 timotimo hmm
21:17 dlem And just think how it would help with porting Perl 5 programs ;-)
21:19 jnthn I suspect you don't get very far before the analysis comes back inconclusive.
21:19 jnthn Escape analysis is typically used to eliminate short-lived allocations.
21:20 jnthn And determine you can elide lock taking.
21:20 dlem jnthn: Yes, there are surely problems which I don't see. The less you know about something, the easier it appears :-)
21:21 jnthn :)
21:21 timotimo jnthn: how is lexicalref supposed to behave? turn into a localref or something?
21:22 jnthn timotimo: Well, if we get this right then it's just lexical -> local, lexicalref -> localref
21:22 jnthn timotimo: The thing to understand is that there's actually a 2x2 grid of possibilities that each compile differently.
21:23 jnthn decl(lexical, lexicalref) X use(lexical, lexicalref)
21:23 jnthn Declared lexical + access lexical = just a normal lexical lookup of the correct type
21:23 dlem In my simplified view on escape analysis, I reckoned that since you were going to identify the short-lived allocations, this would include all allocations of variables leaving the scope without any references to them.
21:24 dlem Chuckle now if you like :-)
21:24 jnthn dlem: Yes, but file handles usually will be (a) allocated in the scope of some open(...) routine, and thus be escaping it, then (b) be passed to various I/O methods or subs
21:24 jnthn And it's somewhat unlikely that you'd end up with those being inlined.
21:26 dlem Hmm, yes, I guess it gets to be a lot to keep track of.
21:26 jnthn Yeah. There was a paper I read that actually calculated re-usable escape info, so if you could figure out all of your callees you could do a bit better
21:27 jnthn But it was extremely complicated.
21:27 timotimo jnthn: and decl lexicalref and use lexicalref can turn into a localref, yeah?
21:27 jnthn timotimo: Correct
21:27 jnthn timotimo: The idea for Perl6::Optimizer is that you s/lexical/lexicalref/ and s/local/localref/
21:27 jnthn timotimo: Note that all of the following can happen:
21:28 jnthn Declared lexicalref, accessed lexical (becomes declared localref, accessed local)
21:28 jnthn Declared lexicalref, accessed lexicalref (...)
21:28 jnthn Declared lexical, accesed lexical (...)
21:28 jnthn Declared lexicalref, accesed lexical (...)
21:28 dlem In any case, now that I've planted this half-baked idea in your mind, who knows what will eventually happen ;-)
21:29 timotimo wait, decl lexical, accessed lexical turns into localref?
21:29 jnthn timotimo: No
21:29 jnthn I was assuming you could s/lexical/local/ :)
21:29 timotimo ah, i was meant to fill the ... myself
21:29 jnthn Right :)
21:29 timotimo %)
21:30 jnthn So the Perl6::Optimizer's job is just to make sure it turns all lexicalref => localref, and all local => localref. The tricky work is in the QAST -> MAST bit. If you look at lexical and lexicalref in QAST -> MAST, you'll see it handles all 3 permutations.
21:30 timotimo so basically "the ref or not ref stays"
21:30 jnthn uh, all *4*
21:30 jnthn Correct
21:30 timotimo underneath that, just turn lexical into local
21:30 jnthn And we need to handle all 4 permutations when implemetning localref
21:31 dlem jnthn: Keep up the good work, it's truly inspiring to see the great progress you're making!
21:31 jnthn So the hard part isn't in Perl6::Optimizer at all, but in the code=gen.
21:31 dlem jnthn: And thanks again for the session.
21:31 jnthn dlem: Thanks! And thanks for the ideas. :)
21:31 timotimo damn
21:33 timotimo but i suppose i could look into the code gen
21:34 dalek MoarVM: 6535f92 | jnthn++ | src/6model/serialization.c:
21:34 dalek MoarVM: Cope with STable change in repossessed objects.
21:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6535f92e2d
21:34 dalek MoarVM: c6e8df8 | jnthn++ | src/6model/serialization.c:
21:34 dalek MoarVM: Further fixes to repossession.
21:34 dalek MoarVM:
21:34 dalek MoarVM: Now we update the STable, we must take care to repossess all STables
21:34 dalek MoarVM: *before* any of the objects, otherwise we end up with a huge mess of
21:34 dalek MoarVM: re-deserialized STables. Additionally, we update the SC of things we
21:34 dalek MoarVM: repossess at deserialization time.
21:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c6e8df8103
21:34 jnthn timotimo: Well, you can see how I did lexical/lexicalref
21:34 jnthn timotimo: And local/localref will be simpler than that.
21:34 jnthn timotimo: Because you have no late-bound cases to handle.
21:34 timotimo hmm, yeah, compile_var is kind of huge already %)
21:35 jnthn :)
21:35 * dlem bids everybody a nice evening
21:35 dlem See you!
21:35 jnthn you too, dlem o/
21:35 jnthn That second serialization patch took me longer to figure out than it shoulda...
21:35 jnthn Now my "kill PARAMETERIZE_TYPE" work has only one remaining casualty.
21:36 timotimo is that only a correctness patch or does it also improve memory usage or serialized blob size?
21:38 jnthn It's possible we were overly detecting repossessions.
21:39 jnthn So could be a win.
21:39 jnthn Primarily correctness.
21:39 timotimo good, as i thought
21:39 timotimo jnthn++
21:39 kjs_ joined #moarvm
21:39 jnthn It may well fix some other lingering pre-comp bugs
21:40 jnthn (Between the two patches, at least.)
21:40 jnthn Ah, and my last fail is thankfully not serialization related at all
21:40 jnthn It's that ^foo methods don't interact with inheritance.
21:41 jnthn That one I can fix.
21:41 jnthn Probably easily
21:41 jnthn But first, a stroll :)
21:42 timotimo have a good stroll :)
21:46 timotimo so what i'm doing as a first step is add a localrefs and a localref_kinds attribute to BlockInfo as well as the accessor methods
21:47 timotimo hm ,will we ever have contvar localrefs?
21:51 timotimo i'll let %!local_vars_by_index be shared among locals and localrefs, that seems right to me
21:52 timotimo hm, since locals share their namespace with localrefs, why have a separate localref_kind from local_kind?
21:55 timotimo hm, ok, so if something's declared lexicalref and we access it as lexical, we just access the lexicalref and decont it
21:55 timotimo that makes sense; i expect the localref stuff would look the same
22:03 japhb joined #moarvm
22:06 kjs_ joined #moarvm
22:08 timotimo and for _o localref doesn't make sense
22:12 jnthn A lexicalref decl always goes in an _o
22:12 jnthn Same with localref
22:12 timotimo since localrefs behave like containers, i can just use "set" on them to put a value in there?
22:12 timotimo oh? i didn't realize that
22:13 jnthn localref => localref is just a set
22:13 timotimo why do we have %!lexicalref_kinds then?
22:13 jnthn local => local is just a set
22:13 jnthn Because we need to know what kind of native it references
22:14 timotimo getregref is what i do if i have a decl local and access it as localref?
22:14 jnthn Correct
22:14 timotimo ah, you mean the allocated register has an _o because a *ref is an object
22:14 jnthn And in the other direction, decont_[ins]
22:14 timotimo that part i understand
22:14 jnthn Yes
22:14 timotimo good
22:14 jnthn I mean it's an o register for refs
22:14 timotimo and if a BINDVAL is set, i just emit a piece of code to put the value of BINDVAL into the localref
22:15 timotimo or the local, if i have a :decl(local) and access it as localref
22:16 jnthn Note that binding is forbidden in varius cases.
22:16 jnthn You can bind local to local, and you can bind an object to a localref
22:17 jnthn Just follow the lexical[ref] rules for locals too
22:19 * jnthn picks music, a beer, and digs into fixing the last regression from cleaning up parameterization
22:26 timotimo OK
22:50 kjs_ joined #moarvm
22:50 * jnthn waits for the JVM build to get done to see if his port of the serialization fixes will help there also
22:54 timotimo <3
22:55 timotimo now how the hell do i test the codegen? %)
22:56 jnthn Add a test to qast.t? :)
22:57 jnthn oh, though you'll only want ot run it on moar
22:57 timotimo aye
22:57 jnthn So you may want to steal the qast.t approach and then put the test in the t/moar folder
23:12 timotimo my $valmast := self.as_mast_clear_bindval($*BINDVAL, :want($res_kind));
23:12 timotimo (this is for localref, localref)
23:12 timotimo if i want to restrict this to only passing obj
23:12 timotimo would i just put :want($MVM_reg_kind_obj)?
23:12 timotimo and that would appropriately error out if the wrong kind of thing gets passed?
23:13 jnthn $MVM_reg_obj
23:13 jnthn Won't error out, will coerce
23:13 jnthn But that's fine
23:14 jnthn Note that lexicalref code for bind does $MVM_reg_obj there also :)
23:14 timotimo ah
23:19 timotimo i confuse myself all the time
23:51 timotimo am i correct in seeing that there are no lexref tests in qast/ yet?
23:56 jnthn Yeah
23:57 jnthn Partly 'cus I could easily cover it from Rakudo
23:57 jnthn Partly 'cus I had no intention of implementing this stuff on Parrot.
23:57 timotimo OK
23:57 timotimo i have my first test written
23:58 timotimo https://gist.github.com/timo/b68416dedda71b72a458 does it seem like i have the right idea in general?

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