Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-01-11

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

All times shown according to UTC.

Time Nick Message
00:31 vendethiel joined #moarvm
00:59 ggoebel7 joined #moarvm
01:03 vendethiel joined #moarvm
02:49 ilbot3 joined #moarvm
02:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:34 leedo joined #moarvm
04:08 vendethiel joined #moarvm
07:44 FROGGS joined #moarvm
07:48 domidumont joined #moarvm
07:54 domidumont joined #moarvm
08:02 zakharyas joined #moarvm
08:18 dalek MoarVM: 94b1b63 | FROGGS++ | README.markdown:
08:18 dalek MoarVM: state that gcc on Windows® works too
08:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/94b1b636b0
08:59 vendethiel joined #moarvm
09:35 virtualsue joined #moarvm
09:46 brrt joined #moarvm
09:51 vendethiel joined #moarvm
10:36 vendethiel joined #moarvm
10:59 vendethiel joined #moarvm
11:02 brrt_ joined #moarvm
11:09 virtualsue joined #moarvm
11:17 virtualsue joined #moarvm
12:08 virtualsue joined #moarvm
12:27 vendethiel joined #moarvm
12:38 virtualsue joined #moarvm
12:40 leont joined #moarvm
12:42 vendethiel- joined #moarvm
12:53 ilbot3 joined #moarvm
12:53 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
13:08 vendethiel joined #moarvm
13:58 vendethiel joined #moarvm
14:36 virtualsue joined #moarvm
14:46 vendethiel joined #moarvm
15:50 vendethiel joined #moarvm
16:31 vendethiel joined #moarvm
16:34 virtualsue joined #moarvm
16:54 vendethiel joined #moarvm
17:06 kjs_ joined #moarvm
17:18 kjs_ joined #moarvm
17:19 vendethiel joined #moarvm
17:47 * jnthn is back home, after a 5 hour trip that turned into an 11 hour trip... :/
17:47 timotimo bleh. damn those planes
17:48 kjs_ joined #moarvm
17:48 jnthn Yeah...
17:48 jnthn 6 hour delay on a 2 hour flight
17:50 TimToady welcome home, anyway
17:50 jnthn Yes, nice to be back...and to be staying here for a good while :)
17:51 leont I know that feeling :-(
17:51 * TimToady understands completely, having been right on the ragged edge over the holidays himownself
17:52 leont "You have 5 hours delay, here is a €10 coupon, it can almost buy you a decent breakfast"
17:53 jnthn Wow, you got a coupon!
17:53 jnthn At least KBP has free wifi... :)
17:53 patrickz joined #moarvm
17:55 jnthn Anyways, tomorrow will be swallowed by recovering from the journey, visiting lawyer, and most likely a tedious but important errand.
17:55 jnthn And after that I'll probably start to ease myself back into things...slooowly. :)
17:55 timotimo +1 on the "sloooowly" bit :)
17:56 timotimo do you already have a list of "things i'd love to optimize first"? ;)
17:57 jnthn Well, -Ofun will probably be doing some stuff down at Moar level :)
17:58 timotimo how -Ofun does it feel to guide me while i'm hopelessly bumbling around at the NQP level? :P
17:58 jnthn (Improving invocation performance, looking at using PICs for type data collection, showing spesh/JIT work off to a background thread, etc.)
17:58 jnthn *shoving
17:59 timotimo right now, spesh/jit only accounts for sub 10% on most workloads i've tried :P
17:59 jnthn I've not really kept up at all with what's happened in the last weeks. :)
17:59 jnthn Hey, we're normally happy with 10% ;)
18:00 jnthn I was pondering that thread being a general "service" thread and pushing finalization off to it also.
18:00 jnthn To get GC times down some.
18:00 timotimo ah, yes, finalization
18:00 jnthn Anyway, no shortage of ideas, at least... :)
18:00 timotimo aye
18:01 timotimo i was hoping i could perhaps tackle the "lexical refs prevent inlining" problem
18:02 jnthn Having spent the last however many months mostly chasing semantic bugs down ahead of 6.c, I'd be quite happy to be focusing on something other than that for a bit, anyways. :)
18:02 timotimo but i have not looked at the code actually yet
18:02 timotimo yeah, definitely
18:03 jnthn (lexicalref) Yeah, that's a cop out. :) The point was that inlining of things getting passed them can often make them go away :)
18:03 timotimo i had been looking at a little benchmark of a eratosthenes sieve and using Int was faster than int
18:03 jnthn But it was a bit tricky to get the analysis right, let alone the transform. :)
18:03 jnthn So it got punted.
18:04 timotimo you mean the analysis and transform inside spesh?
18:04 jnthn Yes
18:05 timotimo right; for an operator that doesn't "is rw" in the argument list, though, it'd be lovely if we didn't take a ref
18:05 jnthn yeah, indeed :)
18:05 timotimo the "Int" version had things like <, + and such inlined, the int version ... nothing at all :|
18:06 jnthn There's plenty of inter-routine even-when-we-don't-inline info that it'd be nice to ponder
18:06 timotimo oh, would we need such a mechanism to say "we don't have rw in the signature"? i thought it'd be accessible by the same parts the inliner looks at anyway
18:07 vendethiel joined #moarvm
18:07 jnthn Not sure it'll be a complex mechanism, I just think it's worth formalizing a little how it's done.
18:07 jnthn Escape analysis might want such things :)
18:07 timotimo ooooh
18:07 timotimo but that's spesh-level, not qast level
18:08 timotimo which is where i'm looking right now
18:11 jnthn Ah
18:11 timotimo er, "looking right now" is ... overpromising
18:11 jnthn Well, Rakudo's inliner should really be inlining ==, <, > and the like on native ints.
18:11 jnthn It was a one point, I thought. Maybe we lost that.
18:12 timotimo yeah, it stopped doing that when we introduced lexicalrefs
18:12 timotimo i thought i whined about it often enough? ;)
18:12 jnthn Um...yeah, you did, I ignored it 'cus my plate was full
18:12 jnthn Now it's...uh...well, folks didn't fill it up again yet :P
18:13 timotimo :D
18:13 timotimo bbiab
18:13 timotimo as i said, i'm hoping i could maybe make it work again, but it'll definitely require a bit of guidance
18:14 timotimo this time around i'll try to only ask you when i've rubber-ducked someone else, so i don't bug you more than necessary
18:15 jnthn It's something we'd really like to get working again :)
18:23 patrickz joined #moarvm
18:27 JimmyZ welcome back, jnthn :)
18:33 timotimo jnthn: is there any reason to keep takeclosure calls "as early as possible" rather than putting them "as late as possible"?
18:45 timotimo i should make a measurement if it actually makes a difference in the cases i'm thinking of
18:54 kjs_ joined #moarvm
18:55 TimToady joined #moarvm
19:00 JimmyZ jnthn: http://irclog.perlgeek.de/moarvm/2016-01-08#i_11853242 # Do we need to re-order it?
19:01 vendethiel joined #moarvm
19:05 domidumont joined #moarvm
19:11 [Coke] (optimizations) I don't know how hard it would be to test optimizations (and where does it make sense to test them? a separate test suite run by rakudo but owned by moar?), but if we don't test, we'll backslide again.
19:12 [Coke] (make opttest in rakudo that works like spectest but on a different repo)
19:19 timotimo it'd seem like we'd need a flag for every optimization to turn it on or off? or would it be enough to test --optimize=0 vs --optimize=3 ?
19:19 timotimo some optimizations depend on others, too
19:20 [Coke] we could go the compiler route (give everything a command line switch) or the friendly route (we know what works together, here's a few simple options).
19:21 [Coke] I lean towards few options, because then we can cheat.
19:47 dalek MoarVM: 2c69687 | (Jimmy Zhuo)++ | src/core/oplist:
19:47 dalek MoarVM: mark flattenropes, graphs_s and codes_s as DEPRECATED
19:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2c6968783d
19:48 jnthn Ain't the regex engine using flattenropes?
19:48 JimmyZ jnthn: I found it's needless
19:49 jnthn Why?
19:49 kjs_ joined #moarvm
19:49 jnthn The regex engine could do with strings it can cheaply scan
19:50 JimmyZ jnthn: because before chars op don't need call flattenropes op
19:50 jnthn ??
19:50 jnthn That's entirely not the point of it.
19:51 jnthn The point is to turn the string into a flat buffer that's really cheap to index into.
19:51 timotimo jnthn: could this be the right place to look? https://github.com/rakudo/rakudo/blob/nom/src/Perl6/Metamodel/BOOTSTRAP.nqp#L1021  -  perhaps here i'd have to check for int or intref and so on?
19:51 jnthn What replaces graphs_s and codes_s?
19:51 jnthn Is graphs_s just a dupe of chars?
19:51 JimmyZ jnthn: yes
19:52 jnthn And codes_s?
19:52 JimmyZ and codes_s not used anywhere
19:52 jnthn Rakudo really should be using it for .codes
19:52 jnthn I wonder how it implements that today...
19:52 timotimo isn't _s usually the one that has a literal string argument?
19:53 jnthn No, just means "works on a string"
19:53 timotimo ok
19:53 jnthn const_s works that way
19:53 timotimo ah
19:53 jnthn Anyway, I think the only one of those deprecations I agree with is graphs_s
19:53 jnthn Which it turns out is a dupe...probably.
19:53 JimmyZ https://github.com/perl6/nqp/commit/3af6e6f49d
19:53 jnthn JimmyZ: Rejected.
19:53 JimmyZ jnthn: see ^^^
19:54 jnthn Yes, graphs_s can go
19:54 JimmyZ jnthn: and I found codes_s is not used even in nqp and rakudo
19:54 jnthn But flattenrpoes stays
19:54 jnthn Yes, but you're noticing things and then drawing dumb conclusions.
19:55 jnthn multi method codes(Str:D:) returns Int:D {
19:55 jnthn #?if moar
19:55 jnthn self.NFC.codes
19:55 jnthn That should really use codes
19:55 jnthn We just didn't get around to doing that.
19:55 JimmyZ jnthn: so codes_s will be useful, but not now?
19:55 jnthn Right
19:56 jnthn And flattenropes is useful now.
19:56 jnthn Consider ($foo ~ $bar) ~~ /.../
19:57 timotimo flattenropes means we can't regex-match things created with the x operator without allocating lots of memory?
19:58 jnthn timotimo: You can't rely on that anyway
19:58 timotimo OK
19:58 jnthn And it's a bit contrived
19:59 jnthn Whereas "I just concatenated some things together I got in over a socket, and want to see if I can parse out a full message" is pretty common
19:59 JimmyZ jnthn: why not move flattenropes code to chars op, since we may do nqp::chars($foo ~ $bar);
19:59 jnthn Why could we do that?
20:00 jnthn We already keep the number of chars cached
20:00 jnthn We don't need to flatten
20:00 jnthn Anyway, the answer is no, flattenropes stays.
20:00 jnthn As does codes_s
20:00 timotimo a quick comment about my link above, jnthn?
20:01 timotimo m: my int $foo; sub test(int $a is rw) { say $a.WHAT }; test($foo);
20:01 camelia rakudo-moar 42a583: OUTPUT«(Int)␤»
20:01 timotimo how did i get IntLexRef from .WHAT again ...
20:01 jnthn It'd have to be .VAR.WHAT I think
20:01 JimmyZ jnthn: ok, I just can't understand it :P , from https://github.com/perl6/nqp/commit/3af6e6f49d , flatten $tgt is only used by chars op
20:01 timotimo oh, of course
20:02 timotimo m: my int $foo; sub test(int $a is rw) { say $a.VAR.WHAT }; test($foo);
20:02 camelia rakudo-moar 42a583: OUTPUT«(IntLexRef)␤»
20:02 timotimo m: use nqp; my int $foo; sub test(int $a is rw) { say $a.VAR.WHAT; say nqp::isint($a); say nqp::isint($a.VAR) }; test($foo);
20:02 camelia rakudo-moar 42a583: OUTPUT«(IntLexRef)␤0␤0␤»
20:02 timotimo neither of those give 1 for isint?
20:02 jnthn JimmyZ: Note that it flattens in-place.
20:03 jnthn timotimo: No, since that's more about "can I unbox it to a native int" or so
20:04 timotimo does "that" refer to isint or the link to trial_bind i put in the channel?
20:04 JimmyZ jnthn: http://irclog.perlgeek.de/moarvm/2016-01-08#i_11853242 # Do we need to re-order it?
20:04 jnthn timotimo: isint
20:05 timotimo OK; that'd mean isint isn't enough for the trial binder, because if there's an is rw, it won't ever give 1
20:05 timotimo but i'm not sure what's the right wording to make it acceptable. is istype IntLexRef correct?
20:05 jnthn JimmyZ: Well, I'd been keeping it ordered partly 'cus I was concerned about whether compilers would be smart enough to realize it can become a jump table if we out-of-order it, and partly 'cus it just seemed sensible. It may be worth checking if the first is true.
20:06 timotimo hm. more something like is its archetype lexref and its nativetype the right one
20:06 jnthn (I don't know; I'd hope MSVC is good enough for it not to matter, for example)
20:06 jnthn (And GCC/Clang use computed goto...)
20:07 JimmyZ jnthn: I tested it, MSVC is good enough
20:07 jnthn OK, good to know.
20:07 jnthn Well, and bad in that we don't get a cheap MSVC speed-up :P
20:07 jnthn Anyway, don't feel strongly on it
20:07 JimmyZ not sure about tinycc etc
20:08 jnthn If somebody patches them to fix the ordering, I'm fine with that. But I'm not going to rush to do it myself :)
20:08 timotimo mhh, that's a clever one-liner for finding out the ordering
20:09 dalek MoarVM: 4f86f20 | (Jimmy Zhuo)++ | src/core/oplist:
20:09 dalek MoarVM: some ops won't be DEPRECATED
20:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4f86f20f2b
20:10 JimmyZ 04:09 here ,good night
20:10 jnthn JimmyZ++ # thanks
20:10 jnthn 'night o/
20:10 timotimo gnite JimmyZ
20:11 jnthn Time for a stroll, after all day cooped up in an airport...then probably rest. :) Will be about a bit tomorrow, I expect. :)
20:12 timotimo sure
20:12 timotimo have a good one!
20:49 patrickz joined #moarvm
22:48 hoelzro Frame_N in a MoarVM dump roughly corresponds to an MVMFrame deserialized by deserialize_context, right?

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