Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-26

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

All times shown according to UTC.

Time Nick Message
01:08 FROGGS_ joined #moarvm
02:05 Util joined #moarvm
02:17 ventica joined #moarvm
04:02 ventica_desktop joined #moarvm
04:25 xiaomiao joined #moarvm
05:34 cognome joined #moarvm
06:01 cognome joined #moarvm
06:28 woolfy joined #moarvm
07:22 lizmat joined #moarvm
07:22 cognominal joined #moarvm
07:37 woolfy left #moarvm
07:39 FROGGS[mobile] joined #moarvm
08:15 FROGGS_ jnthn: it must be this:
08:15 FROGGS_ ==13374== 4,646,152 bytes in 112,982 blocks are still reachable in loss record 1,663 of 1,668
08:15 FROGGS_ ==13374==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
08:15 FROGGS_ ==13374==    by 0x4F8590C: deserialize (MVMArray.c:1098)
08:15 FROGGS_ ==13374==    by 0x4F9FE92: MVM_serialization_deserialize (serialization.c:1987)
08:15 FROGGS_ though, that is b2e3884
08:38 sergot hi o/
08:52 Ven joined #moarvm
08:55 jnthn FROGGS_: I don't think so; that's just deserializing things at startup...but the leak grows over time.
09:12 FROGGS_ ohh, I am actually still looking at the old run
09:12 FROGGS_ hi sergot
09:12 FROGGS_ hi jnthn :o)
09:15 FROGGS_ hmmmm
09:15 FROGGS_ jnthn: look at this: http://paste.scsys.co.uk/409702
09:16 FROGGS_ ohh
09:16 FROGGS_ perl6-m -e ':3("111") while 1'
09:16 FROGGS_ extend/trunc NYI
09:16 FROGGS_ :(
09:16 FROGGS_ that explains the non leakness
09:17 FROGGS_ with backtrace: http://paste.scsys.co.uk/409703
09:17 FROGGS_ what is happening here?
09:28 jnthn FROGGS_: I dunno, maybe you updated Moar to get extop changes, but didn't update Rakudo also?
09:28 jnthn So now it reads bytecode wrong...
09:29 FROGGS_ jnthn: correct
09:29 FROGGS_ will update
09:39 tgt joined #moarvm
10:43 Ven joined #moarvm
11:01 Ven joined #moarvm
11:07 FROGGS_ jnthn: must be this then:
11:07 FROGGS_ ==16116== 40,729,249 (38,335,200 direct, 2,394,049 indirect) bytes in 1,197,975 blocks are definitely lost in loss record 1,656 of 1,656
11:07 FROGGS_ ==16116==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
11:07 FROGGS_ ==16116==    by 0x4F49AE0: MVM_args_proc_to_callsite (args.c:68)
11:07 FROGGS_ ==16116==    by 0x4F49B89: MVM_args_use_capture (args.c:92)
11:55 Ven joined #moarvm
13:06 FROGGS_ jnthn: is that a good approach? https://gist.github.com/FROGGS/4c459d3daea186e3a5ce
13:06 FROGGS_ I'm in doubt
14:22 Ven joined #moarvm
14:44 zakharyas joined #moarvm
14:53 carlin is this the right way to fix the *BSD rand() problem? https://gist.github.com/carbin/8d35cebb83a7f92fd1ed
14:56 * jnthn back
14:57 jnthn FROGGS_: Yeah, that looks like a serious loss...
14:57 jnthn uh, leak
15:03 dalek MoarVM/esc: fb4a6cb | jnthn++ | / (4 files):
15:03 dalek MoarVM/esc: Annotate ops with escape info and store it.
15:03 dalek MoarVM/esc:
15:03 dalek MoarVM/esc: Product of escape analysis research/planning hackathon with masak++.
15:03 dalek MoarVM/esc: Only a handful of ops annotated so far.
15:03 dalek MoarVM/esc: review: https://github.com/MoarVM/MoarVM/commit/fb4a6cb6c9
15:11 jnthn carlin: Provided all those platforms do indeed have arc4random, probably works. Though may want to make it MP_GEN_RANDOM as a name, just to descrease chance of collisions...
15:12 carlin I've tested moar/rakudo on openbsd and freebsd, and tested that arc4random is on dragonflybsd and netbsd
15:55 jnthn FROGGS_: Don't think the approach you suggested will work, but one I just tried isn't any better...
15:57 timotimo ESCAPE_IRR is IRRELEVANT?
15:57 FROGGS[mobile] joined #moarvm
15:58 jnthn yes
16:00 timotimo maybe i'll have someone (masak perhaps?) explain this to me and i'll help annotate ops ...
16:36 Ven joined #moarvm
17:06 itz_ joined #moarvm
17:31 dalek MoarVM: 815abcb | jnthn++ | src/ (4 files):
17:31 dalek MoarVM: Allow extops to provide flags and spesh.
17:31 dalek MoarVM:
17:31 dalek MoarVM: This means we can mark extops pure so dead code elimination can kill
17:31 dalek MoarVM: them, as well as provide a spesh function for an extop.
17:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/815abcb3bb
17:31 dalek MoarVM: 9e90ac1 | jnthn++ | src/spesh/optimize.c:
17:31 dalek MoarVM: Don't keep guards just because of usage analysis.
17:31 dalek MoarVM:
17:31 dalek MoarVM: This should allow a few more unrequired guards to be thrown out.
17:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9e90ac1e62
17:33 jnthn .tell brrt I did various extop things that should make things a bit better from the JIT side.
17:34 jnthn Including being able to set the invokey flag, or at least making it easily possible to implement that feature.
17:44 timotimo jnthn: how about allowing the user to register extra fact discovery routines for extops?
17:45 timotimo p6box_* for example could probably benefit from setting the known type to Int, Num, Str
17:45 timotimo p6parcel as well, i'd say, as well as p6list
17:47 timotimo actually, a whole lot of them could benefit from that... if not all
17:53 jnthn timotimo: Yeah, I suspect so.
17:54 jnthn timotimo: Interested in adding it at al? Might not be too hard following the patches Idid...
17:54 timotimo can do
17:54 timotimo currently fighting my little ear infection
17:55 jnthn ugh :(
17:55 jnthn Sounds less awesome than my little pony
17:55 timotimo yup
17:57 timotimo the pain levels ebb and tide, but it's a strange feeling being practically deaf in one ear
18:03 timotimo huh, we have to do a linear scan through the extop records?
18:04 jnthn It'll be a small list
18:04 timotimo OK
18:04 jnthn So not worth making a full-on hash thingy for it
18:04 timotimo it'll probably all land in the cache as one blob anyway
18:05 jnthn *nod*
18:14 dalek MoarVM: 603b50f | (Timo Paulssen)++ | src/ (3 files):
18:14 dalek MoarVM: allow extops to put facts into the spesh fact database.
18:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/603b50f706
18:19 timotimo oh, actually ... i messed that up
18:19 timotimo should have compiled before pushing i s'pose
18:24 timotimo ah, here's what i missed
18:25 dalek MoarVM: 8ef4455 | (Timo Paulssen)++ | src/ (4 files):
18:25 dalek MoarVM: allow extops to put facts into the spesh fact database.
18:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8ef4455eef
18:26 timotimo *force pushed* ...
18:30 jnthn That's almost always a bad idea :P
18:30 jnthn Now the commit that NQP_REVISION points to doesn't exist, for example...
18:33 FROGGS[mobile] MOAR_REV points to the right thang
18:36 zakharyas joined #moarvm
18:40 timotimo jnthn: i force pushed to *all three repositories* :P
18:40 timotimo i'm extra bad
18:40 FROGGS[mobile] uhh
18:40 FROGGS[mobile] :p
18:43 timotimo jnthn: is the result of p6parcel deconted or is it a container?
18:43 timotimo i think it's not, but what do i know :P
18:49 timotimo p6scalarfromdesc should set known type to Scalar. what else?
18:51 timotimo should it also - if the scalar descriptor is a known_value - set the deconted value to be known and set the known deconted value to the descriptor's the_default?
18:54 jnthn I don't think so.
18:54 jnthn p6parcel should be deconted
18:54 jnthn coming out of the op, at least
18:54 timotimo good
18:54 timotimo you don't think so about what exactly?
18:54 jnthn Everything you said about p6scalarfromdesc except the known type bit.
18:55 timotimo OK
18:57 timotimo now i have some fact discovery thingies in place
18:57 timotimo i should probably spectest before i push
18:57 timotimo oh, i forgot to register the functions %)
19:00 timotimo i made discovery functions for known_type for p6box_[ins], p6listiter, p6scalarfromdesc, and p6reprname
19:00 timotimo sound about right?
19:03 raiph joined #moarvm
19:05 jnthn Soudns reasonable
19:05 timotimo the only fails in spectests are lock.rakudo.moar and t/spec/integration/99problems-51-to-60.t
19:05 timotimo there's a segfault in there
19:06 timotimo interestingly, it segfaults in MVM_gc_root_add_frame_roots_to_worklist
19:06 timotimo i don't have debug symbols right now; does that happen on master, too?
19:07 timotimo oh well, SPESH_DISABLE=1 makes the segfault go a way
19:09 timotimo should i set the known type of p6bool's return value to STABLE(True).WHAT?
19:13 TimToady I assume you mean MVM_SPESH_DISABLE
19:13 timotimo yes
19:14 TimToady otherwise it would be quite interesting if that "fixed" the problem
19:15 timotimo surely :)
19:16 TimToady nutrition &
19:18 timotimo well, i put a printf into all my discovery functions and it doesn't seem like they get run at all
19:20 timotimo aaah, here's what i've been missing ...
19:21 dalek MoarVM: 4ae0734 | (Timo Paulssen)++ | src/core/ext.c:
19:21 dalek MoarVM: forgot to resolve discovery function in extop records
19:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4ae0734a20
19:34 timotimo since my code didn't even really run before and it's only a single test file that segfaults, it'll probably be fine to just push
19:34 timotimo after all, we're weeks away from the next release
19:39 jnthn timotimo: The other missing facts thingy you may like to look at is in Moar itself,with the bigint ops
19:39 jnthn I the ++ microbenchmarks we can eliminate at least one useless decont with that.
19:49 colomon joined #moarvm
19:56 carlin the good news is the the segv with 51-to-60.t was known (RT 122297)... the bad news is it was apparently fixed a couple of days ago and [Coke] unfudged the test
19:56 timotimo oh well :(
19:57 timotimo jnthn: which ops need what facting?
19:58 jnthn add_I, sub_I, etc etc
19:58 timotimo let's see ...
19:59 jnthn They always come with the result type
19:59 timotimo and the result is never a container?
20:00 timotimo i.e. you can't pass anything as the result type that'd cause a container to be the result?
20:01 timotimo in that case i guess i can re-use the create_facts function
20:01 jnthn Correct
20:01 jnthn Yeah, create_facts mstm
20:01 timotimo that'll take care of container/not container
20:04 timotimo well, now i get a segfault in the core setting compilation
20:05 jnthn I can't think of a situation where having a type that was both a scalar container AND a bigint container makes sense :)
20:06 timotimo ah, i was trying to get the 4th argument even for neg_I and abs_I
20:08 dalek MoarVM: 89658cb | (Timo Paulssen)++ | src/spesh/facts.c:
20:08 dalek MoarVM: know type and containerness information for bigint ops
20:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/89658cb4c9
20:09 timotimo this ought to be correct
20:09 timotimo i suppose it's not a gigantic win yet; it would be if we could *ahem* remove redundant set instructions :)
20:10 jnthn It's to darn hot in here for me to contemplate debugging that one.
20:12 timotimo aye, you should do something simple instead, like escape analysis :D
20:12 Ven joined #moarvm
20:12 jnthn Well, currently looking at handler table merging :)
20:12 timotimo ah, good
20:13 jnthn BOOM SEGV
20:13 timotimo that's what keeps spesh from handling almost all perl6 frames, eh?
20:13 jnthn Hm
20:14 jnthn Well, lexotic will still be an issue in those I guess
20:14 timotimo that's whenever we throw exceptions or return or do stuff like that?
20:14 jnthn return in particular
20:15 timotimo that'd happen quite frequently, i suppose
20:15 timotimo we do have a little optimization in there that removes redundant returns at the end of functions, thanks to froggs
20:15 jnthn What we do inline so far is due to an optimization in Perl6::Optimizer that tosses lexotic entirely...
20:16 jnthn ah yay, latest version of my patch builds Rakudo and NQP, and passes sanity tests in both
20:16 jnthn Should spectest this I guess :)
20:17 jnthn aww, a fail
20:17 jnthn oh wait, it's Mouq++'s recent push
20:17 jnthn (as in, I don't have it)
20:19 timotimo oh, that sounds lovely!
20:19 jnthn I thought one a case I didn't handle too...
20:20 timotimo as long as we can safely bail in that one case it should be fine, no?
20:20 jnthn Oh, I handled it.
20:24 * jnthn waits on the next spectest run
20:28 timotimo hum.
20:28 timotimo well, we have a bogus pointer in a register
20:28 timotimo in a frame that has been spesh'd
20:30 timotimo oh great!
20:30 timotimo when i'm attached to the process with gdb, it runs fine
20:30 jnthn :/
20:31 carlin gdb is really good at fixing bugs, everyone should just run everything inside it
20:32 timotimo aye
20:34 dalek MoarVM: 54a4961 | jnthn++ | src/spesh/codegen.c:
20:34 dalek MoarVM: Use handlers from spesh graph at code-gen time.
20:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/54a4961f11
20:34 dalek MoarVM: 028d7a7 | jnthn++ | src/spesh/inline.c:
20:34 dalek MoarVM: Support inlining of frames with handlers.
20:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/028d7a75a7
20:34 timotimo jnthn: should i look into running a new benchmark with this?
20:35 jnthn Not sure if it'll make a hgue difference tbh
20:35 jnthn Well, maybe all the chagnes we've done together will
20:35 timotimo hm, so inlining these frames won't do much good?
20:35 jnthn Well, it will, but not sure how many more it gets us without the lexotic stuff
20:36 timotimo OK
20:36 timotimo got a clue how much work that is going to be?
20:36 jnthn Lemme remember how lexotic works these days...
20:36 timotimo i never knew :)
20:40 Ven "gdb is really good at fixing bugs, everyone should just run everything inside it" <- quote of the year :)
20:43 jnthn OK, I really dunno why lexotic inlines won't work
20:43 jnthn I'm probably missing something
20:43 * jnthn takes :noinline off them to find out :)
20:43 timotimo %)
20:43 timotimo :noinline means "if we see this in a frame, don't dare inline it", right?
20:44 jnthn Right
20:44 jnthn Oh...
20:45 jnthn Just remembered that I re-did lexotic a bit.
20:47 jnthn So maybe that makes it OK
20:47 timotimo that's why we can now inline lexotic safely?
20:48 jnthn Yeah, that's what I@m wondering.
20:50 jnthn Darn, not so simple
20:50 jnthn NQP build and worked out OK
20:50 jnthn But in Rakudo's CORE.setting: Stage parse      : Label with no handler passed to newlexotic
20:51 timotimo well, d'oh
20:53 jnthn wtf, 453 basic blocks...
20:55 timotimo a long cascade of ifs? :)
20:58 jnthn No
20:58 jnthn a complicated token
20:58 jnthn or rule
20:59 jnthn oh...
20:59 jnthn I see
21:00 timotimo i'm still wondering if we're missing anything special that'd make our parsing faster thanks to spesh
21:00 timotimo special/specific
21:21 Ven joined #moarvm
21:36 timotimo just run a nqp-moar vs nqp-moar-jit and it doesn't seem to give big differences :(
21:37 timotimo charrange                            556/s     219094/s
21:37 timotimo 393.8x         1.0x
21:37 timotimo charrange_ignorecase            22890104/s      13288/s
21:37 timotimo 1.0x      1722.6x
21:37 timotimo what now? o_O
21:38 timotimo japhb or japhb_, are you here?
21:38 jnthn Yeah, I don't think the OSR kicks in really on NQP, though
21:39 jnthn As brrt noted a few days back
21:39 timotimo we don't emit osrpoint instructions there yet?
21:39 jnthn We do
21:39 jnthn But the mainline is varargs or something
21:39 jnthn Which upsets OSR
21:39 timotimo oh? damn.
21:41 timotimo hm, actually, no need to bother japhb about this i guess
21:41 timotimo i wonder what the F is up with my measurements of the charrange benchs
21:44 dalek MoarVM: 6f20346 | jnthn++ | tools/update_ops.p6:
21:44 dalek MoarVM: Fix missing MVM_PUBLIC in update_ops code-gen.
21:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6f20346561
21:44 dalek MoarVM: 2ce6988 | jnthn++ | src/ (5 files):
21:44 dalek MoarVM: Enable inlining of lexotic.
21:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2ce69887cd
21:47 timotimo should i run benchmarks with a rakudo after the inlining of lexotics patch?
21:48 jnthn Can try it :)
21:48 jnthn Also with what I pushed to Rakudo itself just now
21:49 timotimo will you bump the revision?
21:49 timotimo that'll also make facts discovery for rakudo's extops actuall yhappen
21:50 timotimo nqp/2014.07 seems to win score-wise against the current nqp with or without jit :\
21:51 timotimo jnthn: if the proto can't .soft, shouldn't that be taken as the same as .soft == 0?
21:55 jnthn It pretty much always can, iirc
21:55 jnthn It's just guarding agaisnt a crash
21:55 timotimo OK
21:59 dalek MoarVM/esc: 76a6bfa | masak++ | tools/update_ops.p6:
21:59 dalek MoarVM/esc: [tools/update_ups.p6] factor out some repetition into sub
21:59 dalek MoarVM/esc: review: https://github.com/MoarVM/MoarVM/commit/76a6bfaf2c
21:59 dalek MoarVM/esc: 03ac282 | masak++ | tools/update_ops.p6:
21:59 dalek MoarVM/esc: [tools/update_ops.p6] introduce grammar for ops
21:59 dalek MoarVM/esc: review: https://github.com/MoarVM/MoarVM/commit/03ac282af9
21:59 dalek MoarVM/esc: 439efca | masak++ | tools/update_ops.p6:
21:59 dalek MoarVM/esc: [tools/update_ops.p6] integrate two grammars
21:59 dalek MoarVM/esc: review: https://github.com/MoarVM/MoarVM/commit/439efca997
22:02 jnthn Nice :)
22:02 jnthn masak++
22:02 masak well, it's a start.
22:04 jnthn Fixes the spaces in adverbs thing, at least :)
22:04 masak hm, not quite yet :)
22:04 masak working on that one now ;)
22:04 jnthn oh... :)
22:05 * jnthn bbi10
22:21 dalek MoarVM/esc: b436429 | masak++ | tools/update_ops.p6:
22:21 dalek MoarVM/esc: [tools/update_ops.p6] integrate :esc parsing into main parser
22:21 dalek MoarVM/esc:
22:21 dalek MoarVM/esc: This kills off another re-parse of the contents of :esc(...)
22:21 dalek MoarVM/esc: and, as a side bonus, allows us to use spaces between the arguments.
22:21 dalek MoarVM/esc: review: https://github.com/MoarVM/MoarVM/commit/b436429cc1
22:21 dalek MoarVM/esc: 96ec3fe | masak++ | src/core/oplist:
22:21 dalek MoarVM/esc: [src/core/oplist] add some spaces
22:21 dalek MoarVM/esc:
22:21 dalek MoarVM/esc: The parser in tools/update_ops.p6 can handle it now.
22:21 dalek MoarVM/esc: review: https://github.com/MoarVM/MoarVM/commit/96ec3fe81b
22:24 dalek MoarVM/esc: 6a4d07a | masak++ | tools/update_ops.p6:
22:24 dalek MoarVM/esc: [tools/update_ups.p6] remove empty line
22:24 dalek MoarVM/esc: review: https://github.com/MoarVM/MoarVM/commit/6a4d07a901
22:30 jnthn update_ups? :)
22:30 masak uups.
22:31 masak I made that typo a number of times, and caught it in time. apparently not this time :)
22:31 raiph joined #moarvm
23:03 timotimo i wonder if we can optimize the random functions in rakudo by knowing when we don't have to do bigint at all ...
23:03 timotimo but maybe we already do that properly?
23:04 jnthn Do we know they're a hot spot, or slow?
23:05 timotimo we do have a rand benchmark
23:05 timotimo í'll see if it's slow or fast soon :)
23:07 timotimo it's a bit annoying that the speed benefits are hiding behind these silly reasons, so that we can't get to measure them properly with our benchmarks
23:07 timotimo like the slurpy args for the mainline
23:08 timotimo how can the mainline even have arguments; does it have an implicit *@ARGV signature?
23:08 jnthn I think it's that, yeah
23:08 jnthn In Rakudo we've got it arranged a bit differently so that doesn't happen.
23:08 timotimo do we have a solution coming up soon-ish?
23:09 jnthn I can probably figure something out without too much trouble.
23:12 timotimo would be neat
23:14 timotimo performance scores look quite good for current rakudo vs the 2 previous releases
23:14 jnthn ooh
23:15 * jnthn awiats les graphicales
23:15 timotimo oh
23:15 timotimo i thought i'd get a rakudo master in first
23:16 jnthn Oh...I thought "current rakudo" meant "master" :)
23:16 timotimo ah
23:16 timotimo current rakudo release* :)
23:16 jnthn ah, ok
23:49 timotimo jnthn: http://t.h8.lv/p6bench/2014-07-27-long-time-rakudo.html
23:55 jnthn Hm. Some minor improvements.
23:56 jnthn Curious. We got worse at visit_2d_indices_while_native
23:56 jnthn In every relesae since 2014.06
23:58 timotimo wtf happened with the charrange benchmarks %)
23:58 jnthn no idea
23:58 jnthn something's up there
23:59 timotimo "up" is the right term

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