Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-11

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

All times shown according to UTC.

Time Nick Message
00:22 zakharyas joined #moarvm
00:51 timotimo weird.
00:51 timotimo these blocks that the optimizer creates
00:51 timotimo they have loc_0_str, loc_1_obj and loc_2_obj
00:51 timotimo but their body is just:
00:51 timotimo 00002   const_s      loc_0_str, 'INTERNAL ERROR: Execution of block eliminated by optimizer'
00:51 timotimo 00003   die          loc_1_obj, loc_0_str
00:51 timotimo 00004   return_o     loc_1_obj
00:51 timotimo so where does that third register get allocated?
00:54 timotimo https://gist.github.com/timo/db2770106e0dc58748ab  - fun!
00:55 jnap joined #moarvm
01:28 FROGGS_ joined #moarvm
04:12 lue joined #moarvm
04:34 diakopter timotimo: heh.
04:41 brrt joined #moarvm
04:50 zakharyas joined #moarvm
05:54 nwc10 jnthn: pass. Except t/spec/S32-list/uniq.t failed during the spectest. Can't reproduce
06:12 brrt joined #moarvm
06:15 brrt jnthn: i have  a reasonable theory on why the thing crashes, but i'm not sure
06:15 brrt the exception itself seems to be normal
06:16 brrt as in, it's also thrown from the exact same spot in interpreted code
06:45 nwc10 m: say  5.588e+01/5.6892e+01; say 5.588e+01/6.597e+01
06:45 camelia rakudo-moar 40748b: OUTPUT«0.982211910286156␤0.847051690162195␤»
06:53 brrt uhm, when is a spesh frame actually compiled
06:55 * brrt has a sneaking suspicion
06:59 brrt ok, much amaze, i've fixed it
07:06 dalek MoarVM/moar-jit: 76f76b8 | (Bart Wiegmans)++ | src/ (5 files):
07:06 dalek MoarVM/moar-jit: Fix bug in handlers
07:06 dalek MoarVM/moar-jit:
07:06 dalek MoarVM/moar-jit: When a frame is JITted, the exception handling logic must
07:06 dalek MoarVM/moar-jit: search for JIT handlers rather than regular handlers because
07:06 dalek MoarVM/moar-jit: the interpreter bytecode offset. Except that this is again
07:06 dalek MoarVM/moar-jit: meaningless if that code has never ran, such as when the frame
07:06 dalek MoarVM/moar-jit: was compiled but has not been entered yet. So we must check
07:06 dalek MoarVM/moar-jit: for that, as well.
07:06 dalek MoarVM/moar-jit:
07:06 dalek MoarVM/moar-jit: I've also added code to automatically load the right label
07:06 dalek MoarVM/moar-jit: to the interpreter whenever we cross a frame handler barrier,
07:06 dalek MoarVM/moar-jit: so that adhoc exceptions should Just Work.
07:06 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/76f76b8ce5
07:19 dalek MoarVM/moar-jit: e5dd370 | (Bart Wiegmans)++ | src/jit/graph.c:
07:19 dalek MoarVM/moar-jit: Add ne_s by appending not_i
07:19 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e5dd3702d3
07:25 odc joined #moarvm
07:50 brrt joined #moarvm
08:09 brrt fwiw, i think we can now delete the output files from dynasm from the repository?
08:09 brrt they no longer serve a purpose now i can build them pretty much always
08:12 FROGGS_ cool :o)
08:12 dalek MoarVM/moar-jit: 3e7eda7 | (Bart Wiegmans)++ | src/jit/ (4 files):
08:12 dalek MoarVM/moar-jit: Add binary operators and integer negation
08:12 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3e7eda7a23
08:15 dalek MoarVM/moar-jit: 71e35f3 | (Bart Wiegmans)++ | / (3 files):
08:15 dalek MoarVM/moar-jit: Remove DynASM output files
08:15 dalek MoarVM/moar-jit:
08:15 dalek MoarVM/moar-jit: These are no longer necessary because we now ship
08:15 dalek MoarVM/moar-jit: minilua and can always build them again.
08:15 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/71e35f336a
08:19 FROGGS brrt: hmmm, would it make sense to generate these files into src/gen/ ?
08:20 nwc10 brrt: for generated files, either build them *every* time as part of the build process
08:20 nwc10 or have a well defined way to rebuild them
08:20 nwc10 and preferably a test that they are current
08:21 nwc10 if you don't enforce policy one way or the other, it inevtiably ends up with them being stale
08:21 nwc10 and then bugs
08:22 nwc10 brrt: are you able to make it to the hackathon in October?
08:22 nwc10 http://act.useperl.at/apw2014/talk/5565 http://act.useperl.at/apw2014/talk/5566
08:27 FROGGS I hope Larry can come :/
08:27 FROGGS but I guess that this is slightly unrealistic
08:29 brrt FROGGS: i'm okay with moving them into src/gen
08:29 brrt nwc10: they're... supposed to be kept up-to-date using make
08:29 brrt much like .o files
08:30 brrt that usually works for me; more importantly i've added a line to .gitignore so they'll be never be included in the repo again
08:30 brrt if they go stale it'd be weird
08:30 brrt also, wrt, to hackaton
08:30 brrt let me see :-)
08:30 FROGGS ( src/gen/ is already in .gitignore of course )
08:31 brrt this in austria?
08:31 brrt i'm perfectly ok with moving them to gen
08:31 brrt i think make clean will also remove them then?
08:31 FROGGS hmmm
08:31 FROGGS brrt: yes, Salzburg
08:33 FROGGS brrt: only distclean would do that if you list your files
08:33 brrt uh, i can already tell you that i'd like too, but i have no idea right now if i'll be studying, if i'll have work, if i'll have any money :-)
08:33 nwc10 I forget the magic not to get logged, so I'm not going to answer that
08:33 brrt my next month's planning is a bit vague
08:37 nwc10 brrt: make, good
08:37 nwc10 brrt: Salzburg is in Austria. Just
08:37 nwc10 it's about 4km from the German border. We can tip you over into Germany if you get ill, if that makes travel insurance easier
08:38 brrt travel insurance? what is that thing i've never heard of? :-p
08:39 FROGGS *g*
08:39 nwc10 it's probably not a problem, if you don't mind the off chance of being stuck in a hospital in Austria
08:39 brrt but yeah, that would be quite a bit cheaper, there are these very cheap cross-qountry germany tickets
08:39 jnthn morning o/
08:39 brrt morning
08:40 nwc10 jnthn: well spotted :-)
08:40 FROGGS "morning" jnthn :o)
08:40 jnthn brrt++ # fixing the JIT
08:40 brrt :-)
08:40 * jnthn should build it :)
08:41 FROGGS Stage parse      :  35.065
08:41 FROGGS that's the lowest I've ever seen on my box
08:41 brrt you should
08:41 brrt hmm, i've seen 25s i think, but only with jit disabled
08:43 jnthn hmmmm
08:43 brrt hmm?
08:43 * jnthn tried to merge in master and it's produced a broken build
08:43 brrt uh
08:43 brrt and.. without master?
08:44 jnthn Probably woulda been OK
08:44 jnthn Looks like a mis-merge
08:44 jnthn yeah, fine now
08:45 brrt oh, ok :-)
08:47 FROGGS brrt: I should mention that this was without jit
08:47 FROGGS yesterday with jit I had about 53s
08:47 FROGGS and that's a core i5 laptop
08:48 nwc10 JIT seems to make my setting build a little bit slower
08:50 brrt yeah, mine too
08:50 brrt everybodies
08:50 brrt :-)
08:50 brrt much sad, but i think the only solution is to start profiling
08:52 brrt jnthn: you can push the merged master if it works
08:55 jnthn brrt: Yes, was just checking it did
08:55 jnthn Get through the setting build here.
08:56 FROGGS brrt: just make it not explode... because the chance that the design is off is pretty non existent me thinks
08:57 brrt FROGGS: because of hunger, i'm stupid today. i'll try to not make it explode, but i'm not sure what you mean with the design being off :-)
08:59 FROGGS brrt: I just wanted to say that you should not worry about the slowness right now
08:59 jnthn brrt: One thing to note: I guess we're still generating the specialized bytecode as well as the JITted output?
08:59 brrt oh yes
08:59 FROGGS just carry on
08:59 brrt jnthn: indeed
09:00 jnthn brrt: For frames below the inlining size limit we still want it.
09:00 jnthn For anything larger than that, I think we could drop that step?
09:00 brrt could potentially, yes
09:00 brrt but codegen also fixes up handlers and all the rest
09:01 brrt and deopt indices, and that would have to be moved
09:01 brrt and that is annoying in a way
09:03 jnthn hmmm
09:04 jnthn Except...it's fixing up handlers and deopt indexes relative to specialized bytecode, rather than JITted code...
09:06 brrt true, but for example the jit handlers are just a bunch of labels, and the action to be performed is still in the interprted handler
09:06 brrt is this a hack? yes
09:06 brrt could we fix it? also yes
09:06 brrt could we fix it without duplicating work? hmmm
09:07 brrt but i agree, we should fix it one day or another
09:08 jnthn *nod*
09:08 jnthn Yeah, not suggesting it for now
09:08 jnthn Given that things now work with JIT, and that you still have to --enable-jit anyway, would now be a sane time for a merge to master?
09:08 brrt ehm, yes, i think so
09:08 FROGGS +1 +1 +1
09:09 brrt i suppose i'd like to remove the test files, i have a local repository for them anyway
09:09 brrt but otherwise
09:09 dalek MoarVM/moar-jit: ec09497 | jnthn++ | src/core/ (5 files):
09:09 dalek MoarVM/moar-jit: Fix --dump when there are state variables.
09:09 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ec094974ef
09:09 dalek MoarVM/moar-jit: d0c50da | jnthn++ | src/6model/serialization. (2 files):
09:09 dalek MoarVM/moar-jit: Provide a way to force-deserialize an STable.
09:09 dalek MoarVM/moar-jit:
09:09 dalek MoarVM/moar-jit: Sometimes, we get ordering dependencies with deserializing REPR data.
09:09 dalek MoarVM/moar-jit: Now that we deserialize lazily, this can get us into trouble. Enable
09:09 dalek MoarVM/moar-jit: fixing this by providing a mechanism for enforcing the dependency.
09:09 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/d0c50dafa2
09:09 dalek MoarVM/moar-jit: 693a628 | jnthn++ | src/6model/reprs/MVMArray.c:
09:09 dalek MoarVM/moar-jit: VMArray types depend on their element type.
09:09 jnthn That was the (fixed) merge
09:09 jnthn (Of mater into moar-jit)
09:09 jnthn uh, master
09:13 brrt dura mater
09:13 brrt ok, i'll remove the test files, and then i think we can merge? or is there something you want me to clean up first?
09:14 brrt (here 'you' was plural, btw :-))
09:14 jnthn No, I'm happy
09:14 FROGGS then we all are happy :o)
09:15 dalek MoarVM/moar-jit: 72f1c02 | (Bart Wiegmans)++ | / (3 files):
09:15 dalek MoarVM/moar-jit: Remove test files, they don't belong here
09:15 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/72f1c02a75
09:16 FROGGS brrt: if you would convert your test files so that they output TAP you could add them to nqp/t/jit
09:16 brrt yes, i'll do that next
09:16 FROGGS though you probably cannot test that something really git JITted
09:16 brrt hmm. no
09:17 brrt except if you'd have reified access to the frame, the spesh candidate, and the jitcode
09:18 dalek MoarVM/moar-jit: 79d3e89 | jnthn++ | src/core/op (2 files):
09:18 dalek MoarVM/moar-jit: Mark can and can_s as invokish.
09:18 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/79d3e89660
09:18 jnthn uh, I probably should wait for the merge, shouldn't I :)
09:19 brrt well, yeah, but it'll be easy enough to merge that back too
09:19 nwc10 cation, these goalposts are moving.
09:19 nwc10 cation, these goalposts are moving.
09:19 jnthn :)
09:19 jnthn cation, spelling hard :P
09:19 nwc10 aye. :-)
09:19 dalek Heuristic branch merge: pushed 238 commits to MoarVM by bdw
09:20 jnthn 238 :D
09:20 brrt muhahaha!
09:20 brrt your project has been irrevocably changed
09:20 jnthn brrt++ \o/
09:20 brrt feel the wrath!
09:21 jnthn ah, my commit did get lost :)
09:21 brrt yes, hadn't merged that in yet
09:21 brrt will do just now
09:22 jnthn OK
09:22 jnthn Or I can rescue it, but if you're doing it anyway... :)
09:22 dalek MoarVM: 79d3e89 | jnthn++ | src/core/op (2 files):
09:22 dalek MoarVM: Mark can and can_s as invokish.
09:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/79d3e89660
09:22 jnthn \o/
09:25 brrt i'm wondering what will blow up because of can_s and can, but we'll see
09:27 jnthn BAIL: op <const_i64_32>
09:27 jnthn srsly?
09:28 brrt lol
09:28 jnthn hah, emit_x64.dasc knows it, but graph.c doesn't :)
09:29 brrt look unlikely something will blow up because of it :-)
09:32 jnthn hopefully
09:32 jnthn I may have something nice to show you in a few minutes :)
09:32 brrt nice
09:32 brrt but... i'll be off for lunch right now :-)
09:33 brrt bye!
09:39 jnthn yay, my changes don't break nqp and rakudo builds
09:41 dalek MoarVM: e26355e | jnthn++ | src/jit/graph.c:
09:41 dalek MoarVM: JIT can and can_s.
09:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e26355ee31
09:41 dalek MoarVM: ca6ee1a | jnthn++ | src/jit/graph.c:
09:41 dalek MoarVM: Add const_i64_32 to list of ops we can JIT.
09:41 dalek MoarVM:
09:41 dalek MoarVM: The emitter already knew how, just not the JIT graph builder.
09:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ca6ee1a39d
09:58 jnthn Without JIT:
09:59 jnthn timecmd perl6-m -e "my int $i = 0; while ($i = $i + 1) <= 100000000 { }; 'ok'.say"
09:59 jnthn ok
09:59 jnthn With JIT:
09:59 jnthn command took 0:0:2.35 (2.35s total)
09:59 jnthn C:\consulting\rakudo>timecmd perl6-m -e "my int $i = 0; while ($i = $i + 1) <= 100000000 { }; 'ok'.say"
09:59 jnthn ok
09:59 jnthn command took 0:0:0.74 (0.74s total)
09:59 timotimo that's cute :)
09:59 timotimo we don't have _I ops in the jit yet, do we?
09:59 jnthn No
10:00 timotimo https://gist.github.com/timo/db2770106e0dc58748ab - did you see this? %)
10:00 jnthn Just gonna check my patch for hllize won't blow stuff up
10:02 jnthn timotimo: Apart from the set that could probably go away, looks like it's making some job of register re-use :)
10:03 brrt joined #moarvm
10:04 timotimo at least that, yeah
10:04 timotimo but spesh will end up with three set operations in a row from code like this %)
10:05 dalek MoarVM: 7671558 | jnthn++ | src/ (3 files):
10:05 dalek MoarVM: JIT hllize.
10:05 dalek MoarVM:
10:05 dalek MoarVM: Also mark hllizefor as invokish, for future JITting.
10:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7671558051
10:05 jnthn Yeah, I know. The set elimination problem needs tackling at some point :)
10:06 timotimo maybe it'll fall out naturally from register allocation on the jit side of things?
10:06 timotimo but not necessarily on spesh ...
10:06 jnthn I think we probably can deal with it more naturally in spesh
10:07 timotimo mhm
10:22 timotimo jnthn: any idea why the "block eliminated by optimizer" frames end up with an unused register?
10:23 jnthn 'fraid not
10:24 brrt timotimo: it actually something that has to be done at all levels, it seems
10:25 timotimo what, superfluous set removal?
10:26 timotimo jnthn: perhaps the mast compiler allocates a register for the "return value" of the raw block and expects something inside to make use of it, but nothing does?
10:26 brrt yes, set removal
10:27 brrt basically, if you do it in spesh, you'll have to make a map for when deopting, right?
10:27 jnthn timotimo: Perhaps
10:27 jnthn brrt: Not really. When I looked into patch it, I was looking for a set with a single usage
10:27 brrt but you'll also have to make the same in the JIT if you're trying to eliminate stores and fetches
10:27 brrt ah, ok
10:27 jnthn brrt: Using a register the other side of a deopt boundary gives it a bonus usage
10:28 timotimo here i see a line that looks at the .blocktype and if it's "raw", it'll create an InstructionList with MAST::VOID, $MVM_reg_void
10:28 jnthn So it never gets eliminated
10:30 timotimo jnthn: how impossible would it be to have something like "hot code swapping" supported by moarvm semi-directly?
10:30 timotimo that's something that's pretty cool in the java world - i guess CLR has something similar as well?
10:37 brrt hot code swapping seems a bit similar to on-stack-replacement? and we do that
10:39 timotimo except the java people replace methods of classes in their IDE and have the change reflected directly in the running VM
10:39 timotimo that's a bit more "advanced" because you're not working from having a quasi-direct mapping between the bytecodes
10:41 jnthn Aye. It'd be nice to support edit-and-continue debugging some day
10:41 brrt ooh in that sense
10:41 brrt well, you'll have to have IDE support too
10:42 nwc10 jnthn: PASS (except for sin)
10:43 brrt awesum
10:43 * brrt is blogging away, btw
10:44 jnthn Cool
10:44 * jnthn is going to nom something, then look at async things a bit
10:47 timotimo nice :)
11:26 cognome joined #moarvm
11:30 nwc10 m: say  5.6177e+01/5.588e+01; say 5.6177e+01/6.597e+01
11:30 camelia rakudo-moar 40748b: OUTPUT«1.00531496062992␤0.851553736546915␤»
11:31 nwc10 JIT setting is slightly slower than JIT-free setting
11:34 timotimo glad to hear it's only a slight change
11:34 timotimo ... what exactly are these two numbers?
11:39 nwc10 first pair are "this run divided by previous run"
11:39 timotimo ah
11:39 nwc10 second pair are "this run devided by a run a couple of weeks ago when I started counting
11:39 nwc10 roughly http://xkcd.com/363/
11:43 lizmat so, how can I tell whether I have a jit enabled moar ?
11:44 lizmat $ install/bin/moar --version
11:44 lizmat This is MoarVM version 2014.07-358-g7671558
11:45 jnthn lizmat: MVM_JIT_LOG=jit_log perl6-m -e "say 42" # and see if jit_log is created and non-empty
11:46 lizmat jit_log created but empty
11:46 jnthn empty? Hm
11:46 jnthn That'd probably mean you didn't get one
11:46 jnthn We may want to include it in --version
11:47 lizmat that explains the lack of difference in spectest timing
11:47 lizmat perl Configure.pl --gen-moar=master --moar-option=--enable-jit  --gen-nqp --backends=moar
11:47 lizmat is what I did after rm -rf install
11:47 carlin moar-option in rakudo's configure doesn't work
11:48 carlin https://github.com/rakudo/rakudo/pull/300
11:48 lizmat --moar-options is not recognize, --moar-option is
11:50 lizmat merged, and rebuilding
12:07 timotimo the moar jit will likely increase the spec test time
12:08 jnthn Here it comes out almost even.
12:23 timotimo that is very good
12:23 timotimo compared to spesh only, yes?
12:23 jnthn Yes
12:23 timotimo if we can get the time we spend jitting back that is a good start
12:24 timotimo would be terrible if we were jvm-slow until the jit kicks in
12:24 timotimo I prefer the trade - off this way
12:31 jnap joined #moarvm
13:04 cognome joined #moarvm
13:52 dalek MoarVM: a811334 | jnthn++ | / (6 files):
13:52 dalek MoarVM: Initial work on async process spawning.
13:52 dalek MoarVM:
13:52 dalek MoarVM: With this, it actually does spawn a process, though the result or any
13:52 dalek MoarVM: errors are not yet handed back, and there's no I/O with the process
13:52 dalek MoarVM: yet.
13:52 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a811334ea5
13:52 jnthn bbiab
14:17 brrt joined #moarvm
14:22 * [Coke] also has no jit on 64bit mac
14:22 [Coke] is this a moar config issue?
14:25 timotimo it mostly means we didn't implement(/activate?) code-gen for mac yet
14:26 carlin does it not Just Work(tm) if the Configure script is edited?
14:26 [Coke] ok. let me know if we need testers or some config stuff going on the mac.
14:26 timotimo carlin: i have no intimate knowledge of dynasm
14:28 carlin the configure script checks for darwin-2level but the OS X's where it's not working have an archname of something like darwin-thread-multi-2level
14:32 carlin on OpenBSD I just edited Configure and it there's stuff going into the jit_log so it seems to be doing something... not sure what that something is though
14:36 brrt \o
14:36 brrt no explicit knowledge of dynasm is necessary, fortunately
14:36 brrt basically i hardcoded the check for suppoted platforms like an evil man
14:36 brrt i have no idea how to check for x64 support otherwise
14:39 * jnthn back
14:42 ggoebel1111114 joined #moarvm
15:11 brrt \o jnthn
15:20 dalek MoarVM: 7aed82d | jnthn++ | src/ (3 files):
15:20 dalek MoarVM: Schedule async proc exit and error callbacks.
15:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7aed82dae9
15:21 jnthn Now it's vaguely useful...
16:09 brrt joined #moarvm
16:16 dalek MoarVM: e034339 | Carlin++ | Configure.pl:
16:16 dalek MoarVM: Some platforms use amd64 to refer to x86_64
16:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e03433939d
16:16 dalek MoarVM: a213518 | lizmat++ | Configure.pl:
16:16 dalek MoarVM: Merge pull request #124 from carbin/bsd-users-are-people-too
16:16 dalek MoarVM:
16:16 dalek MoarVM: Some platforms use amd64 to refer to x86_64
16:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a213518c03
16:16 lizmat odd that I'm called lizmat here, and on rakudo Elizabeth Mattijsen ?
16:17 jnthn Some channels just don't give you the respect you deserve... :)
16:17 jnthn Really though, no idea why :)
16:18 japhb lizmat: There's a translation table somewhere.  Trying to remember where ... moritz++ might remember.
16:18 jnthn Or is it that this was a pull request merged at the web UI, rather than a push from yourlocal machine?
16:18 lizmat web UI
16:18 japhb bus stop &
16:18 lizmat ah, that could be it
16:19 lizmat hmmm.  after carlin's patch, I still get:
16:19 lizmat Configuring native build environment ................... JIT isn't supported on darwin-thread-multi-2level yet.
16:21 jnthn Did carlin's patch make it match that string?
16:21 * lizmat looks
16:21 brrt nah, doesn't
16:22 timotimo the "-thread" piece is missing from that regex
16:22 timotimo but "darwin-2level" is
16:22 lizmat $ perl -V | grep archname
16:22 lizmat osname=darwin, osvers=13.1.0, archname=darwin-thread-multi-2level
16:22 timotimo er, and the -multi is also missing
16:22 timotimo no clue what it means
16:22 lizmat maybe I got a wonky perl5
16:22 lizmat 5.10.1
16:22 lizmat hmmm...
16:23 lee_ i believe that means you have a perl with support for threads
16:23 lizmat indeed
16:24 lee_ https://gist.github.com/leedo/86975efa5f47b7e8344d
16:25 dalek MoarVM: dbc6cac | (Bart Wiegmans)++ | Configure.pl:
16:25 dalek MoarVM: Another attempt at Mac OS X support
16:25 dalek MoarVM:
16:25 dalek MoarVM: I'd say there has to be a better way to detect
16:25 dalek MoarVM: x64 support, but I don't know it yet.
16:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dbc6cac19c
16:29 lizmat pulled and compiling
16:32 brrt let's hope
16:35 * brrt wants this: http://imgs.xkcd.com/comics/universal_converter_box.png
16:37 carlin Sorry, my patch was just to make *BSDs work, not Mac, but it looks like brrt++ got that covered
16:37 dalek MoarVM: 6eea4f8 | jnthn++ | src/ (3 files):
16:37 dalek MoarVM: Preparation for async read from stdout/stderr.
16:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6eea4f8a4c
16:37 jnthn Uh, for async processes, that is
16:38 timotimo async read from async processes stdout/stderr? :)
16:39 jnthn Yes
16:39 jnthn my $proc = Proc::Async.new(path => 'ping', args => ['www.jnthn.net']);
16:39 jnthn $proc.stdout_chars.tap(&print);
16:39 jnthn say await $proc.start;
16:39 jnthn That's the thingy I'm playing with getting working :)
16:40 lizmat Success!: $ ls -ls jit_log
16:40 lizmat 760 -rw-r--r--  1 liz  501  385987 Aug 11 18:40 jit_log
16:40 jnthn So JIT!
16:40 jnthn brrt++
16:41 lizmat indeed, brrt++
16:41 brrt yay
17:01 lizmat would something like 'my $a = 1000000; my int $b; for ^$a { $b = $b + 1 }' be jittable?
17:02 jnthn Potentially
17:02 jnthn Well
17:02 jnthn That'll probably hit MapIter
17:02 lizmat I'm not seeing it  :-)
17:02 jnthn And I've no idea how well that works out
17:03 jnthn for ^1000000 { ... } is the form that'll get turned into a while loop
17:06 lizmat $ time MVM_SPESH_DISABLE=1 perl6 -e 'my $a = 10000000; my int $b = 0; while $a-- { $b = $b + 1 }'
17:06 lizmat real0m5.313s
17:07 lizmat $ time perl6 -e 'my $a = 10000000; my int $b = 0; while $a-- { $b = $b + 1 }'
17:07 lizmat real0m2.526s
17:07 lizmat the for ^x version is *much* slower
17:07 lizmat $ time perl6 -e 'my int $b = 0; for ^10000000 { $b = $b + 1 }'
17:07 lizmat real0m3.667s
17:08 lizmat $ time MVM_SPESH_DISABLE=1 perl6 -e 'my int $b = 0; for ^10000000 { $b = $b + 1 }'
17:08 lizmat real0m3.441s
17:08 lizmat so, even though apparently for ^x is turned into a while, it's slower than a written out while
17:09 jnthn It can't inline that block at present.
17:09 jnthn Whereas in the while loop the static optimizer does away with it.
17:10 lizmat so not jitting at all there yet ?
17:10 jnthn Well, we probably are jitting at least the inner block
17:10 cognome_ joined #moarvm
17:11 jnthn The trouble is, it's swamped by the invocation.
17:11 jnthn Which spesh isn't smart enough to know it can remove yet
17:13 jnthn And it's not only that it can't inline, it's that it can't even eliminate the guards on the inner thing yet
17:18 lizmat well... it's a start....
17:19 lizmat :-)
17:19 lizmat I find the while $a-- difference quite impressive
17:21 jnthn lizmat: To see another notable difference, maybe try: my int $i = 0; while ($i = $i + 1) <= 100000000 { }
17:21 dalek MoarVM: 29d2e7b | jnthn++ | src/ (3 files):
17:21 dalek MoarVM: Async process stdout/stderr async reads.
17:21 dalek MoarVM:
17:21 dalek MoarVM: This means tapping either (or both) output stream will now work out.
17:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/29d2e7b355
17:22 lizmat $ time perl -e 'my $i = 0; while (($i = $i + 1) <= 100000000) { }'
17:22 lizmat real0m4.728s
17:23 lizmat note, that's Perl *5*
17:23 lizmat $ time perl6 -e 'my int $i = 0; while ($i = $i + 1) <= 100000000 { }'
17:23 lizmat real0m0.658s
17:24 lizmat this particular piece of code is ~ 7 times as fast in Perl 6 than it is in Perl 5
17:24 lizmat $ time MVM_SPESH_DISABLE=1 perl6 -e 'my int $i = 0; while ($i = $i + 1) <= 100000000 { }'
17:24 lizmat real0m2.819s
17:24 lizmat even without JIT, perl 6 is faster!
17:25 * lizmat likes where this is going :-)
17:25 jnthn Still plenty of hard work yet :)
17:25 jnthn But yes, nice to see such numbers :)
17:26 lizmat should we put in spectests to make sure the optimization kicks in ?
17:26 lizmat like the above code ?
17:27 jnthn Feels more like the kind of thing an automated perl6-bench run could do for us...
17:29 lizmat but that wouldn't target any specific optimizations. would it?
17:30 jnthn The above example code is straight out of perl6-bench :)
17:33 lizmat ah, ok  :-)
17:40 jnthn Hm, I should probably not forget to have dinner :)
17:40 jnthn bbiab
17:40 japhb lizmat: I've been thinking for a while that we really want a couple more classes of benchmarks in perl6-bench -- and one of those is regression tests for optimizations.  Now that we have history view for each test (as well as the summary), we can see when performance gets suddenly worse, and we should have a raft of benchmarks that check for specific optimizations we want to be sure to keep.
17:42 japhb jnthn: does your async proc code support *synchronous* writes to the spawned process, or does it not support writes to the subprocess at all?
17:42 japhb jnthn: Also, is/will it be possible to communicate on FDs other than 0,1,2?
18:32 pmichaud joined #moarvm
18:33 pmichaud jnthn/masak : where are you staying (hotel) at YAPC::EU ?
18:33 FROGGS it is probably dinner time
18:38 jnthn pmichaud: http://www.hotelexposofia.com/
18:38 jnthn pmichaud: There's a note on the website about getting a conf discount
18:38 jnthn japhb: No writes at all yet; will get to it in the next days.
18:39 jnthn japhb: Just 0/1/2 so far
18:40 jnthn japhb: I guess the API in libuv supports beyond that? If so and you've a use case, could look into that...
18:40 pmichaud jnthn: I hope it's a significant discount... current rates are around 205EUR per night it seems.
18:40 pmichaud That's pretty hefty.
18:41 nwc10 jnthn: much spectest unhappyness. t/spec/S32-list/first-index.rakudo.moar t/spec/S32-list/grep-index.rakudo.moar t/spec/S32-list/first.rakudo.moar t/spec/S32-list/grep.rakudo.moar t/spec/S32-list/last-index.rakudo.moar t/spec/S32-list/uniq.t
18:41 nwc10 in addition to the usual sinners. Sampling them seems to all be "not ok" rather than ASAN explosion
18:42 jnthn lizmat: I guess ^^ is related to what you've been up to?
18:42 nwc10 oh, 2 people are moving goalposts? This is going to get confusing
18:42 jnthn pmichaud: Yeah, I have half that a night and that was 'cus I was too late to get a normal room and ended up with a junior suite...
18:43 pmichaud the yapceu site mentions sending email but doesn't provide an address  :-/
18:46 pmichaud and now I can't reach the hotel web site :-/
18:46 pmichaud I think I'll have to try again later
18:46 jnthn pmichaud: reservations@hotelexposofia.com
18:46 pmichaud jnthn: thanks
18:49 pmichaud email sent
18:49 japhb jnthn: Most of the use cases I've seen recently for additional FDs to children involve various security enhancements (sandboxing I/O, avoiding writing to FS, getting a third write channel (aside from stdin and argv) to the subprocess, etc.)
18:49 pmichaud I have to go do some other tasks for a while... bbl
18:51 jnthn o/
18:57 mj41 joined #moarvm
18:58 timotimo there's also (on linux (only?)) a way to send opened FDs to other processes via a socket
18:59 mj41 brrt++, jnthn++, timotimo++, ... Congratulations guys, you all rock! https://gist.github.com/mj41/cb457de4ae7a53b2ccde
19:00 nwc10 if you mean passing file descriptors over Unix domain sockets - I think it's been around for at least 20 years. It's in first edition Stevens
19:01 timotimo yeah, that :)
19:01 nwc10 mj41: that's not quite a fair comparison. Could you also try
19:01 nwc10 time perl -e 'use integer; my $i = 0; while (($i = $i + 1) <= 100000000) { }'
19:01 nwc10 I have an idea what the result will look like :-)
19:02 timotimo i tried to do it once via socketpair i think
19:02 timotimo but it was kind of not working properly %)
19:04 mj41 nwc10: https://gist.github.com/mj41/cb457de4ae7a53b2ccde
19:04 mj41 also nwc10++
19:05 nwc10 mj41: cool. thanks. which shows that even integer operations aren't much of a win in Perl 5
19:06 diakopter it's type systems all the way downer
19:16 FROGGS[mobile] joined #moarvm
19:25 mj41 lizmat: https://github.com/rakudo/rakudo/commit/e822ccab88da13d7a48ef6c78e9f8d361648b241
19:25 timotimo good day, diakopter! :)
19:25 timotimo how are you?
19:28 mj41 lizmat: thx :-)
19:30 lizmat nwc10: $ time perl -e 'use integer; my $i = 0; while (($i = $i + 1) <= 100000000) { 1 }'
19:30 lizmat real0m5.434s
19:30 lizmat $ time perl -e 'my $i = 0; while (($i = $i + 1) <= 100000000) { 1 }'
19:30 lizmat real0m4.751s
19:31 lizmat looks like use integer only makes things slower?
19:34 rurban joined #moarvm
19:37 timotimo i've just been shown the "red zone" that you can have on x86_64
19:39 lizmat .oO( that's not red lights, is it ? )
19:41 timotimo throughout the nqp compilation process, param_rp_o is the second-most bailing op in the jit with 180 bails
19:41 timotimo paramnamesused gets 481 bails under its belt
19:41 nwc10 lizmat: it was faster for me. but not much
20:03 jnthn Smell of electrical smoke considered ungood... :S
20:04 nwc10 no.
20:04 nwc10 yesterday we managed a bang that took out all the power in the room
20:04 nwc10 dodgy inherited wiring on a freestanding lamp
20:04 jnthn Wow.
20:04 nwc10 well, given how it was done, ultimately it was not surprising that it failed
20:04 jnthn I thought it was the wireless router, but now I ain't so fure...
20:05 jnthn *sure
20:05 nwc10 we were not previously aware
20:05 nwc10 jnthn: at a guess, it's the power supply
20:05 nwc10 I've had a couple fail
20:05 jnthn Not coming from there.
20:05 nwc10 OK. bang goes my theory
20:05 nwc10 [oops :-)]
20:05 jnthn oh, you mean the power supply for the router?
20:05 nwc10 yes.
20:05 jnthn Hmm
20:06 jnthn that'd meaning switching the thing off may not have cut it...
20:06 nwc10 the power brick
20:06 jnthn yeah, I'd better shut stuff down and find it. :/
20:08 FROGGS it is actually hard to locate it when you are not a dog
20:08 FROGGS because that smell will be everywhere very fast
20:11 * lizmat is fetching perl 5.20.0 for benchmarking
20:17 brrt joined #moarvm
20:22 jnap1 joined #moarvm
20:22 lizmat nwc10: with 5.20.0, the "use integer" case is faster, but not much: 3.9 vs 4.4 wallclock
20:23 lizmat versus the perl 6 case (with / without MVM_SPESH_DISABLE): 0.7 vs 2.8
20:23 lizmat so the non optimized Perl 6 case is still faster
20:24 lizmat taking into account that starting perl6 is .3, it sorta becomes .4 vs 2.5, aka 6 times faster
20:24 brrt yay for super simple benchmarks :-D
20:24 lizmat and Perl 6 for that loop (without startup) is looking at 10 times faster  :-)
20:24 brrt (that we can win)
20:25 lizmat lies, damn lies and statistics  :-)
20:27 lizmat fwiw, super simple benchmarks are only the shape of things to come
20:27 brrt fwiw, the red zone is the 128 bytes down from the stack pointer that are 'safe to use'
20:28 jnthn Hmm
20:29 * jnthn thinks he found it
20:29 brrt but only on the posix abi, not on windows
20:29 jnthn 10+ year old power brick for the speakers...
20:31 lizmat *phew*  :-)
20:32 * lizmat fell in love with a small USB powered bluetooth tethered box with built in battery
20:33 lizmat I'm taking it with me whenever I travel: love the sound of it, compared to pad / notebook speakers
20:39 brrt uh, i had one of those things, and sold it because didn't have a bluetooth-capable player :-)
20:40 brrt i use a direct analog headphone-to-stereo-aux cable
20:42 * lizmat uses iPhone or iPad as player  :-)
20:44 brrt well, you have to have one of these then :-)
20:47 [Coke] how can I tell if I have a jit enabled moar? I reupped, and the config output didn't say one way or the other.
20:49 lizmat MVM_JIT_LOG=jit_log perl6 -e "say 42"
20:49 lizmat if the jit_log is not empty, you have JIT
20:50 [Coke] \o/
20:51 [Coke] would it be helpful to have both moar and moar-jit in the daily runs?
20:51 timotimo https://gist.github.com/timo/7204c6cda63e528f1ac1 ← brrt, combined rakudo build jitlog
20:52 brrt such wow
20:52 [Coke] timotimo: presumably, each time you implement one, that changes the list potentially dramatically?
20:52 brrt unless_n, i want to do that one
20:52 [Coke] Unless_n is in that list 2x.
20:58 brrt well, yeah, that's true
20:58 brrt oh ah
20:58 brrt i see what you mean
21:02 brrt hmm MoarVM doesn't quite build on haiku
21:02 cognome joined #moarvm
21:04 jnthn so disappointment
21:04 jnthn insufficiently ported
21:04 jnthn plz fix before fall
21:11 brrt something wrong with probe
21:13 brrt can't really tell why it won't work
21:14 [Coke] . o O (ugh, this failing rakudo-moar make on os x is annoying. :|)
21:26 japhb lizmat: Just have perl6-bench build you all the perl5 versions that you want, and then you can run your tests from those.  I've provisionally declared that perl6-bench tests can require 5.010, but I think it will happily *build* a perl5 from way back.
21:40 timotimo [Coke]: that's the "write error" one?
21:41 timotimo jnthn: is moarvm in a state where we can just ignore argconst_s?
21:42 jnthn No, if you remove it we'll fail
21:43 timotimo but that's what we want to get to with the "named parameters in callsites" thing, aye?
21:46 [Coke] timotimo: yes, that one.
21:46 timotimo >:(
21:51 [Coke] wonder if we can get mdiep to take a look. :)
22:11 jnthn timotimo: Yeah, though it's not a huge priority :)
22:11 jnthn timotimo: It'll make the bytecode a bit smaller
22:16 [Coke] jnthn: I'm adding moar-jit to the daily runs. cool?
22:20 * brrt afk
22:21 brrt left #moarvm
22:25 jnthn [Coke]: Yes, cool :)
22:28 [Coke] lots of failures, btw
22:28 jnthn Oh?
22:29 jnthn Odd. It was as clean as non-jit for me.
22:30 timotimo jnthn: smaller bytecode means less ram usage ... hopefully
22:59 [Coke] jnthn: I'm not running -master -master. Might that matter?
23:02 japhb timotimo: re: your old request for being able to specify particular revisions/branches of nqp/moar when building r-m, is it sufficient if I just provide the ability to specify extra arguments for the configure stage of a build?  It occurs to me that the more generic concept may be slightly wordier but simpler to implement and more useful in the long run (such as by being able to specify a JIT build)
23:09 timotimo japhb: SGTM, though it'd be nice to then have the ability to give that "thing" a particular name, too :)
23:13 jnthn [Coke]: We bumped revisions quite recently; shouldn't.
23:39 japhb timotimo: 'that "thing"'?
23:42 timotimo a given combination of a commit shasum and a bunch of options passed at build-time
23:43 jnthn 'night o/
23:44 TimToady time perl -e 'use integer; my $i = 0; while (($i = $i + 1) <= 100000000) { 1 }'
23:44 TimToady real0m3.647s
23:44 TimToady user0m3.641s
23:44 TimToady sys0m0.002s
23:45 TimToady time perl -e 'use integer; my $i = 0; while (++$i <= 100000000) { 1 }'
23:45 TimToady real0m2.900s
23:45 TimToady user0m2.896s
23:45 TimToady sys0m0.002s
23:45 TimToady just because rakudo can't do ++$i on an int doesn't mean p5 can't :P
23:47 japhb timotimo: Hmmm, good point.
23:48 japhb TimToady: I'm somewhat surprised that the perl5 peephole optimizer doesn't turn the first into the second anyway.
23:49 TimToady the peephole optimizer is not optimized for turning stupid code into smart code
23:49 japhb Fair enough.
23:49 TimToady p5 always has to compile and run, so only had time to turn smart code into smarter code
23:50 japhb What is it optimized for?  I mean, I know it optimizes 'for (1..1000000)' into a simpler loop, rather than generating the list, but I'm not sure where that dividing line was intended to be drawn
23:50 japhb nodnod
23:50 TimToady optimized for things that you couldn't really express
23:50 TimToady though there are a few of the others too
23:50 japhb Does it do $i++ in void context --> ++$i?
23:51 TimToady turns $i++ into ++$i in void context, for instance
23:51 japhb heh
23:51 TimToady yes
23:52 TimToady I think peephole deals with a branch to a branch
23:52 TimToady removes ops that got nulled by some other optimizations too
23:53 TimToady don't remember if that's where it substitutes specialize opcodes for $foo[1] where 1 is a literal...
23:54 TimToady most such optimizations are in the compiler proper, like substituting a join for a bunch of concats
23:54 timotimo brrt, in your blog post it says "seems to take slightly longer while using JIT than while." which should end in "without"
23:55 TimToady but as you can see from the performance graphs, a lot of work went into making sure strings, arrays, and hashes all scaled well
23:57 japhb TimToady: Yeah, which is much of why I was able to use perl5 for so much over the years.  So thanks for that.  :-)
23:57 TimToady p5 also relies pretty heavily on the notion that if you allocated something once, you'll probably do it again
23:59 TimToady so it caches a lot of allocations and conversions for you

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