Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-30

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

All times shown according to UTC.

Time Nick Message
00:04 timotimo huh
00:04 timotimo why is there an implementation of istype in the jit?
00:04 timotimo 1) it turns into a call to MVM_6model_istype, but pretends the return value is void and
00:04 timotimo 2) it can be invokish
00:07 dalek MoarVM/jit-moar-ops: 8c79da9 | (Timo Paulssen)++ | src/jit/graph.c:
00:07 dalek MoarVM/jit-moar-ops: istype is invokish and its return value ought to be INT, not VOID
00:07 dalek MoarVM/jit-moar-ops:
00:07 dalek MoarVM/jit-moar-ops: so i just comment it out for the time being.
00:07 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/8c79da96c1
00:07 dalek MoarVM/jit-moar-ops: d25255a | (Timo Paulssen)++ | src/jit/graph.c:
00:07 dalek MoarVM/jit-moar-ops: support for bindpos_i is trivial to add
00:07 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/d25255a07c
00:07 dalek MoarVM/jit-moar-ops: f5229ae | (Timo Paulssen)++ | src/ (3 files):
00:07 dalek MoarVM/jit-moar-ops: add isint/isnum/isstr/islist/ishash
00:07 dalek MoarVM/jit-moar-ops:
00:07 dalek MoarVM/jit-moar-ops: in the interest of finding out what other ops will cause
00:07 dalek MoarVM/jit-moar-ops: bails down the road. These ops ought to be implemented
00:07 dalek MoarVM/jit-moar-ops: by generating a tiny bit of assembly code instead of a
00:08 dalek MoarVM/jit-moar-ops: 15cb79e | (Timo Paulssen)++ | src/ (3 files):
00:08 dalek MoarVM/jit-moar-ops: add isint/isnum/isstr/islist/ishash
00:08 dalek MoarVM/jit-moar-ops:
00:08 dalek MoarVM/jit-moar-ops: in the interest of finding out what other ops will cause
00:08 dalek MoarVM/jit-moar-ops: bails down the road. These ops ought to be implemented
00:08 dalek MoarVM/jit-moar-ops: by generating a tiny bit of assembly code instead of a
00:08 dalek MoarVM/jit-moar-ops: C call, but i leave that for brrt++ to do.
00:08 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/15cb79eaff
00:11 timotimo wtf
00:11 timotimo out of nowhere, 128 bails for jumplist have appeared
00:19 timotimo with jit-moar-ops, i cannot build nqp any more. i get a strange error:
00:19 timotimo /usr/bin/perl tools/build/gen-cat.pl moar src/QRegex/P5Regex/Grammar.nqp src/QRegex/P5Regex/Actions.nqp src/QRegex/P5Regex/Compiler.nqp  > gen/moar/stage2/NQPP5QRegex.nqp
00:19 timotimo ./nqp-m --target=mbc --output=NQPP5QRegex.moarvm \
00:19 timotimo gen/moar/stage2/NQPP5QRegex.nqp
00:19 timotimo Unhandled exception: Missing or wrong version of dependency 'gen/moar/stage1/nqpmo.nqp'
00:19 timotimo at <unknown>:1  (./NQPHLL.moarvm::1070)
00:31 timotimo well, jumplist is getting more and more interesting :)
00:37 dalek MoarVM/jit-moar-ops: 7483c74 | (Timo Paulssen)++ | src/jit/graph.c:
00:37 dalek MoarVM/jit-moar-ops: implement iscclass
00:37 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/7483c74f0a
00:37 dalek MoarVM/jit-moar-ops: 55a74f0 | (Timo Paulssen)++ | src/jit/graph.c:
00:37 dalek MoarVM/jit-moar-ops: implement nfarunalt
00:37 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/55a74f0727
00:37 dalek MoarVM/jit-moar-ops: f5cd5be | (Timo Paulssen)++ | src/jit/graph.c:
00:37 dalek MoarVM/jit-moar-ops: implement substr_s and index_s
00:37 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/f5cd5be02c
00:39 timotimo sadly can't implement ne_s, as it'd need a negation in addition to the call to MVM_string_equal ...
00:42 timotimo i think that's pretty much all the hot ops i can implement properly
00:43 timotimo the rest is just ops that we run into fewer than 10 times
00:45 hoelzro I would say "cool", but I don't really understand what you're doing right now timotimo  =)
00:47 dalek MoarVM/jit-moar-ops: cc9e819 | (Timo Paulssen)++ | src/jit/graph.c:
00:47 dalek MoarVM/jit-moar-ops: fix setelemspos
00:47 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/cc9e819ac3
00:47 dalek MoarVM/jit-moar-ops: bd0c3b9 | (Timo Paulssen)++ | src/jit/graph.c:
00:47 dalek MoarVM/jit-moar-ops: push_n and push_s are also easy.
00:47 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/bd0c3b931e
00:47 timotimo well
00:48 timotimo the jit will be invoked for every frame that spesh generates and that is considered even hotter still
00:48 timotimo it will just optimistically run and as soon as it sees an op that it doesn't know, it'll bail
00:48 timotimo it also writes "BAIL" and the name of the op into the jitlog
00:48 hoelzro ah, I read about that on your blog
00:48 timotimo yup
00:48 hoelzro pretty cool stuff =)
00:48 timotimo these ops i'm implementing are ops that i can just map 1:1 to C function calls
00:49 hoelzro but something about how the JIT doesn't generate faster code yet?
00:49 timotimo well, there's multiple parts to that problem
00:49 timotimo for one, it doesn't know how to deal with perl6's extops, like p6bind, p6bool, ...
00:49 timotimo so it wouldn't be used in any of the benchmarks we have
00:49 hoelzro ah ha
00:50 timotimo the other part is that the "mainline" of programs have variadic arguments, which makes spesh itself bail before even trying to do anything
00:50 hoelzro so it may benefit NQP, but not Rakudo (yet)?
00:50 timotimo so neither the perl6 benchmarks nor the nqp benchmarks will show any difference at all
00:50 timotimo except slower run-time, because it tries to jit things here and there
00:50 hoelzro ah ha
00:50 timotimo it can benefit perl6 programs, but only for frames where we generate super tight code and also don't hit any extops
00:50 hoelzro I see
00:50 timotimo i have no idea how many that would be
00:51 timotimo https://gist.github.com/timo/f92ff69eb404592b3a51/revisions ← look at these diffs, it's fun to look at how implementing one op removes it completely, but ups the counter on a bunch of other ops
00:52 hoelzro yiks
00:52 hoelzro *yikes
00:52 timotimo refresh for one more
00:52 timotimo ah, look!
00:52 timotimo i implemented push_s and 4 bails disappeared, no bails were added
00:52 timotimo that means we were able to jit-compile 4 more frames! :)
00:53 timotimo oh, interesting
00:53 timotimo all of these 4 frames were versions of !dba
00:55 hoelzro \o/
00:55 timotimo the sum of the "bytecode size" lines is 429597
00:55 timotimo whatever that means :)
00:56 * hoelzro shrugs
00:56 hoelzro I burned myself out on Moar stuff last night
00:57 hoelzro so timotimo++ for soldiering on
00:59 timotimo https://gist.github.com/timo/f13611f6d587bb1e9188 - lookie here
01:00 hoelzro whoa
01:00 timotimo turning off the jit actually makes it faster at the moment
01:00 hoelzro 40 second parse?
01:00 timotimo but it's still way faster than without spesh at all
01:00 timotimo yeah, this is just my laptop
01:00 hoelzro I think I get 120 seconds
01:01 timotimo huh?
01:01 timotimo when was that %)
01:01 * hoelzro tries again
01:01 timotimo well, okay, this laptop is only half a year old
01:01 hoelzro gah, I'll wait until after nqp-js tests fniish
01:01 timotimo and was pretty up-to-date at that time
01:01 hoelzro I built my desktop like 3 months ago o_O
01:01 hoelzro and it's the fastest machine I've built perl6 on!
01:02 hoelzro ok, let's see...
01:02 timotimo there must be something wrong, surely
01:05 hoelzro ok, I'm on drugs
01:05 hoelzro 46 seconds
01:05 hoelzro maybe I was thinking about parrot speeds?
01:05 * hoelzro should really resume S26 work
01:06 timotimo i like S26
01:06 hoelzro you wanna help? =)
01:07 timotimo i've already done a lot way back when :S
01:07 timotimo the code was strenuous to wade through, tbh
01:07 timotimo i had hoped i could refactor the parsing of pod completely
01:07 timotimo make it more "parametric"
01:07 hoelzro ugh, I had the same hope
01:07 hoelzro at this point, I feel like I've done an "ok" job
01:08 timotimo (>^_^)>
01:08 hoelzro there's still much to be done
01:09 hoelzro so I should stop chasing Moar bugs, playing with nqp-js, and messing with lib/Test.pm =)
01:09 timotimo now i implemented tc, lc, uc and it split into le_s (which is now at 1) and ordat (which is now at 6)
01:09 hoelzro tbf, the first was a result of the last!
01:09 hoelzro huh
01:09 hoelzro it's like trying to plug a leaky boat
01:09 timotimo ordat wants a bit more than just a call to the C, it wants to verify the string's length, too
01:10 timotimo well, yeah :)
01:10 timotimo but it's kind of a fun boat
01:10 hoelzro =)
01:10 timotimo tomorrow brrt will implement sp_findmeth, which will cause an explosion of new bails
01:11 hoelzro oh joy
01:11 timotimo it'll potentially spread out into 358 individual ops and ++ all of them :P
01:11 * hoelzro .oO( bailing out a boat? )
01:11 timotimo (i don't think we have that many ops)
01:11 timotimo oh, huh
01:11 timotimo 650 is the last line of the oplist file that contains non-sp ops
01:11 hoelzro so, how does that work? I figured once you implemented the JITing for one op, it wouldn't show up again?
01:11 timotimo 40 is the first one
01:11 timotimo so we have 610 individual ops? wow.
01:12 timotimo that's right
01:12 hoelzro so everytime you implement one, you potentially incr the counts of other unimpl'd ones?
01:12 timotimo yup
01:12 timotimo maybe even from 0
01:13 hoelzro grr
01:13 timotimo look at the very first diff on that page
01:13 timotimo that was when i implemented bindpos_i
01:13 timotimo 32 less for bindpos_i
01:13 timotimo 1 more iscclass, 1 more indexat, 20 more islist, 10 more sp_findmeth
01:14 hoelzro nuts
01:14 timotimo so not a single extra frame got compiled after that
01:14 timotimo but later i implemented islist
01:14 timotimo that's the next diff, one up
01:14 timotimo that diff confused me, though
01:15 timotimo didn't actually do the counts there
01:15 timotimo oh, i also un-implemented istype there
01:15 timotimo i'm surprised it didn't blow up majorly; istype would always leave the value in the register untouched
01:16 timotimo oh, hold on
01:16 timotimo i think i was wrong about *that* part
01:16 timotimo but still, istype is an invokish op, the jit has to be extra careful around these
01:16 hoelzro I see
01:16 hoelzro it's pretty cool
01:17 hoelzro I can't wait to see how well Moar does after the JIT is fully in place
01:17 timotimo aye.
01:18 timotimo i wonder how long the core setting compilation would take if we subtracted the time it takes to attempt a compilation and bail in the middle of it
01:19 timotimo i.e. if it'd be worth it already
01:19 timotimo the thing is, we still read and write from the working memory before and after every single translated op
01:20 timotimo brrt is going to implement a nontrivial feature in dynasm for that to improve
01:20 TimToady you might want some kind of pragma to say "Don't attempt to jit this bit for now."
01:20 timotimo i.e. keeping values in registers between ops
01:20 TimToady if you know it's going to bail
01:21 timotimo i'd assume it's not worth the time it'd take to implement :)
01:21 TimToady 'course then you fix the optimizer to work with that bit, and then it doesn't jit, d'oh
01:22 timotimo gotta run for now :)
01:22 hoelzro later timotimo
01:26 timotimo :)
02:01 btyler joined #moarvm
02:05 btyler joined #moarvm
02:29 jimmyz joined #moarvm
02:29 jimmyz Stage parse      :  39.273, before: 44
02:30 jimmyz since yesterday
02:31 timotimo sweet :)
02:31 timotimo jnthn made some pretty radical improvements in nqp, and a few in moarvm as well
02:31 timotimo i'm assuming you're on nom/master/master?
02:35 btyler joined #moarvm
02:37 jimmyz timotimo: yeah
02:37 timotimo yeah what exactly? :)
02:38 timotimo lizmat: just don't try the moarvm/jit-moar-ops branch with --enable-jit; it's slower than what we have with spesh, but it's still faster than without spesh
02:39 timotimo i only really wanted to benchmark the json thing, but i ended up kicking off a complete benchmark run ... oh well
02:39 timotimo when it's done with rakudo-moar, nqp-moar will only take about half the time ... :)
02:40 jimmyz timotimo: I'm on nom/master/master :P
02:41 btyler joined #moarvm
02:44 timotimo ah
03:42 itz joined #moarvm
04:19 ventica joined #moarvm
04:19 ventica o/
05:36 jnap joined #moarvm
05:59 FROGGS joined #moarvm
06:02 nwc10 jnthn: setting...
06:02 nwc10 was: cmd: Rounded run time per iteration: 7.3881e+01 +/- 9.3e-02 (0.1%)
06:02 nwc10 now: cmd: Rounded run time per iteration: 7.1820e+01 +/- 4.2e-02 (0.1%)
06:02 nwc10 win. (about 2.5% win)
06:14 brrt joined #moarvm
06:15 brrt \o
06:15 brrt timotimo: istype is correct i believe, the function is actually marked as invokish in oplist (which means it's handled), and it's passed the address of the destination register, thus the return value is void
06:16 brrt thanks for bringing it to my attention, though :-)
06:17 sergot hi o/
06:18 brrt also, seeing that core.setting benchmark makes me sad
06:18 brrt o/ sergot
06:21 brrt oh, you said that already
06:22 brrt much timotimo++ for hard work, though
06:40 jnap joined #moarvm
06:54 zakharyas joined #moarvm
07:18 nwc10 brrt: which benchmark, and why sad?
07:18 brrt nwc10: https://gist.github.com/timo/f13611f6d587bb1e9188 this one
07:18 brrt and although i think there's a logical enough explanation for it, it still hurts
07:19 nwc10 I didn't say, but I didn't see faster setting compiles with JIT
07:40 oetiker joined #moarvm
07:46 jnap joined #moarvm
07:46 oetiker joined #moarvm
08:02 nwc10 ==30641==     in use at exit: 776,094,561 bytes in 2,625,245 blocks
08:02 nwc10 ==30641==   total heap usage: 17,741,594 allocs, 15,116,349 frees, 3,670,670,682 bytes allocated
08:03 nwc10 not quite a fair comparison with http://irclog.perlgeek.de/moarvm/2014-07-29#i_9101664 as the former is the JIT, the latter is not, and JIT will allocate more
08:03 nwc10 botu quite a lot less allocation
08:03 FROGGS joined #moarvm
08:06 * brrt is further triangulating the regex bug
08:42 brrt hmm, very interesting
08:44 * brrt is now hoping this is some sort of OSR bug
08:47 brrt correction, a JIT-OSR bug
08:51 brrt and, it's not that
08:52 brrt /me brb
09:03 jnap joined #moarvm
09:25 brrt joined #moarvm
09:37 brrt ok, long story short, it isn't OSR
09:38 * jnthn tries to find yesterday's number
09:38 jnthn (for allocated)
09:39 brrt o/ jnthn
09:40 jnthn nwc10: oh wow, that's like, a third to a quarter of what it was.
09:40 jnthn o/ brrt
09:40 jnthn In other news, yay, I have a working keyboard
09:40 jnthn On my laptop
09:40 brrt \o/
09:40 jnthn :))))) <== I can smile again and it works
09:41 brrt in other news, i'm hardly a step further in the regex bug business
09:41 jnthn Regex bug?
09:41 jnthn It was a mis-code-gen, or?
09:42 brrt probably
09:43 brrt basically, the t/qregex/01-qregex.nqp test breaks reliably with iter, but not without
09:43 japhb_ joined #moarvm
09:43 brrt because the QRegex compiler doesn't compile the regex with jit
09:44 brrt and.. i have /still/ no idea why exactly this is
09:44 [Coke]_ joined #moarvm
09:44 TimToady_ joined #moarvm
09:45 cognome joined #moarvm
10:06 brrt boxing ops aren't normally invokish, are they?
10:06 jnthn No
10:06 jnthn Never
10:08 brrt hmm no, you're right
10:08 brrt that'd be weird
10:09 brrt ok, no need to look there
10:12 jnthn lunch; bbiab
10:25 jnap joined #moarvm
10:37 * brrt back from lunch :-)
10:50 brrt y this no work
10:53 nwc10 jnthn: as stated in #perl6, MoarVM about 6.5 times faster than parrot at compiling the setting
10:56 nwc10 will take 27 more 2.5% speedups to get to a factor of 10
10:56 brrt \o/
10:56 * brrt wonders if JIT will get us there once it ACTUALLY WORKS
10:56 brrt and what an actual optimizing JIT could make of regexes
11:18 brrt well, it isn't istrue combined with iter
11:18 brrt because that looks just dandy
11:19 brrt tl;dr
11:19 brrt 'ok frame is ok'
11:28 jnap joined #moarvm
11:44 brrt y u compile so much
12:28 timotimo brrt: do you feel like jit-moar-ops could be merged into master? it seems to compile rakudo and nqp just fine
12:30 Ven joined #moarvm
12:30 timotimo also, i would revert the "omg istype is probably broken!" commit
12:30 timotimo oh, i was wrong, there's still the "missing or wrong version of dependency nqpmo.nqp" thing when building nqp
12:31 brrt make clean
12:31 brrt :-)
12:32 brrt i'll check it in a bit
12:32 brrt i'm stepping through the frame now
12:34 timotimo make clean doesn't help
12:34 brrt hmm what
12:34 brrt weird
12:43 brrt 32 bytes seems a bit small for fastcreate, no?
12:43 timotimo don't know?
12:43 timotimo don't understand the context
12:58 timotimo i was wondering ... if we have a string that's mostly ascii-encodable, but has a few multibyte-utf8-chars here and there, we could pick it apart into multiple strands and have direct jump-to-correct-byte-for-offset access to big parts of the string
12:59 nwc10 you can do that by using any fixed with encoding, without needing strands
13:00 timotimo yeah, but if we have a 20k character string with a single ö in it, we'd blow it up to 4x the size (if we use ucs-32)
13:00 nwc10 possibly at the cost of more memory. But the overhead of tracking the multiple strands will not be free
13:00 nwc10 agree. but implementing the 8 bit NFG would also address this
13:00 timotimo next thing i'll do is get a c-level profile of parse-json
13:01 nwc10 mostly it's only going to be 2x the size, if we can use ucs-16
13:02 timotimo except ucs-16 isn't a fixed-width encoding
13:02 timotimo well, not in the strict sense
13:02 timotimo if we do analyze the string up front, then yeah
13:07 timotimo set and decont are kinda hot
13:09 timotimo interesting, guardconc is also considered hot
13:10 timotimo well, all these "hot" things are probably just "warm"
13:10 timotimo another warm instruction is in getspeshslot
13:10 brrt getspeshslot? i thought i did that already
13:10 brrt as well as guardconc
13:11 timotimo i'm probably reading this wrong
13:11 timotimo this is trying (and failing) to interpret a report from perf, not a jit bail log
13:12 timotimo MVM_frame_decref is warm, too
13:14 timotimo are you interested in a bail log for parse-json?
13:15 timotimo https://gist.github.com/timo/89aafc240d13748e4278 - this is from the perl6 version of that benchmark
13:15 timotimo AFK
13:20 brrt yes, i am
13:20 brrt paramnameused is a big one
13:20 brrt I CAN"T FIND THE SOURCE OF THIS BLOODY BUG
13:23 brrt and i'm not starting anything until i found it
13:35 jnthn brrt: Hm, I should probably take a look this evening :)
13:36 jnthn See if I can spot anything of note :)
13:37 brrt i'd be delighted :-)
13:37 brrt this feels something between Real Work and a Complete Waste Of Time
13:38 klaas-janstol joined #moarvm
13:38 brrt because i'm truly so little further
13:39 jnthn What do we know so far? Where do you have to disable JIT to make it work?
13:40 brrt what i know is that disabling iter and friends make it run, if only because it disables many if not all regex methods
13:40 jnthn ah, ok
13:41 jnthn Well, every regex method uses jumptable too
13:41 jnthn So it won't be a regex method per se
13:41 jnthn It may well be something in the regex engine though
13:41 brrt timotimo also reported not being able to run because of missing or wrong dependency complaints, but i typically get that when moarvm and nqp no longer feel like they agree
13:41 jnthn like MATCH or CAPHASH
13:41 brrt well, i know have the exact frame that was compiled just the moment before the errors start
13:42 brrt so i'm hoping that should give some insight
13:42 brrt and yes, it uses iter
13:42 brrt but i've not seen anything weird yet
14:32 timotimo brrt: fwiw, disabling the jit for only the single call that fails with "blah dependency" doesn't fix it; disabling the jit completely does, however
14:33 brrt you've made quite a few problems for me this week :-)
14:35 timotimo the good kind of problem, i hope
14:36 brrt pff
14:36 brrt lets just say you've uncovered a boat load of jit bugs :-)
14:36 timotimo :)
14:38 brrt waitaminute
14:40 brrt why... why does shift_o bottom out as an u8?
14:45 timotimo oh noes! did i do that wrong? ;(
14:45 timotimo i don't see anything wrong with my implementation off-hand
14:47 dalek MoarVM/jit-moar-ops: e4f28ab | (Timo Paulssen)++ | src/jit/graph.c:
14:47 dalek MoarVM/jit-moar-ops: istype is actually totally correct; i didn't see the REG_ADDR
14:47 dalek MoarVM/jit-moar-ops:
14:47 dalek MoarVM/jit-moar-ops: also, it's marked as "invokish", so the jit knows how to
14:47 dalek MoarVM/jit-moar-ops: deal with that part of the problem at least.
14:47 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/e4f28ab01d
14:47 brrt no, probably not
14:52 brrt hmm.. gdb is just funky i guess
14:54 timotimo that's not a good sign ...
14:55 brrt that's optimization for you
15:05 dalek MoarVM/jit-moar-ops: 542fe59 | (Timo Paulssen)++ | src/jit/graph.c:
15:05 dalek MoarVM/jit-moar-ops: implement uc, lc, tc.
15:05 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/542fe59b5d
15:06 dalek MoarVM/jit-moar-ops: 5239e3e | (Timo Paulssen)++ | src/ (3 files):
15:06 dalek MoarVM/jit-moar-ops: implement splice.
15:06 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/5239e3ec39
15:24 dalek MoarVM/jit-moar-ops: bca161a | (Timo Paulssen)++ | src/jit/graph.c:
15:24 dalek MoarVM/jit-moar-ops: implement split.
15:24 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/bca161a397
15:24 timotimo implementing split caused 2 more frames to be compiled in the core setting! :)
15:24 timotimo 1.5k frames still bailing out, though
15:26 [Coke] q; is having other folks committing to the jit stuff at all confusing for final grading?
15:26 [Coke] (it's awesome for the community and I entirely support it; just don't want to screw up grading)
15:26 timotimo the contributions i make are all trivial
15:39 brrt \o/
15:39 brrt not so trivial, they have to be correct too
15:39 brrt git can get you a log of all my commits and changes
15:43 ventica joined #moarvm
15:49 TimToady brrt++'s work is already awesome; it would be difficult to ruin his grade :)
15:51 TimToady just having the framework in place is a great thing, even if there are still enough opcodes and/or bugs at the end to mask the eventual performance improvements
15:53 TimToady JIT by definition tends to perform poorly when there are scattered weak links in the chain of opcodes, which can result when you have code in a language that is not well designed for JIT :)
15:53 brrt i would add that if you didn't know you were going to do a JIT right at the start (e.g., LuaJIT-2.0), it can be difficult in any language
15:54 TimToady I think the JIT performance vs effort curve will typically look like a hockey stick.
15:54 brrt and i would further add that some things which are o so simple in plain-old-c can be devillish in ASM :-)
15:54 * brrt certainly hopes so
15:54 brrt until we hit another barrier
15:55 brrt and then it'll be flat again for a while, and given enough effort, might increase again
15:55 TimToady pity we don't have a language designer around to fix the language... :)
15:55 brrt so perhaps sigmoidal?
15:55 TimToady prolly
15:57 carlin sounds like a stair-case
15:57 TimToady "It'f fubconfiouf!" --Sigmoid Frund
15:59 * brrt dinner &
16:45 brrt joined #moarvm
16:46 brrt we should be able to dump the moarvm call stack using moar-gdb.py
16:46 jnthn Can you not just MVM_dump_backtrace(tc); in gdb?
16:47 timotimo you should be able to
16:50 klaas-janstol joined #moarvm
17:02 FROGGS joined #moarvm
17:33 vendethiel joined #moarvm
17:39 brrt i'll try, but tc has been... optimized out :-(
17:41 brrt why, that does explain a lot
17:51 brrt although it puzzles me why there's an invoke there
17:51 jnthn "there"?
17:51 * jnthn has nommed and will attempt to work in his unwanted free home sauna
17:53 brrt there is this, it seems
17:54 brrt https://github.com/perl6/nqp/blob/master/src/QRegex/P6Regex/Grammar.nqp#L353
17:55 jnthn I'm extremely surprised if you're in a JIT-compiled cclass_elem in so far as we don't compile jumptabl yet...
17:55 brrt well, the code fragment within is compilable :-)
17:55 jnthn ah, yes
17:56 brrt anyway, bbi2h or so :-)
17:56 jnthn ok
17:56 brrt i think my %seen creates a bindlex?
17:56 jnthn It's just a decl afaik
17:57 brrt there's a bindlex i can't really explain otherwise
17:57 brrt but, i'll be really of now
17:58 jnthn OK. Lemme know when you're back; I can look through the disassembly.
18:05 jnthn m: say 1041064 * 64
18:05 camelia rakudo-moar 11e193: OUTPUT«66628096␤»
18:06 jnthn m: say (1041064 * 64) / 4194304
18:06 camelia rakudo-moar 11e193: OUTPUT«15.885376␤»
18:11 timotimo what awesome patch do you have for us now? :)
18:11 timotimo also ... aaw, no brrt for 2 hours? :(
18:14 Ven joined #moarvm
18:24 jnthn Will let you know in 5 mins if I have one :)
18:35 * TimToady is always disappointed when he reads that jnthn will not be available till evening, till he remembers that jnthn's evening comes, like, nine hours earlier :)
18:35 jnthn :)
18:35 jnthn I realized that every alternation and protoregex evaluation ended up taking a closure for a needless reason.
18:36 FROGGS I believe there a a lot of spots in our codebase like that
18:37 TimToady sugoi!
18:38 TimToady which, as in english awesome/awful or terrific/terrible, can mean both really good and really bad, though usually good
18:38 TimToady cf awfully good and terribly good
18:41 TimToady not that STD's regex engine isn't chockablock full of closures to emulate laziness...
18:48 jnthn m: say 5524580 - 4483251
18:48 camelia rakudo-moar 509b1a: OUTPUT«1041329␤»
18:48 jnthn Yeah, I'll happily make a million less closures, thanks.
18:49 TimToady .oO(we merely have to call the slow-path binder a million times instead...)
18:50 jnthn There's no slow-path binder in NQP :)
18:59 cognome joined #moarvm
18:59 cognominal__ joined #moarvm
19:02 Ven joined #moarvm
19:06 japhb_ Waiting for the day when jnthn can say "There's no slow path in NQP" ...
19:35 brrt joined #moarvm
19:35 cognome joined #moarvm
19:35 brrt jnthn, timotimo: i'm back
19:37 timotimo yay :)
19:37 timotimo turns out i was able to occupy myself with friends & food until brrt came back :)
19:37 brrt i'll have fully annotated dissassembly in about an hour or 2
19:38 brrt (annotating dissassembly is expensive)
19:38 dalek MoarVM: d51a9cf | jnthn++ | src/ (2 files):
19:38 dalek MoarVM: Cache fates array rather than re-allocating.
19:38 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d51a9cff13
19:38 dalek MoarVM: a4ac569 | jnthn++ | / (3 files):
19:38 dalek MoarVM: Cache frame index, to avoid a linear scan.
19:38 dalek MoarVM:
19:38 dalek MoarVM: Turns out linear scans for frame indexes dominated assembly time. With
19:38 dalek MoarVM: this, stage mbc for Rakudo's CORE.setting is a third of what it was.
19:38 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a4ac56952b
19:39 jnthn m: say 35 + 73
19:39 camelia rakudo-moar c9ad80: OUTPUT«108␤»
19:40 jnthn Well under 2 minutes for a full NQP and Rakudo re-build on my box these days. :)
19:41 vendethiel you got a good box :P
19:42 vendethiel what was it like, with last year's parrot ? :)
19:42 jnthn I forget. I suspect CORE.setting alone was in the 2 minute region though.
19:43 timotimo holy hell!
19:43 timotimo down to a third %)
19:43 timotimo that is pretty fantastic
19:44 jnthn Stage mbc was the shortest stage. But still, it's a nice win. :)
19:45 timotimo i always thought it ought to be faster than that
19:47 timotimo the closure thing ought to make all our parsing faster,n o?
19:47 btyler 'Stage mbc        :   0.539' :)
19:48 hoelzro great scott
19:48 timotimo er ... huh
19:48 timotimo oh!
19:48 timotimo stage mbc
19:48 timotimo i thought we were talking about stage mast
19:48 timotimo well, that's still a nice little win :)
19:50 jnthn btyler: Heh, 0.287 here :)
19:51 timotimo 0.275
19:51 timotimo i win :)
19:55 jnthn :P
20:00 tadzik "stage mbc for Rakudo's CORE.setting is a third of what it was" ( ͡° ͜ʖ ͡°)
20:02 timotimo what does that face mean? :\
20:03 jnthn "I know more weird chars than you"
20:04 tadzik yeah :)
20:06 timotimo oke
20:30 brrt ok, apparantly now i'll be iterating a hash, lets see if that does anything strange
20:42 brrt oh, my dumb ass just stepped over the rest of the frame, completely not finding why it doesn't work
20:42 jnthn I normally use a horse rather than an ass, tbh... :P
20:43 jnthn Is the bug certainly in that frame?
20:43 jnthn Also, do you know exactly which frame it is?
20:43 brrt what i know is that there is no bug before that frame is compiled :-)
20:44 brrt i used the break-on-print / break-on-compile technique
20:45 brrt basically, most of the time the compiler JITs quite a few frames of itself, right? so i need to skip these before getting to the frame that i'm really interested in
20:45 brrt i can try the reverse as well, checking if the bug persists if i put something uncompileable in that frame
20:46 Ven joined #moarvm
20:46 brrt anywya, iterating on a VMArray works perfectly
20:48 brrt related question: what's still really uncompileable?
20:54 brrt (plenty of things, of course.. but :-)
20:55 jnthn Well, since we're actually hitting jumplist now sometimes, that means fixing that would get us compiling various regexes.
20:55 jnthn Well, and tokens/rules
20:55 * brrt shivers
20:56 brrt exciting, also very scary
20:57 brrt right now, i'm suspicious of sp_fastcreate
20:57 jnthn Oh?
20:57 jnthn It is JITted to quite a bit of code.
20:58 brrt basically, it creates an object of only 32 bytes large
20:58 brrt thats big enough for a header, but nothing more
21:00 brrt it's a hash iter all right
21:01 brrt and the object is a VMHash
21:01 brrt so far, so good
21:03 brrt also, ,the somewhat funky loop body is transformed into a routine call for reasons unbeknownst to me
21:03 brrt if they hadn't, i wouldn't have seen this bug, so...
21:04 klaas-janstol joined #moarvm
21:06 brrt further spesh opportunities would be - i'd say - creating sp_istrue_iter (and prefereably, sp_istrue_iterhash / sp_istrue_iterarray), and transforming if_o for iters into those + if_i
21:07 brrt that should help a bundle wrt to making a fast implementation
21:07 brrt and it should be easy since iter is almost always followed by unless_o or if_o
21:07 jnthn Yeah
21:08 brrt but that's just, like, my opinion :-)
21:08 jnthn It makes sense.
21:08 brrt (in fact, spesh gives us an opportunity to disintermediate so many things)
21:08 brrt it's really exciting
21:09 brrt i should not forget that, probably, as i'm struggling to understand this
21:09 jnthn Yes, spesh is really about taking away various bits of late bidning.
21:10 brrt and it should also remove the completely uneccesary invokish guard in this case, since istrue for an iter never invokes
21:12 jnthn yeah
21:18 brrt MVMIter shift always returns the hash for a return value? that seems.. odd
21:22 jnthn Not the hash
21:22 jnthn The iterator.
21:23 brrt you're quite right
21:28 jnthn Did investigating sp_fastcerate go any further?
21:29 brrt no, not really
21:29 brrt the object behaves exactly as intened
21:30 brrt it's a VMHash btw
21:30 nwc10 jnthn: ASAN barfage
21:30 nwc10 I need to go to bed
21:30 nwc10 ==8038==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000356b80 a
21:30 nwc10 t pc 0x7fa6838f49bc bp 0x7fff6e2d9900 sp 0x7fff6e2d98f8WRITE of size 8 at 0x619000356b80 thread T0    #0 0x7fa6838f49bb in nqp_nfa_run src/6model/reprs/NFA.c:406
21:31 nwc10 ]blah
21:31 nwc10 0x619000356b80 is located 0 bytes inside of 1088-byte region [0x619000356b80,0x619000356fc0)freed by thread T0 here: #0 0x7fa6841778e6 in __interceptor_realloc ../../.././libsanitizer/asan/asan_malloc_linux.cc:93 #1 0x7fa6838f4970 in nqp_nfa_run src/6model/reprs/NFA.c:403
21:31 brrt and it is precisely as large as it needs to be in fastcreate, namely 32 bytes
21:31 nwc10 without using a debugger, I guess thatthe problem is
21:31 nwc10 fates = (MVMint64 *)realloc(fates, sizeof(MVMint64) * fate_arr_len);
21:31 nwc10 and I would hazard a guess that fate_arr_len is 0
21:32 nwc10 t/spec/S05-metasyntax/longest-alternative.rakudo.moar
21:33 nwc10 Nope
21:33 nwc10 (gdb) p total_fates
21:33 nwc10 $1 = 1
21:33 nwc10 (gdb) p fate_arr_len
21:33 nwc10 $2 = 1
21:33 jnthn Huh, what on earth frees it...
21:34 nwc10 #1 0x7ffff66d6970 in nqp_nfa_run src/6model/reprs/NFA.c:403
21:34 nwc10 the realloc() 3 lines before that kaboom
21:34 jnthn ah
21:35 jnthn Darn, yes
21:36 nwc10 oh, it never assignes back to tc->fates
21:37 nwc10 I mean  tc->nfa_fates
21:37 jnthn yeah, testing a fix here now
21:37 jnthn And wondering if it's actually to blame for the SEGV I thought a different refactor had caused.
21:38 jnthn Yes, it was
21:38 jnthn nwc10++
21:38 nwc10 win!
21:38 nwc10 can I go to bed please? :-)
21:38 jnthn Thanks, that's saved me quite a headache.
21:38 jnthn Yes. Sleep well. :)
21:39 nwc10 glad to be of assistance
21:40 brrt sleep well nwc10 :-)
21:40 brrt you're always of assistance :-)
21:41 brrt (really, hash lookups flatten strings? i can only say... wow)
21:41 jnthn Yeah, for the moment.
21:41 brrt :-)
21:42 jnthn We use uthash but need to moarph it some more to handle our strandy strings.
21:42 brrt all strings will get their own brand new normalization right?
21:42 brrt hmm i see
21:42 brrt then using strandy strings might sometimes be much more expensive than imagined
21:42 jnthn Yeah, for the moment.
21:43 jnthn The string opts so far aren't the end of the work :)
21:43 jnthn Just enough of an improvement for some previously painful benchmarks.
21:44 brrt is suposse VMIter has a value method
21:45 brrt s/is/i/
21:45 dalek MoarVM: 2f16928 | jnthn++ | src/6model/reprs/NFA.c:
21:45 dalek MoarVM: Fix the fates allocation optimization.
21:45 dalek MoarVM:
21:45 dalek MoarVM: It failed to update a code path that reallocated, leading to a use
21:45 dalek MoarVM: after free bug. Found by nwc10++ using ASAN.
21:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2f16928086
21:45 jnthn brrt: Well, VMIter is just a representation
21:45 jnthn brrt: But yeah, it can be on a type with a .value method.
21:46 jnthn brrt: NQP defines an NQPHashIter type with one, iirc
21:46 brrt hmm ok
21:46 brrt i suppose my understanding of 6model is still rather limited
21:46 brrt i.e. i treat a REPR as a class
21:46 brrt but that's pretty much wrong :-)
21:46 jnthn Right
21:47 jnthn REPR is about memory layout
21:47 jnthn Type = meta-object + REPR
21:47 jnthn An STable is per type (the "S" meaning "Shared", as in "stuff things of the same type share in common"
21:47 jnthn )
21:49 brrt ok, i think i get that
21:50 brrt premature optimizer me would say 'how nice would it be if these (meta-obj + repr) could be aligned in memory
21:50 jnthn Well, a meta-obj is just a normal object
21:55 brrt i wonder why i'm starting to like nqp
21:56 brrt f.....
21:56 brrt oh bloody hell
21:56 brrt this can't be serious
21:57 brrt call MVM_dump_backtrace, ASAN kicks in, crashburn
21:57 jnthn :(
21:57 jnthn Did it point out some intresting kind of corruption?
21:57 brrt no, not really, probably just because clang optimized something away
22:03 brrt well, i'm pretty sure now the problem is /somewhere/ in that frame
22:03 brrt except that it seems to work precisely as advertised
22:03 brrt as in, /precisely/ as advertised
22:04 brrt why am i so sure? well, i inserted something that i knew wouldn't compile - namely, eq_n, and lo and behold, test no longer crashes
22:05 brrt the secret is in there
22:07 brrt also, despite being not american and never will be a customer of such a data provider, this scares me terribly: http://blogs.wsj.com/digits/2014/07/30/sprint-tries-a-facebook-only-wireless-plan/
22:09 brrt imagine an internet with only 4 sites
22:09 jnthn ugh
22:09 brrt if i had that when i was young, i never ever would have gotten even as far as i have
22:09 brrt no irc
22:09 brrt no mailing lists
22:10 brrt no msdn, no wikipedia, no random guys blogs
22:10 brrt (or gals)
22:10 brrt no slackware, fedora, debian
22:12 jnthn Yeah. Wow.
22:12 jnthn Quite a step backwards.
22:13 brrt btw, i find it ironic that it's easier to debug a JIT frame for me than to debug interpreted frame
22:14 jnthn o.O :)
22:17 jnthn brr
22:17 jnthn brrt: oh no, I just spotted something and you're not going to like it :(
22:18 jnthn for %seen {
22:18 jnthn next if $_.value < 2;
22:18 jnthn self.worry("Repeated character (" ~ $_.key ~ ") unexpectedly found in character class");
22:18 jnthn }
22:18 jnthn Could it be that "next" there?
22:19 jnthn That's implemented as an exception.
22:19 jnthn I shoulda seen it before, but I was looking at the previous loop :(
22:21 brrt o really?
22:21 brrt well, that's certainly possible, i guess
22:22 jnthn Yeah. Stick a breakpoint in throwcatdyn or so
22:22 brrt ok
22:22 brrt if that's it, you are my hero
22:26 brrt https://gist.github.com/bdw/899799631900fab733fa this is by the way, everything i've collected so far
22:30 brrt that... seems to be it, yet, throwcatdyn is actually called
22:31 jnthn Yes, trace into it and see what it does...
22:31 jnthn It'll unwind a frame and then...do something...with the PC
22:38 brrt well,, the caller frame indeed has a handler
22:38 brrt oh, lord
22:38 timotimo ooooh, are we close to a fix for the hang issues? :)
22:39 brrt well.... we're close to the /reason/ for the hang issues, that much seems certain
22:39 * brrt should have debugged unoptimized code long ago
22:45 brrt i suppose the 'next' exception should've been caught by the frame above it?
22:46 jnthn Yes
22:46 jnthn exception.c attempts to put the PC in the right place...
22:46 jnthn ...then I don't quite know what will happen.
22:46 brrt well, it seems to jump way above that
22:46 brrt i mean way way above that
22:46 brrt why would that be?
22:47 jnthn Well, it will unwind the current frame
22:47 jnthn frame.c has that logic
22:47 jnthn Maybe it's then finding some outdated JIT re-entry address?
22:48 jnthn And re-entering the JITted code at the wrong place
22:48 jnthn Rather than at the place the exception handler points to
22:48 TimToady long run this one oughta just turn into a goto and never throw
22:49 jnthn TimToady: Yeah, that relies on the loop body being inlined...which I don't know why it isn't, tbh
22:49 TimToady basically needs to go to whatever NEXTish logic there is
22:51 TimToady p5 jumps to the continue block, but optimizes that to jump directly to the while condition, loosely speaking
22:51 TimToady (in the absence of a continue)
22:52 TimToady maybe lexical reentry conditions are a problem though
22:52 jnthn Yeah
22:53 jnthn It's already on the Moar todo list this month to optimize various throws into gotos.
22:53 TimToady for %seen has an implicit $_
22:53 jnthn Right
22:53 jnthn I'm a bit surprised it hasn't managed to optimize that away, though.
22:53 TimToady but if you know you're gonna clobber it anyway
22:53 TimToady no need to reclone
22:54 TimToady or whatever it does on entry to the block
22:54 TimToady could become a state var, really
22:54 jnthn Well, creates a frame in theory, but just re-uses the frame from last time in reality.
22:54 * TimToady waves hands encourageingly :)
22:55 TimToady *ging
22:55 jnthn I thought I'd taught NQP how to turn such for loops into not needing to invoke, though.
22:55 jnthn I'll have to look into why the opt didn't work out this time.
22:55 TimToady maybe it's does, and that's why there's no catcher for 'next'?
22:56 TimToady *it
22:56 TimToady just a wag
22:56 TimToady about all I do anymore :)
23:03 ventica joined #moarvm
23:04 brrt as it seems to be, it never re-enters the JIT at all
23:05 brrt which is what i expereience here, too
23:05 brrt oh, i see what's the problem
23:05 timotimo yay!
23:06 brrt basically, search_frame_handlers searches handlers on basis of the current bytecode offset
23:06 brrt i.e. i suppose the handler is a mapping between a throwpoint and a catchpoint
23:06 jnthn Ahhhh
23:07 brrt clearly, when in the JIT, the current bytecode is the magic bytecode
23:07 jnthn Right.
23:07 brrt so that doesn't appear in any handler
23:07 brrt so it wals the stack all the way until it finds something that /does/ have a handler, and continues from there
23:08 brrt the quick fix is to disable JIT compilation on graphs that have handlers, i think?
23:08 brrt and then tomorrow work on adding handlers to the JIT
23:08 brrt somehow, at least
23:10 * brrt ponders a bit on how that should look, but it will probably involve dynamic labels much like OSR
23:10 jnthn brrt: Yes, that could work though might rule out a lot of things
23:13 brrt well, it /should/ rule out a lot of things
23:13 brrt it's broken :-)
23:14 brrt i'll fix it, but for now, it won't work
23:14 jnthn *nod*
23:14 jnthn Yes, agree with the way forward.
23:15 timotimo will you put in that hotfix before bed or tomorrow?
23:15 brrt right now is when i'm testing it
23:15 brrt again, lizmat++ and woolfy++ got me a computer that can speedwise compete with jnthn's :-) so i don't have to wait for compilations so long anymoe
23:15 brrt more
23:16 brrt no more hanging during building
23:16 brrt nqp
23:17 jnthn \o/
23:18 brrt btw, jnthn, it might interest you that the block within for %seen is invoked by invoke_o after JIT (and spesh)
23:18 brrt i.e., not even fastinvoke
23:20 jnthn Yeah, I know why :)
23:20 dalek MoarVM/moar-jit: 7d17cb0 | (Bart Wiegmans)++ | src/jit/graph.c:
23:20 dalek MoarVM/moar-jit: Don't compile frames that have handlers
23:20 dalek MoarVM/moar-jit:
23:20 dalek MoarVM/moar-jit: Handlers and the JIT don't play so nicely together, yet.
23:20 dalek MoarVM/moar-jit: This is because searching a frame handler looks for the
23:20 dalek MoarVM/moar-jit: current bytecode offset, which is all off in the JIT
23:20 dalek MoarVM/moar-jit: because it uses a magic bytecode.
23:20 dalek MoarVM/moar-jit:
23:20 dalek MoarVM/moar-jit: So I'll disable the handlers for now. This fixes a long-standing
23:20 dalek MoarVM/moar-jit: issue whereby adding the iter ops would case infinite loops and
23:20 dalek MoarVM/moar-jit: other weird behavior.
23:20 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7d17cb0498
23:23 brrt jnthn++ for actually finding the cause
23:25 timotimo that was tough.
23:25 jnthn aye
23:25 jnthn brrt++ # persistence
23:25 brrt :-)
23:25 brrt we're not out of the woods yet
23:25 brrt jit-moar-ops, even with the current fix, can't compile nqp
23:26 timotimo darn
23:26 brrt current error: 'No applicable candidates found to dispatch to for 'compile_node'.
23:27 timotimo uh ... huh?
23:27 * brrt hopes something went wrong in jit-moar-ops
23:27 brrt but i doubt it
23:27 brrt what's wrong with that, you think?
23:27 itz_ joined #moarvm
23:31 brrt oh, that's not a JIT bug
23:31 brrt still happens with MVM_JIT_DISABLE=1 :-)
23:31 brrt and not a spesh bug
23:31 brrt maybe a corrupted-install bug
23:32 brrt let's check that first
23:33 brrt thats not it
23:34 jnthn brrt: Do you have a latest NQP?
23:34 brrt i think i do
23:37 brrt hmm
23:37 brrt seems like a jit bug after all
23:37 brrt or, you know, i just don't know
23:38 brrt maybe this is the bug timotimo was talking about
23:38 jnthn Sleep on it? :)
23:38 jnthn Or are you too zoned in? :)
23:39 dalek MoarVM/jit-moar-ops: 7d17cb0 | (Bart Wiegmans)++ | src/jit/graph.c:
23:39 dalek MoarVM/jit-moar-ops: Don't compile frames that have handlers
23:39 dalek MoarVM/jit-moar-ops:
23:39 dalek MoarVM/jit-moar-ops: Handlers and the JIT don't play so nicely together, yet.
23:39 dalek MoarVM/jit-moar-ops: This is because searching a frame handler looks for the
23:39 dalek MoarVM/jit-moar-ops: current bytecode offset, which is all off in the JIT
23:39 dalek MoarVM/jit-moar-ops: because it uses a magic bytecode.
23:39 dalek MoarVM/jit-moar-ops:
23:39 dalek MoarVM/jit-moar-ops: So I'll disable the handlers for now. This fixes a long-standing
23:39 dalek MoarVM/jit-moar-ops: issue whereby adding the iter ops would case infinite loops and
23:39 dalek MoarVM/jit-moar-ops: other weird behavior.
23:39 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/7d17cb0498
23:39 dalek MoarVM/jit-moar-ops: d14351c | (Bart Wiegmans)++ | src/jit/graph.c:
23:39 dalek MoarVM/jit-moar-ops: Merge branch 'moar-jit' into jit-moar-ops
23:39 timotimo may need a clean and then a JIT_DISABLE run from the very beginning
23:39 timotimo that's how one of my problems behaved
23:39 brrt yeah, i suspect that will fix it
23:39 brrt but that's nasty
23:39 brrt it means something in the compilation went wrong
23:40 timotimo yes
23:40 timotimo in a way that doesn't make it crash
23:40 brrt i mean that's which circle of debugging hell?
23:41 jnthn tbh, I'd pull the patches from timotimo++'s branch in one or two at a time until you hit the one that breaks
23:41 brrt yep, that seems like a plan
23:41 brrt again :-)
23:41 brrt :-)
23:41 * brrt is going to sleep on it
23:41 jnthn 'night o/
23:42 brrt timotimo: if you're still awake, btw, when did this first appear?
23:43 brrt 'night :-)
23:44 timotimo oof
23:44 timotimo last night? dunno :(
23:44 brrt well, doesn't matter, i'll find it eventually
23:44 brrt left #moarvm
23:46 timotimo good luck!

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