Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-03-15

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

All times shown according to UTC.

Time Nick Message
00:06 vendethiel joined #moarvm
00:25 samcv nice
00:25 samcv any improvement is an improvement
02:03 agentzh joined #moarvm
06:15 domidumont joined #moarvm
06:36 brrt joined #moarvm
06:46 brrt samcv; it's a good question
06:46 samcv brrt, which is a good question?
06:47 brrt why JITting helps, even if the advantage per function is pretty small
06:47 brrt (well, per op)
06:47 samcv ah yeah
06:47 samcv why can't we just JIT everything auto-magically
06:47 brrt hehe
06:47 samcv WHY
06:47 brrt well, there's a good answer to that
06:48 brrt we have a couple hundred ops
06:51 brrt and many of them are de facto C calls
06:51 brrt to JIT them correctly, we need to know what those calls look like
06:51 brrt however, if we have only one op doesn't work, we can't JIT the entire function
06:51 brrt we can't just fall back into interpreting
06:53 brrt perl5 could, as could python, because they can have 'nested interpreters'
06:54 brrt in general, JITting makes running code cheaper mostly by removing the interpretation overhead, which is argubably not the primary source of overhead for a 'dynamic' language
06:56 brrt so the trick, i think, is to be able to represent the code to be interpreted in a way to reduce the effective complexity of code
06:57 domidumont joined #moarvm
07:02 samcv ok so you tell it special hints and info about the function and how it is
07:02 samcv and that allows it to be effectively JIT'd. that makes sense
07:02 samcv otherwise everything would break if you put the wrong things in huh
07:03 samcv is whether it is static or can be affected by other variables part of the info you define?
07:16 brrt well, usually specific ops are just altogether added
07:16 brrt as in, it's entirely possible to 'bail out' JITting in specific conditions
07:17 brrt but it is rare that we do
07:20 brrt (i broke spilling again :-()
07:21 vendethiel- joined #moarvm
07:22 samcv what do we do with spilling. that's about register alocation and moving it from cache to memory right?
07:23 brrt yeah, the 'cache' is the register
07:28 vendethiel joined #moarvm
07:45 samcv how can I try and ensure things don't spill into the cache? Or is that only a problem for VM allocation and stuff
07:46 brrt joined #moarvm
07:46 brrt i found the issue, i guess
08:30 Geth ¦ MoarVM/even-moar-jit: 8f0d36dcf8 | (Bart Wiegmans)++ | 4 files
08:30 Geth ¦ MoarVM/even-moar-jit: MVM_jit_tile_make should take values
08:30 Geth ¦ MoarVM/even-moar-jit:
08:30 Geth ¦ MoarVM/even-moar-jit: MVM_jit_tile is supposed to make it easy to make 'complete' tiles
08:30 Geth ¦ MoarVM/even-moar-jit: inline, so that includes values. Could've chosen to use refs (to the
08:30 Geth ¦ MoarVM/even-moar-jit: tree), but these are used by the register allocator (and only for live
08:30 Geth ¦ MoarVM/even-moar-jit: range determination), whereas values are used by the tile itself.
08:30 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/8f0d36dcf8
09:12 domidumont joined #moarvm
09:33 zakharyas joined #moarvm
10:03 lizmat joined #moarvm
10:53 geekosaur joined #moarvm
12:35 domidumont joined #moarvm
12:40 * dogbert17_ wonders if MasterDuke++ created a MoarVM issue describing the problems with t/spec/S17-promise/nonblocking-await.t that he discovered yesterday
12:40 MasterDuke MasterDuke-- did not
12:41 domidumont joined #moarvm
12:42 MasterDuke dogbert17_: have you started to? if not i can do that now
13:00 MasterDuke dogbert17_, jnthn: written up as https://github.com/MoarVM/MoarVM/issues/554
13:18 dogbert17_ MasterDuke+++ :)
13:19 geekosaur joined #moarvm
14:27 ggoebel joined #moarvm
15:48 timotimo samcv: you don't really have to worry about spilling in your own work; it's just something the register allocator will do for you, just like it would in a C or C++ compiler
15:49 timotimo samcv: also, our current JIT basically spills all registers that were used to memory after every single op
15:59 timotimo (and it can still give you a very strong improvement in performance)
16:12 brrt joined #moarvm
16:33 timotimo brrt: how do you feel about allowing providers of extops to also provide a function that constructs a simple jit graph? like, C function calls only, for example
16:35 timotimo see conversation in #perl6-dev on the trade-off between p6bool making a frame un-jittable and the overhead of ?? !! being potentially bigger than p6bool could do
16:35 brrt let me read that for a bit
16:35 * jnthn wonders why p6bool is unjittable
16:35 brrt that would be awesome
16:36 jnthn We can JIT ext-ops?
16:36 * brrt wonders too
16:36 brrt we can
16:36 brrt we ought to be able at least
16:36 jnthn I mean, we JIT them into C calls to the op bodies, don't we?
16:36 timotimo wait, we can?
16:36 timotimo we already have the functionality for that?
16:36 timotimo big oops %)
16:36 lizmat jnthn: no idea, but it appears that nqp::p6bool is quite a lot slower than ?? True !! False  :-(
16:37 brrt we can and we do
16:37 brrt i'm not sure what the restrictions on p6bool are
16:37 brrt but extops were the first use case for the new data segment
16:38 timotimo yup, it does jit it
16:38 timotimo i spoke way too soon
16:38 brrt hmmm
16:38 timotimo but now, how do we explain the performance discrepancy liz is measuring?
16:38 brrt good question
16:39 brrt (the JIT sucks, haha)
16:39 timotimo is the jit code for that loop really so tight in comparison to a C function call?
16:39 jnthn lizmat: I don't see that
16:39 jnthn $ time perl6-m -e 'use nqp; for ^1000000 { $ = 1 ?? True !! False }'
16:39 jnthn real0m0.838s
16:39 jnthn $ time perl6-m -e 'use nqp; for ^1000000 { $ = nqp::p6bool(1) }'
16:39 jnthn real0m0.830s
16:39 jnthn Pretty much identical
16:40 jnthn And with
16:40 jnthn $ time perl6-m -e 'use nqp; my $x = 1; for ^1000000 { $ = $x ?? True !! False }'
16:40 jnthn real0m0.837s
16:40 jnthn $ time perl6-m -e 'use nqp; my $x = 1; for ^1000000 { $ = nqp::p6bool($x) }'
16:40 jnthn real0m0.786s
16:40 timotimo oh, i have an idea
16:40 jnthn It comes in faster
16:40 lizmat huh?
16:40 lizmat it comes in slower for me
16:40 timotimo hm, no, p6bool is defined on native ints, not on objects
16:40 jnthn OK, doing several runs they basically come out the same within noise
16:41 timotimo not on my machine
16:41 jnthn timotimo: yeah, but the code-gen first does istrue iirc
16:41 timotimo hm, OK
16:41 timotimo for 10_000_000 i get 5.7s vs 6.4s
16:42 timotimo the measurements are not very noisy
16:42 lizmat jnthn: I've used a native int for $x, does that make a difference to you ?
16:42 jnthn 6.766 vs 6.783 for me
16:42 jnthn lizmat: Lemme try
16:43 lizmat the reason I used a native int, is that p6bool is usually used in conjunction with native int values
16:43 jnthn Aha, now I see the difference
16:44 timotimo right, with a non-native variable they are only half a second apart
16:44 jnthn https://github.com/rakudo/rakudo/blob/nom/src/vm/moar/Perl6/Ops.nqp#L277
16:45 jnthn The code-gen there isn't aware of intlexref
16:45 jnthn Well, lexical refs in general
16:45 timotimo that's a good point
16:45 jnthn So that's probably where the discrepancy comes from
16:45 lizmat ah, so the use case for p6bool doesn't use it  :-(
16:45 timotimo i didn't know we had a piece of compiler for p6bool
16:45 timotimo it does use it, because it's forced to
16:46 timotimo it just doesn't understand it could just decont_i or decont_n
16:46 jnthn Not even that
16:46 timotimo so it goes through the general istrue_o
16:46 jnthn I can just do a lexical access
16:46 jnthn *It
16:46 lizmat so it's first boxing the value
16:46 lizmat ?
16:46 timotimo right, it probably creates an *LexRef and will istrue_o that
16:47 timotimo whereas the ?? !! version probably doesn't allocate anything at all
16:47 jnthn Yes, the decont will box
16:47 * lizmat has to be afk again
16:47 jnthn Anyway, good news is we can fix it in one place :)
16:47 timotimo that's something we'd have to implement in the Optimizer, no?
16:47 timotimo hm, no, actually
16:47 jnthn timotimo: No, we can just handle it in p6bool's compilation
16:47 timotimo we do get the qast that has the lexicalref into that function
16:47 jnthn Just case-analyze what we get
16:47 jnthn Yes
16:48 jnthn It'll be a QAST::Var with scope lexicalref
16:48 jnthn In that case we can actually just :want($MVM_reg_int64) when we compile_mast
16:48 timotimo right, so w'll do that before $exprres gets created and twiddle the Var node first
16:48 timotimo oh, ok, no need to twiddle, then
16:48 jnthn And then it'll compile it into a lexical lookup
16:48 jnthn Yeah, I'd rather not twiddle the AST
16:48 jnthn We've been burnt from doing that before
16:49 timotimo i would have twiddled it the same way the nfg tree gets twiddled
16:49 timotimo i.e. create a copy, modify that
16:49 timotimo let me try to whip something up
16:50 jnthn Yeah, but we can do even easier and just pass a :want in :)
16:50 jnthn And then leave the rest of the code the same :)
16:50 timotimo right
16:50 timotimo but we should only do it if we detect an IntLexRef, right?
16:51 timotimo i'm actually not sure how to get at the target lexical from here
16:51 jnthn I'm saying you don't need to
16:51 timotimo like, to figure out if we'll want an int or num or what
16:51 timotimo oh, not at all?
16:52 jnthn Hm, actually maybe you do to know what to :$want
16:52 jnthn I'd do somethin glike
16:52 jnthn my $want;
16:52 jnthn if it's a QAST::Var with .scope eq 'lexicalref'
16:53 jnthn get the objprimspec of the type, aand use that to assign $MVM_reg_int64, $MVM_reg_num64, or $MVM_reg_str to $want
16:53 jnthn Then pass that to compile_mat
16:53 jnthn *compile_mast
16:53 timotimo i'm imagining someone calling nqp::p6bool on, say, 1e100 and we'd asplode with "this num is too big to be boxed into an int"
16:53 timotimo ah, objprimspec is the one i'd want
16:54 timotimo would i grab it from the .returns of QAST::Var?
16:54 jnthn Yeah
16:55 timotimo i feel like i haven't touched qast compiler stuff in ages :|
16:56 jnthn Heh, same for me :)
16:56 jnthn It's not an area where bugs crop up all that often
16:57 timotimo i can make bugs there!
16:57 timotimo ;)
16:57 jnthn :P
17:05 timotimo i got distracted waiting for the build to finish
17:05 timotimo now i'll spectest with my change
17:09 brrt joined #moarvm
17:15 timotimo okay, all spec tests clean except the one that always goes out of order and the subst one
17:16 timotimo i broke it \o/
17:17 timotimo objprimspec isn't compatible with the enum we use for :want ?
17:20 timotimo that's it
17:21 timotimo okay, that closed the performance gap
17:24 timotimo good catch in any case, jnthn :)
17:25 jnthn Well, lizmat++ spotted the perf diff, I just figured out what was going on :)
17:25 timotimo right
17:25 jnthn timotimo++ for fixing it
17:25 timotimo lizmat++ jnthn++ :)
17:26 timotimo depending on the branch you take in p6bool, we'll look up $*REGALLOC between 4 and 6 times; is caching that in a lexical a useless micro-optimization?
17:28 timotimo 5 lookups in p6sink, i expect we call that a bajillion times all in all?
17:28 domidumont joined #moarvm
17:29 jnthn Probably worth it
17:31 timotimo i'll make a pass over Ops.nqp and do a full measurement of the core setting build 10x with and 10x without during my next AFK
17:33 timotimo "regal" in german means "cupboard" or "shelf"
17:34 jnthn Ain't languages fun :)
17:35 * jnthn has tomorrow set aside for doing Perl 6 and Moar stuffs
17:35 [Coke] nine.
17:35 jnthn ten!
17:36 * jnthn goes to rest a bit :)
17:39 timotimo timings will now commence (and i'm AFK)
17:43 brrt joined #moarvm
17:54 brrt joined #moarvm
18:19 timotimo barely noticable, but statistically significant
18:24 timotimo 0.02s or something
18:35 timotimo interesting. on the nqp side of things, there's already a whole lot of "my $regalloc := $*REGALLOC" in QASTOperationsMAST
18:37 timotimo in moarvm's irclog search i only found a timtoady gist from 2 years ago about dynamic var lookup stats
18:38 timotimo ah, perl6-dev has one from a month ago
18:38 timotimo there regalloc only accounts for like 0.25% of time
18:40 timotimo i could put up the changes for $REGALLOC in a branch in case the dynamic var cache gets made 100x slower or something :P
18:44 domidumont joined #moarvm
19:39 samcv good *
19:51 ggoebel joined #moarvm
19:52 lizmat joined #moarvm
20:45 domidumont joined #moarvm
21:15 jnthn o/ samcv
21:20 Geth ¦ MoarVM/master: 6 commits pushed by (Samantha McVey)++, (Jonathan Worthington)++
21:20 Geth ¦ MoarVM/master: 9b74782c86 | Remove unneeded variable in MVM_string_index
21:20 Geth ¦ MoarVM/master: b625a9a19f | Add MVM_string_index_ignore_case function
21:20 Geth ¦ MoarVM/master: 9ac5314697 | Set update_ops.p6 as executable and add perl6 shebang
21:20 Geth ¦ MoarVM/master: 1a5ee0da6d | Add indexic_s Op, calls MVM_string_index_ignore_case
21:20 Geth ¦ MoarVM/master: e05f396032 | Use MVMROOT to make sure we don't GC haystack or needle
21:20 Geth ¦ MoarVM/master: 6954d2033f | Merge pull request #550 from samcv/indexic_s
21:20 Geth ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/b8aa33dfb9...6954d2033f
21:21 colomon_ joined #moarvm
22:03 timotimo yo samcv
22:47 samcv yo
22:50 samcv should be fine building with local repos for everything but libtommath right?
22:51 samcv using --has-libffi --has-libatomic_ops --has-libuv --has-dyncall atm
22:52 timotimo it should be erroneous to have both libffi and dyncall in the configure line
22:52 timotimo it doesn't make sense to have more than one of those two
22:53 samcv well those flags only tell it to use locally installed versions instead of the moarvm provided ones right
22:53 samcv or maybe i'm wrong
22:53 timotimo hm, maybe
22:53 timotimo i didn't do much inside Configure.pl
22:54 samcv which one is the default? or best, do we have backends for both libs or something?
22:55 timotimo yeah, we have a little wrapper for each of those
22:55 timotimo these wrappers both have the same API that the rest of moarvm then uses
22:56 samcv https://github.com/MoarVM/MoarVM/issues/183
22:56 samcv so i guess dyncall is the preferred one
22:57 jnthn So far as I remember, they don't support completely overlapping sets of platforms
22:57 samcv libs: -lffi -L/usr/lib/../lib -lffi  -latomic_ops -L/usr/lib/../lib -lffi  -luv -L/usr/lib/../lib -lffi  -lm -lpthread -lrt -ldl
22:57 samcv well
22:58 samcv so i guess i've been using libffi
22:58 timotimo right, platform support is the reason why we even pulled libffi in
22:58 timotimo we used to have only dyncall, which is also what parrot had
23:01 timotimo grrr
23:02 timotimo i'm getting python errors but no apparent way to figure out where they originated
23:06 timotimo print("sizeclass " + sizeclass + " being analyzed")
23:06 timotimo TypeError: Can't convert 'int' object to str implicitly
23:06 timotimo has this always been like that?
23:07 geekosaur apparently yes
23:08 geekosaur python isn't perl
23:08 geekosaur (arguably you can depend on python doing what perl doesn't...)
23:12 agentzh joined #moarvm
23:17 timotimo okay, getting the errors from trying to stringify a string that contains ropes
23:18 timotimo someone needs to rewrite this code
23:29 vendethiel- joined #moarvm
23:29 samcv is this with python only or inline::python?
23:29 timotimo python only
23:29 timotimo we'd need inline.perl6 to make this bearable ;)
23:30 samcv so python is broken? lol
23:30 timotimo huh?
23:30 samcv <timotimo> okay, getting the errors from trying to stringify a string that contains ropes
23:30 samcv that was refering to python or perl6?
23:30 timotimo let me show you
23:31 timotimo https://github.com/MoarVM/MoarVM/blob/master/tools/moar-gdb.py#L180-L205
23:31 timotimo this is what's broken
23:53 samcv ah
23:54 samcv makes sense now
23:54 timotimo i don't think it was ever correct, either
23:55 timotimo i think it gave off-by-ones all the time :P
23:57 timotimo for the time being i turned it off and put the address of the string into the histogram
23:58 brrt joined #moarvm

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