Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-14

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

All times shown according to UTC.

Time Nick Message
01:32 FROGGS_ joined #moarvm
06:12 sergot morning o/
06:47 FROGGS joined #moarvm
07:06 zakharyas joined #moarvm
08:57 jnthn o/
09:04 moritz joined #moarvm
09:17 timotimo morning
09:19 moritz moarning
09:27 lizmat joined #moarvm
09:28 jnthn moaning
09:29 nebuchad` joined #moarvm
10:08 FROGGS joined #moarvm
10:20 timotimo did brrt say he'd have a 4-day-weekend?
10:22 jnthn Not that I remember. Well, he was about here on Friday at least. :)
11:28 brrt joined #moarvm
11:28 brrt \o
11:30 jnthn o/ brrt
11:30 brrt wow, timotimo++ 's been busy
11:31 brrt do you happen to know if pop_o and pop_s etc... are invokish?
11:32 jnthn No, they're not
11:32 jnthn REPR ops can never invoke
11:32 brrt ok, awesome
11:32 jnthn That's a 6model design rule for a long time :)
11:33 jnthn (Which serves us nicely :))
11:34 brrt yes, it does, certainly here
11:34 * brrt is trying to renember which ops were in fact invokish
11:34 brrt smrt_*ify at least
11:36 jnthn if_o, unless_o, smrt_*, istrue, isfalse, decont, assign, assignunchecked
11:36 brrt only these?
11:37 jnthn Well, those stand out to me glacning oplist
11:37 jnthn *but*
11:37 jnthn A bunch of ops can also throw exceptions.
11:37 timotimo brrt: i've got beginnings of a getattr_s patch, but i don't have a way to express "pass the nth literal string from the current compunit's literal table"
11:37 timotimo it'd be nice if i could just dereference the address of that string at jit time, because i *think* that table cannot move
11:37 brrt hmm
11:38 jnthn And exceptions will need some pondering.
11:38 brrt /if/ it cannot move, you can just pass the pointer in a literal
11:38 brrt otherwise, i might need / want to add options to callarg
11:38 * brrt nods wrt to exceptions
11:38 timotimo how do i properly pass that pointer?
11:39 timotimo when i said i'd just use the litearl int64 argument type, diakopter warned that some architectures have different sized pointers
11:39 brrt i think the callarg structure is a union of  { ptr, num64, int64 }
11:39 timotimo so it'd be good if the jit had a way to differentiate numbers from addresses on that stage
11:39 brrt true
11:40 brrt it hasn't a pointer value in there, if you like you can just add a void * in the struct
11:40 brrt the emitter will handle eventual differences
11:40 brrt hmm wait, i may have a better idea
11:42 jnthn shop/lunch; bbiab
11:43 timotimo preparing for departure first
11:43 timotimo brrt: do you want my patch so you can massage it into a workable state?
11:44 timotimo in my newest assessment, ifnonnull turned up as the second most bail-causing op, following getattr_s
11:44 timotimo we'll probably see an "explosion of diversity" once those two are done :)
11:44 timotimo which may be a good thing ("we attempt to compile a whole bunch more diverse frames!") or a bad thing ("oh no, look at all these low-worth ops we'll have to take care of!")
11:45 timotimo oh, btw, it'd be fantastic for logging purposes if the "call a C function" nodes could be annotated with the original opcode and if that could be printed in the log
11:45 timotimo so that we can get proper "emitted opcodes" statistics from the log
11:46 * brrt agrees
11:46 timotimo and rather than using a perl6 script, i suggest the use of grep "emit" | sort | uniq -c | sort -n
11:46 brrt oh, you can send a patch, yes
11:46 * brrt had considered that, too :-)
11:47 timotimo https://gist.github.com/timo/84d595f301354393bdc0
11:49 timotimo it'd probably also be nice to merge master into moar-jit again, as we've recently got some decont -> sp_p6oget_o transformations in spesh done
11:49 timotimo i've been running a non-pushed merge of master into moar-jit locally and it still builds rakudo fine at least
11:49 timotimo AFK now :)
11:50 brrt ok, will do :-) thanks a lot
12:03 brrt bbiab
12:09 zakharyas joined #moarvm
12:28 jnap joined #moarvm
13:32 carlin joined #moarvm
13:37 timotimo brrt, i'd also be interested in a before/after master-merge comparison of decont bails
13:37 timotimo or rather: decont count in general
13:37 timotimo (for setting compilation or something like that)
13:42 brrt joined #moarvm
13:44 brrt that's a prety good idea, yes
14:14 dalek MoarVM/moar-jit: 83a6629 | (Bart Wiegmans)++ | src/jit/ (4 files):
14:14 dalek MoarVM/moar-jit: Add pointer values as literals in call args
14:14 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/83a6629d51
14:14 dalek MoarVM/moar-jit: 4d50b38 | (Bart Wiegmans)++ | src/ (7 files):
14:14 dalek MoarVM/moar-jit: Add support for getattr_s
14:14 dalek MoarVM/moar-jit:
14:14 dalek MoarVM/moar-jit: Based on timotimo++'s patch. Also added direct support for
14:14 dalek MoarVM/moar-jit: calling args with the a string based on the string index.
14:14 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/4d50b38015
14:20 timotimo yay
14:30 colomon joined #moarvm
14:40 woolfy left #moarvm
14:41 woolfy joined #moarvm
15:06 brrt :-)
15:33 timotimo for the weekly it would be fantastic to have an updated bail log for the core setting :\
15:33 timotimo i suppose i'll have an outlet on the train and can compile and run stuff there no-problem
15:40 timotimo new most-bailing op: flattenropes
15:41 timotimo followed by ifnonnull, which i'm hoping brrt can implement very soon :)
15:49 dalek MoarVM/strref: f6b3ea8 | jnthn++ | src/strings/ops.c:
15:49 dalek MoarVM/strref: Fix variable names in asserts.
15:49 dalek MoarVM/strref: review: https://github.com/MoarVM/MoarVM/commit/f6b3ea8d3a
15:50 dalek MoarVM/strref: c4cfd75 | jnthn++ | src/strings/ops.c:
15:50 dalek MoarVM/strref: Toss debug code.
15:50 dalek MoarVM/strref: review: https://github.com/MoarVM/MoarVM/commit/c4cfd758c4
15:57 timotimo how did that even build? :)
15:57 timotimo should i point out that the string refactor branch still breaks at least one benchmark?
15:58 timotimo or are you about to fix that?
15:58 nwc10 on http://jnthn.net/perl6/bench/2014-07-13.html some of those HEAD benchmarks seem to be within a factor of 8 or even 4 of Perl 5
15:59 timotimo nwc10: wasn't that only the microbenchmarks, though?
15:59 nwc10 possi bly
16:00 jnthn There's some where we even beat Perl 5...
16:00 nwc10 I'm not aware, I'm on a poor connection (and I've closed the page) and $more excuses
16:00 nwc10 yes, I forgot to say. Some are already ahead
16:00 nwc10 need some concurrency benchmarks :-)
16:01 nwc10 We have a very dirty floor, thanks to 2 dogs, and so some concurenncy benchmarks would be very useful :-)
16:01 nwc10 [maybe too subtle]
16:01 klaas-janstol joined #moarvm
16:04 timotimo nwc10: you want to wipe the floor with perl5? :)
16:04 nwc10 aye.
16:04 timotimo sufficiently unsubtle :)
16:05 nwc10 more, I want the floor wiped. And I'd prefer an automated solution.
16:05 [Coke] nwc10++ for coming to the dark side.
16:05 nwc10 I'm playing both sides. :-)
16:06 timotimo :D
16:07 japhb_ I can't wait to see the benchmarks after strref merges.  And my perl6-bench fixes from last night should cut out a lot of the noise in the data, too.
16:08 timotimo japhb_: er .. you're seeing the benchmarks after the strref merges there :)
16:09 japhb_ nwc10: I welcome a moving target for perl5 performance, as long as it's moving in the "faster" direction.  :-)
16:10 japhb_ timotimo: His stuff was from the branch, not after the merge.  I've got a bunch of versions timed, so I want to be able to add the merged results into my histories and see how it looks.
16:11 jnthn Still need to decide whether to merge strref before or after 2014.07 release...
16:11 japhb_ Certainly after perl6-bench fixes, the history shows a much more reasonable improvement curve.
16:11 timotimo ah, of course.
16:11 jnthn I don't want a bunch of module regressions blocking a *
16:11 timotimo japhb_: is there a good explanation for why the lines on the left are exactly the same steepness?
16:11 japhb_ jnthn: if it can pass the spectests and the benchmarks, I'd love to be able to merge it.  The improvements for end users will be huge.
16:12 japhb_ Yeah, agreed about module regressions.  :-(
16:12 jnthn japhb_: Well, release is on Thu
16:12 jnthn So it's not a long wait
16:12 japhb_ timotimo: explain?
16:13 japhb_ jnthn: I meant I'd rather not have the users stuck waiting for mid-late August.
16:14 japhb_ (Those of us actually working on it are probably all running a current build)
16:16 japhb_ timotimo: Before my fixes last night, it was relatively common to have a couple of compilers whose run times on the left side of the graph were in the noise, and being pinned to the minimum run time (after subtracting startup/compile time).  Thus when calculating rates, they ended up colinear.  That's part of what I was trying to fix.
16:16 japhb_ It should be much rarer now to see that.  More likely you'll see plot lines missing the left end, or having fewer data points on the left end.
16:18 japhb_ Damn plugged ears.  Sudafed is NOT DOING ITS JOB.  :-/
16:18 timotimo ah, pinned to the minimum run time, that'd explain why they look the same
16:19 japhb_ timotimo: The initial version of the code was trying to avoid divide-by-zero.  The current version is attempting to avoid lies.
16:19 timotimo that's an improvement
16:19 timotimo i still kind of wish our html output had a way to make all graphs have the same scale
16:19 japhb_ It can probably still be tuned a bit, but I wanted to see how other people's benchmarks looked before tuning further.
16:19 nebuchadnezzar joined #moarvm
16:20 timotimo but i suppose our history comparison view is going to be much less problematic
16:20 japhb_ Some of the tests have VASTLY different scales.
16:20 japhb_ Yes, history should help that a lot.
16:20 timotimo that's true :\
16:20 japhb_ Bus stop coming soon, bbiab.
16:20 timotimo in about 15 minutes i'll reach the next train station, too
16:20 timotimo so ... what do i do until then? :)
16:21 timotimo i think flattenropes looks like a quite simple thing to do
16:29 dalek MoarVM/moar-jit: ce5cf76 | (Timo Paulssen)++ | src/jit/graph.c:
16:29 dalek MoarVM/moar-jit: implement flattenropes in the JIT.
16:29 dalek MoarVM/moar-jit:
16:29 dalek MoarVM/moar-jit: pretty much every bail that was flattenropes is now a bail caused by
16:29 dalek MoarVM/moar-jit: graphs_s ...
16:29 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ce5cf76645
16:31 timotimo jnthn: if the implementation of s_graphs is GET_REG(...).s->body.graphs, i should be able to turn it into a p6oget_s with offsetof( MVMString, body.graphs ), right?
16:34 jnthn timotimo: hmm
16:34 jnthn But that's changed in strref...
16:34 jnthn But yeah, that appraoch would work
16:34 jnthn It's called num_graphs now :)
16:37 japhb_ BTW jnthn, I'd like to see what the current version of perl6-bench run on Windows produces for plots ... I'm curious whether the tuning I did for my system (fast linux workstation) does the right thing on a Windows laptop as well.
16:38 japhb_ Also, if any of your Windows fixes for perl6-bench are immediately commitable, please do -- I'd like to keep the "hand-managed" part minimized, for any other Windows users who might be interested.
16:45 brrt joined #moarvm
16:50 kjs2 Hello all. Quick question - just cloned moarvm, trying to compile, but getting this error: src/moar.h:20:10: fatal error: 'uv.h' file not found
16:50 kjs2 #include <uv.h>
16:51 kjs2 perl Configure.pl completed successfully, Mac OSX platform. Just wondering if it’s just me.
16:54 kjs2 … but compilation of the latest release (2014.06) worked well.
16:56 japhb_ kjs2: Have you run Configure?
16:56 kjs2 japhb_: Yes, success
16:56 brrt that's... odd
16:56 japhb_ (I'm guessing you don't have the git submodules checked out)
16:56 brrt Configure.pl ought to do that
16:56 kjs2 that’s what confused me. As said, when just “download”ing the latest release, it works well
16:56 brrt maybe run it again?
16:57 kjs2 i took the latest version from github. Maybe I should jsut stick with releases :-)
16:58 brrt i'm checking if the latest checkout of master Just Works as it ought to
16:59 brrt ok, i'm waiting a pretty long time for 'Updating submodules'
16:59 timotimo kjs2: did you get it from the "releases" tab?
16:59 brrt but, i'm getting them after all
17:00 kjs2 timotimo: I downloaded the .zip file on github
17:00 timotimo yes
17:00 timotimo that's wrong
17:00 kjs2 that one failed (complaining about no uv.h)
17:00 timotimo i think we don't know how to turn that feature off
17:00 kjs2 but I realized it was easier for me to download it from moarvm.org
17:00 timotimo those are proper
17:00 kjs2 and that one works.
17:00 timotimo my seat is b0rken ;(
17:01 timotimo ah, just misconfigured
17:01 timotimo running Configure.pl again fixed it
17:41 brrt joined #moarvm
17:43 brrt left #moarvm
17:43 brrt joined #moarvm
18:21 FROGGS joined #moarvm
18:25 teodozjan joined #moarvm
18:29 nwc10 jnthn: *only* spectest difference from MoarVM master appears to be t/spec/S16-filehandles/io.t
18:29 nwc10 ok 81 - the bytes decode into the right Str
18:29 nwc10 vs on branch
18:30 nwc10 not ok 81 - the bytes decode into the right Str
18:30 nwc10 #      got: 'f??'
18:30 nwc10 # expected: 'föö'
18:30 timotimo oops
18:30 nwc10 yes. needs more cowbell, er metal dots
18:32 carlin joined #moarvm
18:34 timotimo p6oget_i isn't the right op at all to handle MVMString struct access, because it's for p6o's and not for MVMStrings %)
18:34 timotimo silly me
18:35 timotimo but using sp_get_i gives me trouble
18:35 timotimo but i did remove the offsetof MVMObjectStooge, data
18:35 [Coke] integration/99problems-51-to-60.t aborted 13 test(s)
18:35 timotimo remove the subtraction
18:35 nwc10 jnthn++ # pretty bloody good
18:36 timotimo i can only reach the Internet from my phone now
18:36 dalek MoarVM/moar-jit: a798a17 | (Bart Wiegmans)++ | src/jit/emit_x64.dasc:
18:36 dalek MoarVM/moar-jit: Remove debug instruction
18:36 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/a798a17df9
18:36 timotimo otherwise  I would upload a patch
18:37 timotimo brrt! \o/
18:37 brrt :-) that was a really simple patch
18:37 [Coke] started failing Mon Jul 7 18:33:12 2014
18:38 timotimo it's amazing how good networkmanager has gotten.
18:39 timotimo https://gist.github.com/timo/9369c4f53eecd40d60b4 - ideas?
18:40 * brrt almost wanted to turn timotimo's appraisal of current networkmanager into cynical terms
18:40 timotimo how so?
18:41 timotimo i plugged in my UMTS stick, "edit connections" "new connection" "mobile broadband" "germany" "vodafone" "default" done
18:41 timotimo i plug in my phone, select "usb tethering" and five secodns later it's already connected and working
18:41 brrt i agrees
18:41 brrt the cynical terms were about how bad it used to be
18:41 timotimo except now i'm inside a tunnel
18:41 timotimo and the connection has no right of working
18:42 timotimo why am i connected? o_O
18:42 timotimo maybe this tunnel has an antenna put into its roof or something
18:42 brrt that happens these days
18:43 brrt what i'm very happy about is the large-font support on gnome these days
18:43 brrt timotimo - you're trying to optimise graphs_s for spesh so it'll be jitted?
18:43 brrt you can do that, but it seems better imho to add an 'accessor node' to the jit
18:44 brrt that is to say, i don't expect a speed benefit by emitting a sp_p6oget_i or anything like that for an op like graphs_s, codes_s, etc
18:45 brrt better to have the JIT say 'here's how to make a node that copies N bytes from the object pointed at in this or that register' etc
18:46 brrt also note that sp_p6oget_ ops assume p6opaque structs, which have a perhaps little-known feature (namely, field indirection); the 'data' vector (which would normally be adjacant to the header) can be 'replaced' and be redirected
18:48 timotimo left the tunnel and the reception goes to hell
18:48 timotimo wtf %)
18:48 timotimo well, i did notice the thing about p6o_ ops
18:48 timotimo and the indirection
18:48 timotimo because it segfaulted in get_real_data :)
18:48 timotimo with "big font" you mean "HiDPI", right?
18:49 brrt no, i mean the little 'accessibility' button
18:49 timotimo it's fine to create a jit node for accessors
18:49 carlin joined #moarvm
18:49 * brrt had expected as much
18:50 brrt just that some accessors are conditional (of the type foo ? foo : bar, or something like that)
18:50 timotimo i want multipath TCP now
18:50 brrt i'll get to that
18:50 brrt time to fix networkmanager then :-p
18:50 timotimo i have to switch between vodafone and eplus every few minutes
18:50 timotimo i didn't implement a node for the jit because i have no idea how to work dasm
18:51 timotimo are you going to build ifnonnull soon? :3
18:52 brrt ehm... i /think/ jnthn said ifnonnull was invokish
18:52 brrt and i'm working on the frame register refactor, which is kind of a prelude to the invokish ops
18:53 brrt and, i'll be blogging about how to use dasm really soon :-)
18:54 timotimo ifnonnull is not invokish
18:54 timotimo it checks if the object pointer is a null pointer and if not if it's == VMNull
18:54 timotimo need to detrain in a few, then somehow get to the hackspace and get a jacket ...
18:55 timotimo ttyl :)
18:57 brrt oh, if that's so, i can do it swiftly
19:00 jnthn nwc10: Thanks. I can reproduce that one here.
19:00 nwc10 t/spec/S22-package-format/local.t fails on master in the same way.
19:01 jnthn timotimo: I think sp_get_i doesn't want th eheader subtracting, fwiw.
19:03 jnthn brrt: It's if_o and unless_o and istrue and isfalse that are the boolean-invokeys.
19:03 jnthn nwc10: Yeah, lizmat++ is actively hacking in that area, so guess it's some churn from that.
19:12 jnthn brrt: BTW, it occurs to me that we might want to mark ops as :invokey and :throwy in oplist and programatically deal with the issue
19:12 * brrt concurs
19:13 brrt throwy can jump arround frames too?
19:13 jnthn I've added various such things in the past; just git log update_ops.p6
19:13 brrt i see
19:14 jnthn Depends what you mean by "jump around frames"
19:14 jnthn In many ways it's worse than invokey
19:14 jnthn 'cus it can jump within a frame also
19:14 * FROGGS .oO( I've added various such things in the qast... )
19:27 dalek MoarVM/moar-jit: fe1315b | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
19:27 dalek MoarVM/moar-jit: Moved frame variable to callee-save register
19:27 dalek MoarVM/moar-jit:
19:27 dalek MoarVM/moar-jit: The frame variable is accessed often, so it is a good
19:27 dalek MoarVM/moar-jit: candidate for a callee-save register (as this saves loads
19:27 dalek MoarVM/moar-jit: whenever it is used). Moreover, in invokish operators
19:27 dalek MoarVM/moar-jit: this will allow us to compare the cur_frame with the jit_frame
19:27 dalek MoarVM/moar-jit: so as to check if they really invoked.
19:27 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/fe1315bb6a
19:27 brrt hmm i see
19:28 brrt basically, that's what handlers are for, aren't they?
19:28 brrt offsets into the bytecode stream
19:28 jnthn yeah
19:28 jnthn I expect spesh will be able to turn *some* local handlers in a frame into gotos...
19:29 jnthn But don't know that we want to rely on that.
19:29 jnthn One good news is that handlers always are new basic block starts... )
19:30 brrt that is good news
19:31 brrt basic block starts are always labels in the JIT
19:31 brrt (not sure how it could be otherwise, by definition of the idea 'basic block')
19:31 brrt which means that if you know the handler the JIT knows the label and you /can/ translate it into goto's
19:31 brrt of a sort
19:31 brrt (and if you can lookup the handler at runtime, better yet!)
19:35 dalek MoarVM/moar-jit: bc4bb42 | jnthn++ | src/spesh/facts. (2 files):
19:35 dalek MoarVM/moar-jit: Cope with cross-deopt-point usage analysis.
19:35 dalek MoarVM/moar-jit:
19:35 dalek MoarVM/moar-jit: If a register gets used after a deopt point, give its usage an extra
19:35 dalek MoarVM/moar-jit: bump. This means we won't kill a write to it when doing dead code
19:35 brrt (please dalek, it's a merge)
19:36 dalek joined #moarvm
19:44 timotimo jnthn: i already removed the header subtraction from sp_get_i
19:46 jnthn timotimo: Did that fix it?
19:47 timotimo no
19:47 timotimo Unable to parse expression in method_def; couldn't find final ')'  at line 16, near ") {\n      "
19:53 timotimo ah, brrt merged master, good.
19:53 brrt rakudo built fast :-o
19:54 brrt i mean, what's a good time for stage mast to build these days?
19:54 jnthn Lowest I've seen is around the 13s mark
19:55 brrt well, i've just hit 13.377
19:55 brrt (a number which i'm not kidding about in the least)
19:55 timotimo cute :)
19:55 brrt i suppose the spesh helped
19:56 timotimo it would be nice if it did
19:56 timotimo btw, only graphs_s and codes_s are amendable to being turned into an access node
19:56 lizmat jnthn, nwc10: wrt to S22 errors: they only happen when run under make, not when just executing with "perl6"
19:57 brrt afaik, there are more :-), it's just that most of these tend to be access from the compunit or threadcontext or similar
19:57 lizmat it appears that trying to execute perll6-m in a shell (which is what the S22 when running under make does)
19:58 lizmat gives the error: Unhandled exception: failed to load library 'dynext/libperl6_ops_moar.dylib'
19:58 lizmat at <unknown>:1  (/Users/liz/Github/rakudo.moar/perl6.moarvm::303)
19:58 timotimo so it's not that useful to build a very generalised solution
19:59 brrt not yet, i agree
19:59 jnthn elems on a VMArray and VMHash also can happen that way
19:59 jnthn Though I think they already spesh to sp_get_i
19:59 timotimo ah, but only if they are nqp::list_i, right?
20:00 timotimo i don't think we have nqp::hash_i at all
20:00 brrt the advantage of 'access nodes' - eventually - is that you can do common-subexpression-elimination for them, and compile code that has fewer loads
20:00 timotimo i'm looking forward to eliminating repeated boxing/unboxing with escape analysis
20:01 timotimo like $foo++ will turn into an inc instruction even if $foo is a container'd thingie
20:01 timotimo well, that doesn't sound like a good idea, as boxed ints are immutable
20:01 timotimo but if we just new'd that int, we can fuddle around with that ... actually we can delay the new-ing until after the calculations
20:01 timotimo forget what i said
20:14 brrt hmm... smallish issue
20:15 brrt can we call GC_SYNC_POINT /before/ branching away?
20:15 brrt would that make a lot of difference?
20:16 jnthn Can you get a little more specific?
20:16 jnthn Like, is there soemthing in interp.c you're looking at?
20:16 timotimo we don't have to call gc_sync_point
20:16 timotimo unless we have an infinite loop that allocates
20:16 * jnthn wonders if brrt is talking about this:
20:16 jnthn OP(goto):
20:16 jnthn cur_op = bytecode_start + GET_UI32(cur_op, 0);
20:16 jnthn GC_SYNC_POINT(tc);
20:16 jnthn goto NEXT;
20:16 brrt for example, yes
20:17 jnthn In which case no, it's not significant that we set cur_op before we call GC_SYNC_POINT
20:17 brrt why
20:17 brrt :-)
20:17 jnthn You could swap the two around.
20:17 jnthn e.g. it could also be
20:17 jnthn OP(goto):
20:17 jnthn GC_SYNC_POINT(tc);
20:17 jnthn cur_op = bytecode_start + GET_UI32(cur_op, 0);
20:18 jnthn goto NEXT;
20:18 jnthn And work just as well.
20:18 jnthn The GC doesn't actually use the program counter
20:18 timotimo gc_sync_point is "this is probably a good spot to see if other threads have decided to gc"
20:18 timotimo iirc
20:18 brrt oh, i read 'it's not /in/significant', which is why i'd expect a dramatic conclusion
20:18 jnthn oh :)
20:18 brrt ok, then i'll move it to the front
20:18 jnthn Yeah, that'd kinda make it weird :)
20:19 brrt because otherwise i'll have to JIT a weird dispatch thing arround it
20:19 jnthn Anyway, timotimo was right about the point of it: making sure non-allocating tight loops don't go wild.
20:19 jnthn And prevent other threads GCing.
20:19 jnthn If you wanted to further optimize it, you could only emit it on backbranches.
20:20 timotimo right, we rely on another thread being marked as "blocked" or reaching a gc sync point soon enough
20:20 timotimo but we can't pretend a piece of jitted code "blocks" a thread except if it is absolutely certain that it won't allocate
20:20 jnthn (Since no backbranch = no loop)
20:20 timotimo and then it must not leave the jitted code without checking for simultaneous gc runs
20:21 * jnthn puts aside $dayjob-stuff for the day
20:21 jnthn ...and wanted to take a stroll but...rain. :(
20:22 brrt what are umbrella's for :-)
20:22 * brrt ponders the backbranch stuff... i'm not sure i can guarantee that bb's are numbered in a linear-consecutive fashion, or in other words, i can't prove bb's from a loop yet
20:22 brrt hmm
20:22 brrt what would be the sizeof of A0_t in x64
20:24 jnthn 64 bits
20:25 brrt indeed :-) that's good news for me
20:25 jnthn Where do you find the AO_t, ooc?
20:25 timotimo is that related to atomicness with regards to certain operations?
20:25 brrt gc_status
20:25 jnthn yeah
20:25 jnthn Ah...
20:25 brrt tc->gc_status is A0_t
20:25 jnthn Right
20:25 brrt which means i must cmp it but know the size
20:26 jnthn GC_SYNC_POINT does not, thankfully, look at it atomically :)
20:27 timotimo aye, it's okay to accidentally miss a beat
20:32 brrt thankfully, indeed
20:35 brrt hmm... that's weird
20:35 brrt if i add ifnonnull as an op, i get lots of 'use of unitiialized value of type Nil in numeric context' errors
20:38 timotimo in that case your ifnonnull is the wrong way around :)
20:38 brrt that could well be
20:41 timotimo :)
20:46 dalek MoarVM/moar-jit: 0e15cb6 | (Bart Wiegmans)++ | src/ (6 files):
20:46 dalek MoarVM/moar-jit: Added frame ArgProcContext as C call interp var
20:46 dalek MoarVM/moar-jit:
20:46 dalek MoarVM/moar-jit: This should fix checkarity, which it seems never worked
20:46 dalek MoarVM/moar-jit: because op_to_func return the function pointer to the
20:46 dalek MoarVM/moar-jit: regular non-jit version.
20:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/0e15cb6b51
20:46 dalek MoarVM/moar-jit: d23c9a0 | (Bart Wiegmans)++ | src/jit/ (4 files):
20:46 dalek MoarVM/moar-jit: Add support for ifnonnull
20:46 dalek MoarVM/moar-jit:
20:46 dalek MoarVM/moar-jit: This also adds the GC_SYNC_POINT to branches
20:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/d23c9a01cb
20:46 brrt timotimo++ for telling me what to look for
20:46 jnthn ah, the rain stopped :)
20:47 jnthn bbi10-15
20:48 brrt see you tomorrow!
20:48 brrt left #moarvm
20:49 woolfy1 joined #moarvm
20:57 * timotimo makes a new bail statistic thingie
21:01 timotimo yeah, a whole bunch of graphs_s failures still
21:01 timotimo then comes atkey_o and then param_rp_o
21:03 timotimo but atkey_o should be implementable as a simple function now
21:06 timotimo will we never ever support may-invoke-opcodes in the jit?
21:08 timotimo well, would you look at that
21:08 timotimo decont is back on the top spot
21:08 timotimo followed by graphs_s by about 15 bails
21:12 jnthn timotimo: Oh, we'll certainly support may-invoke; brrt++ and I have been discussing that :)
21:12 timotimo cool
21:12 timotimo otherwise we'll never be able to tackle decont :)
21:13 timotimo actually ... how come we don't have guarded almost all deconts with a "the type of container has always been the same"?
21:16 timotimo since the only container we cannot turn into a p6oget_o is the code-based one and i don't think it's used that often ... ?
21:17 jnthn Dunno. There must be places we're not sure; in may cases, perhaps we can be more sure :)
21:18 jnthn May be worth checking if box_i and friends introduce "known not a container" things in facts.c for example
21:18 jnthn Otherwise I'd just look at spesh log and see if remaining deconts come in some kind of pattern.
21:22 jnthn m: say "föö".encode("ISO-8859-1").perl
21:22 camelia rakudo-moar b25b86: OUTPUT«Blob[uint8].new(102, 246, 246)␤»
21:24 timotimo create_facts is responsible for box_i and friends, it checks the type for known_value (is that right? wouldn't known_type be enough?) and if it's got a null container_spec and then sets FACT_DECONTED
21:25 jnthn Well, the type almost always is suppleid as a wval
21:25 jnthn But yeah, technically known_type is enough. Not sure if it'll nail many more cases, but quite possibly
21:27 timotimo OK, i'll add a printf in that branch
21:27 dalek MoarVM/strref: bab734b | jnthn++ | src/strings/latin1.c:
21:27 dalek MoarVM/strref: Fix copy-pasto when updating latin-1 encoding.
21:27 dalek MoarVM/strref: review: https://github.com/MoarVM/MoarVM/commit/bab734b0bc
21:27 jnthn There's the one nwc10++ reported
21:28 timotimo in the first piece of the function we check the type for known_type, in the second piece we check for known_value
21:28 japhb joined #moarvm
21:28 timotimo interesting.
21:29 timotimo that triggers really often
21:29 jnthn Whcih "that"? :)
21:29 timotimo both branches are hit, actually
21:30 jnthn Are there cases where type is and value ain't?
21:30 timotimo let me see.
21:31 timotimo er. yes.
21:31 timotimo type is known, value is not known
21:31 timotimo surprisingly a bunch of times
21:31 jnthn darn, it's used for create too
21:31 jnthn That's a big missed opportunity
21:32 jnthn Yeah, type is enough.
21:32 jnthn I think it mighta been copy-pasto from object_facts
21:32 timotimo i'll change that, in that case.
21:32 timotimo could be, yeah
21:32 jnthn Where exactly value is known.
21:32 timotimo gimme a sec.
21:32 jnthn thx
21:34 timotimo building now and seeing if the bail log is better
21:34 jnthn oh, good news
21:34 jnthn You know parse-json failed horribly?
21:34 jnthn Turns out it was nothing to do with strref
21:35 timotimo oh!
21:35 timotimo yays :)
21:36 timotimo still got a whole bunch of deconts in there. huh.
21:36 jnthn Was that my perl6-bench was old enough to have eval
21:36 timotimo :D
21:37 timotimo excellent
21:37 jnthn I'm pondering whether to merge now and bump revisions to get feedback from the ecosystem
21:37 jnthn If we see anything I can always easily back it out.
21:37 jnthn That's what version control is for, after all.
21:39 timotimo aye, i'd like that :)
21:39 timotimo a lot, actually
21:41 timotimo interesting, a bunch of create_fact without a known type. but probably also without a known value in that case. let me check
21:43 timotimo ah
21:43 timotimo yeah, no case of "unknown type, but known value"
21:43 timotimo which would have been quite surprising
21:43 timotimo so that's likely just stuff like "get the type object from an array" or something :)
21:43 japhb joined #moarvm
21:45 jnthn hah...
21:45 jnthn Profiled -e "my $s = ' ' x 1000 ~ 'x' x 1000 ~ ' ' x 1000; $s.trim for 1 .. 1000"
21:46 jnthn 94% of the time is spent in MVM_string_gi_move_to :)
21:46 japhb_ joined #moarvm
21:47 timotimo that's the iterator move function?
21:47 jnthn yeah
21:47 timotimo that tries to step over graphemes?
21:47 japhb joined #moarvm
21:47 jnthn /* Sets the position of the iterator. (Can be optimized in many ways in the
21:47 jnthn * repetitions and strands branches.) */
21:47 timotimo "in the future"?
21:47 jnthn you don't say :D
21:47 timotimo ah, hehehe.
21:47 timotimo well, does that still count as a fair benchmark? :)
21:47 jnthn oh, the benchmark is great
21:47 timotimo if we simply skip over the ' ' x 1000?
21:48 timotimo oh, that's not what that does
21:48 jnthn It tells me this thing I wondered if I could get away with optimizing now actually really really needs optimizing.
21:49 timotimo OK :)
21:49 timotimo we could optimize "find_cclass" for repetition rope cases. if it didn't find one in any of the repeated thingies, it'll never find it in any of them
21:50 timotimo so it could skip to the next ropey bit :)
21:50 timotimo in that case our trim benchmark would not even depend on $scale
21:50 timotimo it'd just be done in constant time :D
21:55 timotimo oh, you're perhaps expecting me to push my code
21:55 timotimo i could totally do that
21:57 jnthn m: my $s = ' ' x 1000 ~ 'x' x 1000 ~ ' ' x 1000; say $s.trim.chars
21:57 camelia rakudo-moar b25b86: OUTPUT«1000␤»
21:58 dalek MoarVM/moar-jit: 7595b3c | (Timo Paulssen)++ | src/jit/graph.c:
21:58 dalek MoarVM/moar-jit: jit can has atkey_o
21:58 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7595b3c99d
21:58 jnthn Rather faster code got 1001. I think I got it wrong. :)
21:59 jnthn Guess that's what I get for coding without a beer to hand...
21:59 dalek MoarVM: 802e3a4 | (Timo Paulssen)++ | src/spesh/facts.c:
21:59 dalek MoarVM: create_facts in spesh doesn't have a known value, just a known type.
21:59 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/802e3a4785
22:00 timotimo ^these are acceptable commits, i hope
22:00 * jnthn pours a De Molen
22:08 * diakopter moles a De Pouren
22:09 jnthn timotimo: First one looks OK at first blush
22:09 * timotimo blushes
22:10 [Coke] m: say Blob[uint8].new(102, 246, 246)
22:10 camelia rakudo-moar b25b86: OUTPUT«Buf:0x<66 f6 f6>␤»
22:10 timotimo i don't know the significance of that
22:10 [Coke] of the pharse "at first blush"?
22:11 timotimo no, of the code you pasted :)
22:11 jnthn Second looks fine
22:11 [Coke] result of jnthn's .perl a few page ^^
22:11 jnthn Yeah; that was busted under strref, but fixed now.
22:12 [Coke] m: say Blob[uint8].new(102, 246, 246).decode()
22:12 camelia rakudo-moar b25b86: OUTPUT«Malformed UTF-8 at line 1 col 2␤  in method decode at src/gen/m-CORE.setting:5302␤  in block  at /tmp/hHkgurlWma:1␤␤»
22:12 jnthn Correct; that is indeed invalid UTF-8 :)
22:13 [Coke] m: say Blob[uint8].new(102, 246, 246).decode("ISO-8859-1")
22:13 camelia rakudo-moar b25b86: OUTPUT«föö␤»
22:14 timotimo m: say "hello".decode("rot13")
22:14 camelia rakudo-moar b25b86: OUTPUT«No such method 'decode' for invocant of type 'Str'␤  in block  at /tmp/MhNMCnzK0V:1␤␤»
22:14 timotimo er
22:14 timotimo m: say "hello".encode("ascii").decode("rot13").encode("ascii")
22:14 camelia rakudo-moar b25b86: OUTPUT«Unknown string encoding: 'rot13'␤  in method decode at src/gen/m-CORE.setting:5302␤  in block  at /tmp/DVnpwyL4pK:1␤␤»
22:14 timotimo that's obviously something we will need in the future
22:14 [Coke] be nice if we could register new encodings at the language level.
22:14 [Coke] (maybe)
22:15 jnthn It's not as easy as it looks, due to decoders especially having to be careful about things dangling over block boundaries when doing I/O.
22:15 timotimo oh ... i remember
22:16 jnthn But yeah, in the long run we want that.
22:16 jnthn (registering new encodings)
22:16 [Coke] seems like we could abstract out the dangling-coverage-bits
22:16 [Coke] with a CMOP.
22:16 timotimo yeah, if we don't want performance :)
22:16 [Coke] :)
22:17 [Coke] once jnthn fixes strings, we'll have plenty to waste!
22:17 timotimo er ...
22:17 timotimo maybe
22:17 [Coke] :)
22:17 timotimo we don't really expect performance improvements on parsing, right?
22:18 jnthn Before: 7.73s. Now: 0.51s.
22:18 jnthn (both including startup time)
22:18 jnthn I...guess that's better :)
22:18 timotimo the 1000 x benchmark, eh?
22:18 jnthn yeah
22:18 timotimo nice! :)
22:21 [Coke] m: say 0.51 / 7.73
22:21 camelia rakudo-moar b25b86: OUTPUT«0.065977␤»
22:23 jnap1 joined #moarvm
22:41 jnthn Got it down to 0.47 now :)
22:41 jnthn (Difference more apparent on bigger benchmarks...)
22:42 jnthn Gonna let perl6-bench tell me how I've done, though...
22:45 japhb joined #moarvm
22:51 japhb_ jnthn: \o/
22:51 japhb_ SO HAPPY TO SEE THAT RESULT
22:51 japhb_ Now we need to give you more benchmarks to bang on.  :-)
22:53 timotimo i wonder what we have to do to make forest fire behave in a similar fashion :)
22:54 jnthn Well, japhb++ already gave me 2 benchmarks showing things forest fire does are slow
22:54 japhb_ timotimo, That's why I started splitting out forest-fire benchmarks for jnthn.
22:54 japhb_ jnthn, There's more than that.  Hold on, lemme find it.
22:54 timotimo yes, that was an excellent help
22:55 timotimo er
22:55 timotimo i mean i expect it to be
22:56 japhb_ timotimo, http://irclog.perlgeek.de/perl6/2014-07-06#i_8980367
22:56 japhb_ I think there's like half a dozen or so now.
22:56 japhb_ But there are indeed more things to extract.
22:57 japhb_ ENOTENOUGHTUITS
22:58 timotimo very good
22:58 timotimo it would be nice to come up with completely new benchmarks, too ...
22:59 timotimo i forgot what the state of the richards benchmark was
22:59 jnthn Aye, more are welcome on regexes, for example
22:59 jnthn Unless japhb++ already sneaked a load of those in while I wasn't looking :)
23:03 dalek MoarVM/strref: 56ddb81 | jnthn++ | src/strings/iter.h:
23:03 dalek MoarVM/strref: Make MVM_string_gi_move_to a bunch more efficient.
23:03 dalek MoarVM/strref:
23:03 dalek MoarVM/strref: Jump directly to the right strand, and then to the correct repetition.
23:03 dalek MoarVM/strref: review: https://github.com/MoarVM/MoarVM/commit/56ddb8199a
23:03 dalek MoarVM/strref: 992a482 | jnthn++ | src/strings/ops.c:
23:03 dalek MoarVM/strref: Optimize find_cclass and find_not_cclass.
23:03 dalek MoarVM/strref:
23:03 dalek MoarVM/strref: Now, they just swiftly iterate graphemes with a single iterator in the
23:03 dalek MoarVM/strref: strand case, rather than making an iterator per char read.
23:03 dalek MoarVM/strref: review: https://github.com/MoarVM/MoarVM/commit/992a482859
23:04 japhb_ jnthn, Sorry, regex benchmarks are on the list, but not added yet.  Are they on your critical path?  I might be able to do some this week if so.
23:04 dalek MoarVM: 9384917 | jnthn++ | src/io/procops.c:
23:04 dalek MoarVM: Just use empty string constant, not make an empty.
23:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/93849174c8
23:04 dalek MoarVM: 6eaf6aa | jnthn++ | / (29 files):
23:04 dalek MoarVM: Significantly overhaul the strings code.
23:04 dalek joined #moarvm
23:04 jnthn japhb_: Not critical path yet, I'm just intrested to know how bad the situation is.
23:04 japhb_ jnthn++ # Dalek crushing commit loads  :-)
23:05 timotimo yaaaaay
23:05 japhb_ jnthn, roger that.
23:05 timotimo should find_cclass and find_not_cclass learn about repetitions, too? :3
23:05 japhb_ Maybe that will give me something easy to do while this cold has my brain at <50%
23:06 jnthn cold--
23:06 * jnthn recommends cooking up some nice Indian noms
23:07 jnthn I had one that woudln't go away until this weekend, when I made some nice spice-packed balti :)
23:07 timotimo whenever i get a sore throat, i like putting slices of ginger in boiling water for a while and drink the result (sans ginger slices, but that's a matter of preference)
23:08 timotimo the result is also enjoyable when cold
23:08 jnthn Curry had 6-7cm of ginger :)
23:08 jnthn And yeah, ginger is awesome.
23:14 japhb Mmmm, Indian food does indeed sound wonderful.
23:17 jnthn Hmm, I hope the latest perl6-bench copes with the fact some of my existing timings don't have all the benchmarks...
23:18 timotimo what i wonder is how to handle re-running a single benchmark and not throwing away all previous values and stuff like that
23:19 japhb_ jnthn, That should be handled just fine, except that you won't get summary scores for any timing runs that are incomplete.  But you may not care about that right now ....
23:19 timotimo oh?
23:19 timotimo summary scores? that's the new thing for history stuff?
23:19 japhb_ Yes.
23:19 timotimo gotta run
23:22 japhb_ When you do `./bench compare|history [checkouts ...]` then the first checkout listed will be considered the standard, with performance = 100.  All others will be compared to it by doing the geometric mean of relative performance on all tested benchmarks, and calculating one linear-scale score.
23:23 japhb_ So with perl5 v5.20.0 as the reference (thus score = 100), one set of benchmarks I ran resulted in nqp-moar ~35, and rakudo-moar ~4-5
23:24 japhb_ But if any tests did not succeed for a given compiler checkout, then the geometric mean is considered invalid, and no score will be computed for that compiler version.
23:25 japhb_ So while working on the history function, I specifically run only the tests that run on all compiler backends, so I can see the scores.  :-)
23:25 jnthn Hmm
23:25 jnthn The graphs look a little odd
23:25 jnthn perl5 is missing a bunch of points to the left.
23:25 jnthn But none of the others are.
23:27 jnthn oh no, happens once somewhere else too
23:27 japhb_ jnthn, yeah, I described that in my most recent commits.
23:28 japhb_ I am now intentionally throwing timing data away that is below the startup/compile noise threshold, because the computed rates are essentially garbage
23:29 japhb_ (which is what caused seesaw plots on the left of some graphs, or ridiculously high rates on the left, when on the right performance settled down to a consistent but much lower value)
23:29 jnthn ah
23:29 japhb_ I believe the trends should remain clear, but please post any that have become confusing.
23:29 japhb_ I'm still tuning the threshold.
23:31 japhb_ (Note: timing data thrown away only during analysis.  Data in timings files remains untouched, unless you intentionally rebuild the input files with post-analysis data using `./bench --format=json analyze`)
23:33 jnthn japhb_: http://jnthn.net/perl6/bench/2014-07-15.html is my latest one
23:34 jnthn Time for some rest; 'night
23:34 jnthn And get well soon!
23:44 japhb_ Thanks, jnthn.  Sleep well.
23:49 japhb_ Hmmm, some of the timings in jnthn's plots still show signs of bogosity.  Left side of rakudo-moar/HEAD in postwhile_nil, for example
23:50 * japhb_ considers increasing the threshold a bit more

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