Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-02

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

All times shown according to UTC.

Time Nick Message
00:03 japhb 2 MB seems like a nice savings to me ...
00:03 japhb Or am I misreading?
00:05 jnthn No, you're not, though we're talking about on CORE.setting :)
00:05 jnthn We'll save some CPU too though, I imagine
00:05 timotimo aye, the time fetching the strings indirectly and then comparing them ... that's gotta be costly
00:06 timotimo mostly the fetching
00:06 TimToady compiling src/mast/compiler.o
00:06 TimToady src/mast/compiler.c: In function ‘form_bytecode_output’:
00:06 TimToady src/mast/compiler.c:1255:53: error: ‘MVMThreadContext’ has no member named ‘str_consts’
00:06 TimToady that's at HEAD
00:06 timotimo oh, why was that thing called "vm"?
00:07 timotimo hold on.
00:07 jnthn Didn't you, like, at least try to compile your change? :P
00:07 timotimo some of these macros take a "vm" argument, but use "tc" instead
00:08 dalek MoarVM: 9154ac3 | (Timo Paulssen)++ | src/mast/nodes_moar.h:
00:08 dalek MoarVM: this argument was called "vm" misleadingly ...
00:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9154ac3437
00:50 cognome joined #moarvm
01:46 FROGGS_ joined #moarvm
03:18 jimmyz joined #moarvm
03:19 jimmyz Stage parse      :  34.374, before ~36s          Stage mast       :  11.899, before ~13s
03:19 jimmyz since yesterday
03:43 xiaomiao death by a thousand papercuts :)
04:21 ventica joined #moarvm
07:00 ventica joined #moarvm
07:17 nwc10 m: say 6.243e+01/6.636e+01; say 6.243e+01/6.597e+01
07:17 camelia rakudo-moar a1a236: OUTPUT«0.940777576853526␤0.946339245111414␤»
07:18 nwc10 jnthn: about 6% less time than mid yesterday's slight slowdown, and 5.5% less than yesterday morning. I think
07:18 nwc10 jnthn: but I do need to be careful, as building parrot tanks the machine performance, because it coredumps twice, filling the disk sufficient to make it slow
08:44 nwc10 setting *with* -flto 6.257e+01
08:44 nwc10 setting without -flto 6.243e+01
08:45 nwc10 so, it makes things fractionally slower, but within the noise
08:45 nwc10 so, not a free win
08:45 nwc10 at least, not for setting building
08:53 timotimo thank you for measuring!
11:17 jnthn afternoon, #moarvm
11:23 FROGGS_ hi all
11:42 dalek MoarVM: c350fe0 | jnthn++ | src/6model/serialization.c:
11:42 dalek MoarVM: Toss dead macro.
11:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c350fe056e
12:26 timotimo oh hey jnthn
12:26 timotimo did you see the performance of "for" benchmarks is still less than it was at our last release?
12:38 jnthn Hmm
12:38 jnthn Oh, because they stupidly put parens around their ranges.
12:38 timotimo %)
12:38 timotimo again? :D
12:38 timotimo time to fix that exact thing a second time
12:38 jnthn And the code-path that stripped away such things is applied after the opt
12:39 timotimo yeah, phase ordering problem yada yada
12:39 jnthn Heh. "Don't write superstitious parens; it'll make yoru code slower" isn't such a bad thing :P
12:40 timotimo %)
12:41 timotimo if i want to specialize smart_numify and smart_strify in the case where they cannot directly unbox, i'd have to do a method call on them; would i need to somehow find a correct callsite to give to prepargs?
12:41 timotimo or is there a prepargs-less method for invocation?
12:41 jnthn No, always need that.
12:42 timotimo in that case i'll do the "can unbox, yay" optimizations first and ignore the method call ones for now
12:49 timotimo hum. smart_strify only tries to unbox a str if the object is concrete ... so i have to test for that fact, too
12:52 * timotimo wonders if brrt can work on moar-jit today
12:54 timotimo wow, the smrt_strify -> unbox opt seems to trigger *very* often
12:55 timotimo (only tested nqp so far)
12:55 timotimo ah, damn, rakudo compilation seems to stumble over it
13:01 timotimo LOL
13:01 timotimo damn you, debug output
13:02 timotimo since gen-cat has been dogfooded, it put a whole bunch of "optimized a call! yay!" lines into the resulting source code %)
13:04 jnthn Yes, fprintf(stderr,...) advised :P
13:10 timotimo that is very true
13:16 timotimo hm. i don't suppose we have a spesh opcode (or general opcode, really) to just take a pointer to MVMObject, reinterpret it as a pointer to MVMString and put it into a register's .s?
13:16 timotimo like sp_get_s without the first pointer dereferencing and with an offset of 0
13:20 jnthn Um, no, and that sounds dangerous
13:20 jnthn What do you want it for?
13:22 timotimo smart_strify checks the reprid of the object and if it is MVMString, it just casts
13:22 jnthn That...uh...should never actually occur
13:22 timotimo in that case, i'll just remove that case from smrt_strify itself :)
13:23 jnthn Can you try removing that case?
13:23 jnthn I really hope we don't rely on it.
13:23 timotimo sure
13:28 timotimo maybe i should have put a printf in there instead of removing it
13:29 timotimo oh
13:29 timotimo it would throw a "cannot stringify this" exception
13:29 timotimo that's fine, then
13:29 timotimo doesn't occur anywhere in rakudo's build
13:29 timotimo does that seem good enough for me to commit the patch?
13:31 jnthn Hm, well, spectest is nice but maybe do that after your other improvements
13:31 timotimo will do
13:44 cognome joined #moarvm
13:44 cognominal joined #moarvm
13:46 cognominal joined #moarvm
13:47 timotimo 29.947 :D
13:47 timotimo sadly, the "advanced" smrt_strify cases don't seem to get triggered by either the build nor "make test"
13:47 timotimo will spectest now.
13:50 timotimo did i understand correctly that we can't currently put new method calls into spesh'd code?
13:51 jnthn I think perhaps we can, it's just tricky to deal with callsite stuff
13:51 timotimo if the interface was more evilness-friendly, i could directly try to inline the target method :P
13:51 jnthn But we need to look at that a bit anyway
13:51 jnthn Well, no, we should just emit the method call and then let the normal logic look over it to decide if it's inlinable.
13:51 timotimo but then i'd also have to find a proper spesh candidate and all that
13:51 timotimo aye
13:52 jnthn Composition always beats hacks.
13:52 timotimo i wasn't very serious about that :)
13:52 timotimo oh, lock.rakudo.moar crashes?
13:52 jnthn Hmm
13:52 jnthn Try it again just in case it's a one-off?
13:52 timotimo was about to
13:52 * jnthn needs to do more stress testing on that sort of stuff
13:53 timotimo waiting for it to finish first
13:53 timotimo the failure from combinations.t was already reported in #perl6 by lizmat
13:54 timotimo although it seems like i have a crash and they had a "not ok"
13:57 timotimo spectests are fine
13:57 timotimo i (or the test harness) misinterpreted an exit(1) as a crash
13:57 timotimo oh, d'oh
13:57 timotimo i didn't save the changes in coerce.c ...
13:58 jnthn fail
14:14 dalek MoarVM: 35687e1 | (Timo Paulssen)++ | src/core/coerce.c:
14:14 dalek MoarVM: we should never depend on this working.
14:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/35687e19ef
14:14 dalek MoarVM: cfafc8d | (Timo Paulssen)++ | src/spesh/optimize.c:
14:14 dalek MoarVM: some smrt_strify can be optimized into simpler ops
14:14 dalek MoarVM:
14:14 dalek MoarVM: like unboxing a string or unboxing num/int and coercing.
14:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cfafc8d773
14:31 timotimo i guess smrt_numify may be worth even more, as it's probably commonly used instead of elems on arrays and hashes
14:32 jnthn yeah
14:35 nwc10 timotimo: did you mean to commit fprintf(stderr, "spesh'd a smrt_strify to unbox and coerce a %d\n", register_type);
14:36 nwc10 and the other sprintf?
14:38 timotimo er, no
14:38 timotimo :)
14:38 dalek MoarVM: 255b466 | (Timo Paulssen)++ | src/spesh/optimize.c:
14:38 dalek MoarVM: didn't mean to keep the debug output around
14:38 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/255b466e83
14:43 jnthn Seems you forget to relesae the temp reg at the end?
14:49 timotimo ah, yes. will fix that in a bit
14:52 timotimo actually, why not right now
14:52 timotimo (i blame the heat)
14:54 dalek MoarVM: 8a9fd7f | jnthn++ | src/mast/compiler.c:
14:54 dalek MoarVM: Toss unused field.
14:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8a9fd7f0b8
14:54 dalek MoarVM: 681ec90 | jnthn++ | src/mast/compiler.c:
14:54 dalek MoarVM: Extract label handling code into functions.
14:54 dalek MoarVM:
14:54 dalek MoarVM: Tidies the code, and will make the upcoming refactor a little easier.
14:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/681ec9052c
14:54 dalek MoarVM: a56d606 | jnthn++ | src/mast/compiler.c:
14:54 dalek MoarVM: Switch over to using label identity for matching.
14:54 dalek MoarVM:
14:54 dalek MoarVM: Means we can elminate a couple of hashes, but also that labels will no
14:54 dalek MoarVM: longer need to have a unique name generated.
14:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a56d606705
15:08 dalek MoarVM: 82ca33d | jnthn++ | src/mast/nodes_moar.h:
15:08 dalek MoarVM: Remove name from MAST_Label; now unused.
15:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/82ca33df97
15:11 timotimo hm. my numify → elems + coerce_in opt doesn't seem to be correct :\
15:14 dalek MoarVM: 4656e18 | jnthn++ | lib/MAST/Nodes.nqp:
15:14 dalek MoarVM: Remove name from MAST::Label and its constructor.
15:14 dalek MoarVM:
15:14 dalek MoarVM: Breaking API change; requires NQP and Rakudo updates.
15:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4656e186d7
15:14 timotimo oh, it could be that the call gets tossed by the unused optimization?
15:14 jnthn timotimo: Is that one you've committed?
15:14 timotimo not yet
15:14 jnthn OK, good...I need to bump
15:14 timotimo this time i'm testing properly before i commit! :P
15:15 jnthn Yes, you probably should be setting usages up on things you add.
15:15 timotimo on temp registers, too?
15:15 jnthn Yes
15:15 timotimo that may explain it :)
15:15 jnthn Dead code elimination will happily kill instructions involving temp registers too :)
15:17 timotimo that fixed it, yay
15:17 timotimo this optimization runs often
15:46 nwc10 jnthn: "works" on "my" machine - 2 spectests currently aren't clear
15:46 nwc10 or are flapping
15:51 zakharyas joined #moarvm
15:53 dalek MoarVM: 84b5348 | (Timo Paulssen)++ | src/spesh/optimize.c:
15:53 dalek MoarVM: release the temp register at the end.
15:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/84b5348d7f
15:53 dalek MoarVM: acaa897 | (Timo Paulssen)++ | src/spesh/optimize.c:
15:53 dalek MoarVM: spesh smrt_numify, bump usage counter of temp reg.
15:53 dalek MoarVM:
15:53 dalek MoarVM: this triggers especially often in combination with a
15:53 dalek MoarVM: MVMArray or MVMHash repr'd object and gives us a
15:53 dalek MoarVM: (usually optimized) elems call + a coerce_in
15:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/acaa8972f8
15:53 timotimo after a spectest and a shower i feel confident pushing this
15:53 timotimo nwc10: yeah, they are for me, too. but when i run them manually, they succeed :(
16:03 timotimo a moar-jit with current master merged is at 30.5 seconds stage parse for me
16:03 timotimo that's hardly any worse than master alone.
16:08 jnthn Yeah. Thing is, when I tried the JIT on various hot loop stuff - even with bojecty code - I was seeing a 50% or so win.
16:09 timotimo did you try counting how often we deopt in the core setting compilation?
16:10 jnthn Yeah. Quite a lot.
16:10 timotimo or should i try that while you do more awesome optimization stuff? :3
16:10 jnthn And then I managed to reduce it a good bit
16:10 jnthn But it's not that costly so far as I can tell
16:10 timotimo how often compared to jumping into jitted code?
16:10 jnthn In fact, deopt from JIT is cheaper than from interpreter in terms of the cost of the deopt itself.
16:10 timotimo ah, that count was before the recent work
16:10 jnthn Didn't count how often we run JITted cdoe
16:11 timotimo fair enough, but if we deopt all the damn time, we'll end up interping all our code instead of running the jitted code :)
16:11 jnthn Yeah.
16:12 timotimo we could probably generate code in the jit output that counts how many opcodes we executed before we bailed due to deopt
16:13 timotimo or we could postpone that to a bit later
16:13 timotimo did brrt say he'd be AFK
16:13 timotimo all weekend?
16:14 nwc10 timotimo: sometimes that means that they are badly written. IIRC one failing was to assume the current directory
16:14 jnthn Think he said he was busy this weekend, yeah
16:14 timotimo ah, ok
16:14 timotimo then i don't need to wonder what's up
16:14 timotimo turns out, that smart numify/stringify were already implemented in the jit anyway
16:14 timotimo but i bet the spesh'd solution ends up cheaper in good cases
16:16 timotimo does it make any sense to spesh away a "not" instruction after an instruction where we know how to negate the result by choosing another instruction? like an isnull + not_i could be just isnonnull
16:17 nwc10 that sounds like bad codegen
16:17 timotimo .o( because the jit doesn't not_i yet )
16:19 nwc10 however, I guess that those sorts of sequences can appear as the result of inlining
16:20 timotimo not only that
16:20 nwc10 so, "how often?" and "how costly?" "how much benefit?"
16:20 timotimo every time the isnull is the result of one operation and the not_i is the result of another ...
16:20 timotimo the jit bails out of 36 frames in the core setting because it sees not_i
16:21 timotimo oh, many more of those are actually isnull_s
16:21 timotimo more than isnull itself
16:21 jnthn isnull_s and isnull should compile into the same assembly, surely.
16:21 jnthn oh, no, wait
16:22 jnthn They won't because of the VMNull thing.
16:23 timotimo at least they are already both implemented :)
16:42 timotimo you don't happen to know of some somewhat low-hanging optimization i could look at next? :)
16:44 timotimo i suppose if i am to implement some feature or ecosystem-related thing instead it'd end up being "gui frontend for the debugger", which will yak-shave-reduce to "improve GTK::Simple"
16:44 jnthn How's GTK::Simple doing these days?
16:44 timotimo it displays windows, buttons and labels :P
16:45 timotimo it's kinda hard to tell what's still in scope for GTK::Simple and what isn't
16:45 timotimo and how to move things into separate modules while still maintaining compatibility between the things
16:45 timotimo though since we got NativeCast now, ther's no need to have the same class repr the OpaquePointer were playing with
16:47 jnthn It's not LHF, but I have pondered that CAPHASH may want to cease to exist, and we build Match objects more directly out of $!cstack
16:47 jnthn We'd have to implement building Rakudo's ones too
16:48 jnthn So we get less code re-use...but Match object construction is so hot path that building an intermediate data structure every time is kinda costly.
16:49 jnthn Especially given the intermediate data structure is a hash
16:49 jnthn And hash lookups are one of the things we spend most time doing in CORE.setting compilation.
16:49 jnthn I'm not sure it's LHF, but it is at least "just" NQP and Perl 6 code to write :)
16:52 timotimo oof
16:58 timotimo commute &
16:58 timotimo i'll have a look later :)
17:21 ventica joined #moarvm
17:53 cognome joined #moarvm
17:54 timotimo now i've finished the commute and also some grocerisation
17:59 FROGGS jnthn: that CAPHASH removal sounds like awesome
18:05 japhb jnthn: still backlogging, so this may be resolved, but: The "superstitious parens in for loops" in the benchmarks were for three reasons: 1. Because it helps align with perl5, so I can visually see if I've typoed, 2. Because Perl 5 converts will accidentally do this *all the time*, and 3. Because it really shouldn't matter for performance, so if it does, I call that a bug worth catching.  :-)
18:57 nwc10 m: say 6.1774e+01/6.243e+01; say 6.1774e+01/6.597e+01
18:57 camelia rakudo-moar e036e2: OUTPUT«0.989492231299055␤0.936395331211156␤»
18:58 nwc10 so 1% less than last time, and 6.4% less than yesterday morning
18:58 timotimo what happened since last time
18:58 timotimo ?
18:58 nwc10 I don't know.
18:59 nwc10 once upon a time it was "this week". Right now, it seems to be "this hour"
18:59 nwc10 I guess, really, it's "this morning"
19:01 jnthn Coulda been the labels improvemnets
19:01 jnthn Also timotimo++'s patches
19:02 nwc10 does perl6bench like it?
19:02 timotimo oh :3
19:02 jnthn perl6bench doesn't measure compilation time really
19:03 nwc10 these are mostly compilation time fixies?
19:03 nwc10 er, fixes
19:03 nwc10 they don't help more general code paths?
19:04 jnthn My labels thing was
19:04 jnthn timotimo's are more genearl.
19:14 japhb jnthn: perl6-bench does measure compile time for each test, it just subtracts it from the run time of the test ... or did you mean, the compile time for the compiler itself?
19:14 timotimo the latter, i believe
19:15 jnthn No, I meant for the test...OK, I guess what I shoulda said is "doesn't appear in the graphs" - which is the right thing in many senses. :)
19:15 jnthn Though it could be itneresting to know about compile itme improvements over time :)
19:16 japhb jnthn: Just turn off the compile time ignoring
19:17 japhb --/ignore-compile and/or --/ignore-setup
19:17 japhb (Because bench defaults both to on.)
19:17 japhb Mind you, you'll then see the combination of compile and run time, so hmmm.
19:18 japhb Maybe I need a plot mode where it just shows the compile time for each test.
19:19 japhb (Since the compile time is in the timings file, it's just normally subtracted out at analysis time)
19:23 cognome joined #moarvm
19:53 ventica joined #moarvm
20:35 ventica joined #moarvm
20:59 ilbot3 joined #moarvm
20:59 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
22:36 jnthn *sigh* That took some doing...
22:37 dalek MoarVM: 3e8e534 | jnthn++ | src/6model/s (3 files):
22:37 dalek MoarVM: Prepare for lazy deserialization.
22:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3e8e534236
22:37 dalek MoarVM: 9539fcd | jnthn++ | src/6model/ (4 files):
22:37 dalek MoarVM: Start storing serialization reader in the SCRef.
22:37 dalek MoarVM:
22:37 dalek MoarVM: We'll need to keep it around for deserialization. Move cleanup to the
22:37 dalek MoarVM: SCRef GC.
22:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9539fcd090
22:37 dalek MoarVM: 0c30c2b | jnthn++ | src/ (3 files):
22:37 dalek MoarVM: Make "allocate in gen2" tracking reentrant.
22:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0c30c2b292
22:37 dalek MoarVM: 7a722dc | jnthn++ | src/ (4 files):
22:37 dalek MoarVM: Switch deserialization to take place lazily.
22:37 dalek MoarVM:
22:37 dalek MoarVM: Now things are only deserialized on "first touch". Unfortunately, we
22:37 dalek MoarVM: are very touchy, as little is set up to take advantage of this. Even
22:37 dalek MoarVM: before looking into using it better, however, it takes another 2.5MB
22:37 dalek MoarVM: off the base memory of Rakudo with CORE.setting loaded.
22:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7a722dc401
22:59 timotimo nice :)
23:10 dalek MoarVM: 58fdbb2 | jnthn++ | src/ (4 files):
23:10 dalek MoarVM: A little STable cleanup.
23:10 dalek MoarVM:
23:10 dalek MoarVM: Kill two fields we don't, and won't, use. Also re-order a bit to try
23:10 dalek MoarVM: and get better cache access patterns.
23:10 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/58fdbb29a7

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