Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-06

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

All times shown according to UTC.

Time Nick Message
04:02 FROGGS__ joined #moarvm
06:02 dalek joined #moarvm
06:28 dalek joined #moarvm
07:27 nwc10 timotimo: yes, t/nqp/59-nqpop.t already had the relevant test
07:39 nwc10 which is now failing on MoarVM (rather than causign ASAN to barf)
07:47 nwc10 so (obviously) something still isn't quite right
07:47 nwc10 and I'm not 100% certain what is truth, and what the bug is
07:58 Ven joined #moarvm
08:05 oetiker_ joined #moarvm
08:06 oetiker joined #moarvm
08:12 Ven joined #moarvm
08:34 salva joined #moarvm
08:45 zakharyas joined #moarvm
08:46 timotimo oh, let me see
08:47 nwc10 I assume that parrot and the JVM pass that test, but I've not tested this. Nor have I looked at the docs to figure out whether the test is consistent with them
08:47 nwc10 but it's, um, interesting (and slightly troubling) that what feels like rather basic NQP behaviour wasn't tested.
08:47 nwc10 *or* tickled by anything later
08:49 timotimo yeah, that value is certainly wrong
08:50 nwc10 I'm glad that you've got more headspace to investigate this issue than I have.
08:50 zakharyas1 joined #moarvm
08:51 timotimo it seems like a part of the code expects the start argument to be where it starts from, going leftwards
08:51 timotimo and the test seems to think the start is where it should go to from the right
08:51 timotimo the docs say "Begin searching at $pos if specified, otherwise start from the last position."
08:52 kjs_ joined #moarvm
08:52 nwc10 The perl 5 tests for rindex are in http://perl5.git.perl.org/perl.git/blob/HEAD:/t/op/index.t
08:53 nwc10 not sure if there's anything useful to steal from there
08:53 nwc10 because the docs do sound a bit under-specified.
08:53 nwc10 but I need to figure out if I'm about to screw up git filter-branch
08:54 timotimo well, git filter-branch will always let you go back to the way it was before with the git reflog
08:54 nwc10 yes, but the filter might take an hour, so I'd prefer to maximise my chance of getting it right
08:54 zakharyas1 joined #moarvm
08:55 timotimo hah
08:55 timotimo i was looking at an index test
08:55 timotimo and not an rindex test
08:55 timotimo clever me
08:55 nwc10 use more 'coffee'?
08:58 timotimo and now i've been using -e ' ... ' and inside the code there were ' ' already, which my shell ate
08:58 timotimo so it was comparing NQPMu with NQPMu
08:59 dalek MoarVM: 7bb98ef | timotimo++ | src/strings/ops.c:
08:59 dalek MoarVM: starting too far right isn't automatic -1
08:59 dalek MoarVM:
08:59 dalek MoarVM: but we do have to cap the index to a rightmost maximum.
08:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7bb98ef663
08:59 timotimo ^- test fixed, logic restored
09:05 nwc10 timotimo++
09:05 nwc10 timotimo++
09:11 donaldh joined #moarvm
09:40 virtualsue joined #moarvm
09:45 brrt joined #moarvm
09:45 brrt \o
09:57 dalek MoarVM: cd85ea1 | nicholas++ | src/6model/reprs/P6bigint.h:
09:57 dalek MoarVM: In the P6bigint body union, the flag most only be first for 64 bit Big Endian.
09:57 dalek MoarVM:
09:57 dalek MoarVM: The intent is that the flag value (0xFFFFFFFF) is in the lower 32 bits of the
09:57 dalek MoarVM: function pointer. On 64 Big Endian systems, the existing code implemented this
09:57 dalek MoarVM: correctly, by storing the 32 bit value first, the 32 bit flag second. But for
09:57 dalek MoarVM: 32 bit Big Endian systems the flag must come first (just like all Little
09:57 dalek MoarVM: Endian systems), because otherwise the 32 bit value and 32 bit pointer share
09:57 dalek MoarVM: the same memory, and writing the flag doesn't cause set the lower bits of the
09:57 dalek MoarVM: pointer)
09:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cd85ea127d
09:58 jnthn o/ brrt
10:03 FROGGS nwc10: all your patches are applied now?
10:04 nwc10 I *think* so.
10:04 nwc10 I was confused earlier.
10:05 brrt \o jnthn :-)
10:05 brrt (WINDOWS OMG :-o)
10:05 brrt they call it a 'server edition' even
10:07 jnthn Just wait for MoarVM Enterprise Edition :P
10:07 nwc10 MEE too
10:07 nwc10 Rewrite 6ae0c1f808dc44ea9bbf9b0b41fb14cb9427e271 (40820/40820)
10:07 nwc10 ...
10:07 nwc10 real    55m34.943s
10:08 nwc10 (being my rewrite)
10:08 nwc10 user    13m8.229s
10:08 nwc10 sys     26m52.721s
10:08 nwc10 that was the git filter-branch at work that I said would take a while.
10:08 timotimo not bad, an hour!
10:08 nwc10 that was only an env-filter
10:08 nwc10 the tree based one took 5 hours on fewer commits.
10:08 timotimo phew
10:08 jnthn Wow
10:09 nwc10 I forget whether I did that on my desktop (SSD) on the dev box (older, and I believe spinning rust)
10:09 jnthn 5 horus is a heck of a lot
10:09 nwc10 it's the main chunk of work history, from 2006
10:09 timotimo if you have enough RAM, the hard drive doesn't matter ;)
10:09 timotimo and if you "git fsck" first, everything will be compressed into packed, indexed files
10:10 nwc10 I was feeling rather wary of any of that, because partly I'm doing it to get rid of a bunch of grafts
10:10 timotimo ah
10:10 timotimo fair enough
10:11 timotimo maybe git fsck has a "dont-delete-anything" mode for just compressing stuff ;)
10:11 nwc10 I assume that it wouldn't have screwed up
10:11 nwc10 but the local checkout will go away at some point
10:12 nwc10 so I wasn't worried about *it*
10:15 brrt (lol @ MoarVM Enterprise Edition)
10:17 timotimo well, there's commercial JVMs that have some extra optimizations or tunings or support or something
10:18 nwc10 I'm only aware of one offhand: http://www.azulsystems.com/products/zing/whatisit
10:18 nwc10 but this is not anything I track carefully.
10:19 brrt anyway, i'm not sure if this is a proper time to discuss it, but how badly do we (= the community) want JIT improvements for MoarVM?
10:19 brrt and also, which JIT improvements do we want most?
10:19 nwc10 on that, I think, get the x86_64 JIT reasonably good before considering any other
10:20 brrt i agree
10:20 nwc10 (and ARM is a more logical second than x86)
10:20 brrt i also agree on that
10:20 nwc10 I think you said that right now it does a lot of pointless loads and stores
10:20 brrt yes
10:20 nwc10 because the infrastructure can't cope
10:20 brrt if you wish, i could probably show you a sample
10:20 nwc10 I think getting them out feels like the first "big project"
10:20 brrt it's also a very large project since it'd be a rewrite in a sense
10:20 nwc10 I don't know x86_64 (itself) so I'm happy to take it as a given
10:20 brrt do you know x86?
10:21 nwc10 no
10:21 nwc10 ARM
10:21 brrt x86_64 is basically the same just with larger registers
10:21 brrt well, there's very little magic about it (i find that very nice about asm in general)
10:21 nwc10 can you hand edit enough JIT code to give a number (or numbers) for what sort of speedup it woudl give?
10:21 brrt hmm
10:21 brrt that would not work, i think
10:22 brrt or i should make specially contrived examples
10:22 nwc10 it would be very useful for any sort of grant prospoal
10:22 nwc10 "somewhat real world" usually stands up best
10:22 brrt but the JIT inserts pointers to run-time constants
10:22 nwc10 and "grant proposal" is an answer to "how much"
10:22 brrt right
10:24 brrt in my ideal scenario, having a more machine-reified representation would also make it possible / easier to efficiently implement all sorts of jit level type optimisations
10:26 timotimo i've still got no idea how we'll make NativeCall representation/invocation friendlier to the JIT ...
10:27 timotimo at the moment we're not even speshing anything close to the piece of code that contains the "nativecallinvoke" operation
10:27 brrt well, my simple suspicion is that you'd convert the nativecallinvoke operation to a MVMJitCall node
10:27 brrt prefixed by any number of pre-conversions
10:27 timotimo yeah, but we can't reach it yet
10:27 brrt hmm
10:28 brrt but to be honest i have no idea how nativecall is currently implemented
10:28 timotimo don't worry too much about this; it's probably something jnthn might have a design for
10:30 jnthn I think we hang it off invokespec
10:30 timotimo in perl6 land we compose a role with a native callsite box target onto a sub or method and implement the postcircumfix:<( )> method to nqp::nativecall on self and its configuration
10:30 brrt but that brings me back to my earlier point....
10:30 timotimo "we hang it" or "we should hang it"?
10:30 jnthn We should hang it :)
10:31 jnthn We have it easy now, though. NativeCall lives in the Rakudo repo
10:31 jnthn So we can do these kinds of changes without too much upheavel.
10:31 timotimo hm, where does extra data go for invocation specs and such?
10:31 brrt we need (or should i say, the JIT would need) a better representation to easily represent such things
10:31 brrt in the REPR i think?
10:32 jnthn Well, the invoke stuff hangs off the STable
10:32 jnthn But you can keep the information itself inside of the NativeCall REPR as is the case today
10:32 jnthn The invoke spec is the linkage between the two, but it makes "this is a native call, look at it" less opaque
10:33 timotimo OK, so we'll be invoking an object that boxes a NativeCall repr'd MVMObject?
10:34 FROGGS we are not invoking it directly, arnt we?
10:34 jnthn timotimo: We already are, but then we have a method postcircumfix:<( )> level of indirection in the way
10:34 jnthn Note that we still do need something like that
10:34 timotimo yeah, i was sketching out, in my mind, how we'd get rid of the postcircumfix:<( )> in the middle
10:34 FROGGS we have a native callsite, pull out libname, symbol, params and return type, and then make the call using dyncall
10:34 jnthn It needs to look like indy in that sense: a callsite that you do setup work on the first time, and then update the callsite
10:35 jnthn And of course, we dont JIT/spesh until stuff is hot
10:35 jnthn So by the time we do those things, it'll already have been set up
10:35 jnthn That's the way multi call spesh works, btw: the unoptimized, interpreted code primes the caches, and spesh just looks at those.
10:36 jnthn On JIT stuff in general, I agree largely with brrt that we need an extra step in there that lets us produce much better machine code.
10:37 brrt i'm not *entirely* sure how to represent that just yet
10:37 jnthn *However*, I'd be inclined to split the work into: 1) design/build the new JIT expression tree thingy, 2) switch over to using it in the simplest way possible, still emitting the loads and stores we do today, to make sure it works at all, then (3) take advantage of it
10:38 brrt fwiw, i mentally resolved the LLVM discussion by noting that LLVM is very far removed from either MoarVM bytecode and (any) machine code, and thus not very ideal to represent the moarvm jit in
10:38 jnthn So that it's not One Huge Rewrite where all the bugs in all the things have to be found together
10:38 * brrt nods
10:38 brrt that is basically the root of my plan too, to allow the expression trees to be 'just nodes' in the whole graph
10:39 jnthn That's kinda even better, perhaps :)
10:39 brrt and then to gradually convert all the nodes into the tree
10:39 jnthn *nod*
10:39 brrt but that may be easier said than done
10:39 jnthn Just need to be careful when you optimize about 1) GC safe points, and 2) deopt points
10:40 brrt optimization is still very far away as far as i see it now
10:40 jnthn Well, I mean more eliding the loads/stores
10:40 brrt right, yeah
10:40 jnthn Some of them matter for correctness.
10:40 brrt that's not conceptually hard to do though, since you already have to track the location of each variable
10:40 jnthn *nod*
10:41 jnthn Getting it wrong does lead to really hard bugs.
10:41 * brrt nods with intense agreement
10:42 brrt as far as my availability goes, i think i'll be fully available after may, at least until august and maybe further; also quite unable to go on a holiday
10:42 timotimo i'd still like to find a good design for code that gets triggered by deopt points
10:42 kjs_ joined #moarvm
10:43 timotimo maybe a "store deopt target and branch" and later a "load deopt target and do the deopt" would bracket the code
10:44 brrt timotimo, please elaborate
10:44 jnthn brrt: Then probably we should get rolling with a grant app in April, so it's ready by end of May
10:44 brrt ok, that's a good idea
10:45 timotimo brrt: currently, a bunch of registers are being kept alive by a requirement to have the proper value set in them at the time a deopt point is hit
10:46 timotimo brrt: but often, those registers just contain a copy of the value of another register, because that's what the original code-gen made and after deopt all registers have to be proper
10:46 * jnthn figures he really better spend some time writing his slides...which are about time...
10:46 timotimo jnthn: Gutes Gelingen! :)
10:46 brrt again presenting? :-)
10:46 brrt ah, i see
10:47 rurban joined #moarvm
10:47 brrt that seems like a tricky thing
10:47 brrt but on the other hand, one that would be doable at spesh time, no?
10:47 timotimo yes
10:48 timotimo at some points, spesh will keep const_s calls in the code just because the deopt'd code expects a string constant in a register
10:48 timotimo and world object lookups, too
10:51 jnthn Note it only does it *if* the thing is used the other side of a deopt boundary
10:52 timotimo oh? how do we figure that out?
10:52 brrt via the ssa i guess
10:52 brrt or
10:52 brrt whait
10:52 brrt wait
10:52 brrt hmmm
10:52 timotimo hm. well, the SSA at the time when we do the facts discovery actually just represents the original code
10:52 brrt do we have a used_after flag or something? that would backpropagate
10:52 timotimo so that *would* work, hmm.
10:54 timotimo hm. there's a "facts->deopt_idx == current_deopt_idx" in there that decides between whether to up the usage by 1 or 2 per actual usage
10:54 timotimo maybe that ought to be <= instead of ==?
10:54 jnthn The trick is actually that we boost usage counts
10:54 jnthn However, some guards go unused
10:55 jnthn And I think at present we don't go back and decrement usage counts again when a guard is unused.
10:56 timotimo oh, that could be something
11:04 dalek Heuristic branch merge: pushed 27 commits to MoarVM/cpp by FROGGS
11:05 * brrt lunch &
11:10 zakharyas joined #moarvm
11:38 colomon joined #moarvm
11:39 Ven joined #moarvm
11:55 kjs_ joined #moarvm
13:01 kjs_ joined #moarvm
13:04 Ven joined #moarvm
13:16 timotimo how do we feel about a configure option for moarvm that activates --march=native?
13:17 kjs_ joined #moarvm
13:20 brrt joined #moarvm
13:22 brrt what does march=native do?
13:23 timotimo it enables a few optimizations for your specific CPU and also sets the cache size to optimize for to what your machine has
13:25 brrt ah, ok :-)
14:25 kjs_ joined #moarvm
14:43 FROGGS[mobile] joined #moarvm
15:18 njmurphy joined #moarvm
15:31 kjs_ joined #moarvm
15:58 [Coke] (grant proposal) as a TPF GC member, I'd love to see some perl 6 grant requests come in. (backlogging)
15:59 jnthn That might be the first time somebody used GC on this channel and didn't mean Garbage Collector... :)
15:59 jnthn [Coke]: Is there some timing on the TPF side we should be aware of?
16:01 [Coke] jnthn: it has changed recently, one moment.
16:01 [Coke] http://www.perlfoundation.org/rules_of_operation - every two months.
16:02 jnthn [Coke]: Mostly, if brrt++ was intersted in a grant for doing stuff in June..August, when do we need to apply... :)
16:02 [Coke] there may also be Hague grant dollars left, that's outside my zone.
16:02 jnthn Ah, eval process in May
16:02 jnthn [Coke]: Sure, guess it's nice TIMTOWTDI :)
16:57 flussence for anyone curious about what march=native does *exactly* - https://gist.github.com/flussence/176895499d7211ee1cce
17:22 donaldh joined #moarvm
18:23 kjs_ joined #moarvm
18:53 kjs_ joined #moarvm
18:56 vendethiel joined #moarvm
19:47 kjs_ joined #moarvm
20:33 rurban joined #moarvm
20:40 kjs_ joined #moarvm
21:50 kjs_ joined #moarvm

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