00:22 zakharyas joined
timotimo weird. 00:51
these blocks that the optimizer creates
they have loc_0_str, loc_1_obj and loc_2_obj
but their body is just:
00002 const_s loc_0_str, 'INTERNAL ERROR: Execution of block eliminated by optimizer'
00003 die loc_1_obj, loc_0_str
00004 return_o loc_1_obj
so where does that third register get allocated?
gist.github.com/timo/db2770106e0dc58748ab - fun! 00:54
00:55 jnap joined 01:28 FROGGS_ joined 04:12 lue joined
diakopter timotimo: heh. 04:34
04:41 brrt joined 04:50 zakharyas joined
nwc10 jnthn: pass. Except t/spec/S32-list/uniq.t failed during the spectest. Can't reproduce 05:54
06:12 brrt joined
brrt jnthn: i have a reasonable theory on why the thing crashes, but i'm not sure 06:15
the exception itself seems to be normal
as in, it's also thrown from the exact same spot in interpreted code 06:16
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␤»
brrt uhm, when is a spesh frame actually compiled 06:53
brrt has a sneaking suspicion 06:55
ok, much amaze, i've fixed it 06:59
dalek arVM/moar-jit: 76f76b8 | (Bart Wiegmans)++ | src/ (5 files):
Fix bug in handlers

When a frame is JITted, the exception handling logic must search for JIT handlers rather than regular handlers because the interpreter bytecode offset. Except that this is again meaningless if that code has never ran, such as when the frame was compiled but has not been entered yet. So we must check for that, as well.
I've also added code to automatically load the right label to the interpreter whenever we cross a frame handler barrier, so that adhoc exceptions should Just Work.
07:06
arVM/moar-jit: e5dd370 | (Bart Wiegmans)++ | src/jit/graph.c:
Add ne_s by appending not_i
07:19
07:25 odc joined 07:50 brrt joined
brrt fwiw, i think we can now delete the output files from dynasm from the repository? 08:09
they no longer serve a purpose now i can build them pretty much always
FROGGS_ cool :o) 08:12
dalek arVM/moar-jit: 3e7eda7 | (Bart Wiegmans)++ | src/jit/ (4 files):
Add binary operators and integer negation
arVM/moar-jit: 71e35f3 | (Bart Wiegmans)++ | / (3 files):
Remove DynASM output files

These are no longer necessary because we now ship minilua and can always build them again.
08:15
FROGGS brrt: hmmm, would it make sense to generate these files into src/gen/ ? 08:19
nwc10 brrt: for generated files, either build them *every* time as part of the build process 08:20
or have a well defined way to rebuild them
and preferably a test that they are current
if you don't enforce policy one way or the other, it inevtiably ends up with them being stale 08:21
and then bugs
brrt: are you able to make it to the hackathon in October? 08:22
act.useperl.at/apw2014/talk/5565 act.useperl.at/apw2014/talk/5566
FROGGS I hope Larry can come :/ 08:27
but I guess that this is slightly unrealistic
brrt FROGGS: i'm okay with moving them into src/gen 08:29
nwc10: they're... supposed to be kept up-to-date using make
much like .o files
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
if they go stale it'd be weird
also, wrt, to hackaton
let me see :-)
FROGGS ( src/gen/ is already in .gitignore of course )
brrt this in austria? 08:31
i'm perfectly ok with moving them to gen
i think make clean will also remove them then?
FROGGS hmmm
brrt: yes, Salzburg
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 :-)
nwc10 I forget the magic not to get logged, so I'm not going to answer that
brrt my next month's planning is a bit vague
nwc10 brrt: make, good 08:37
brrt: Salzburg is in Austria. Just
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
brrt travel insurance? what is that thing i've never heard of? :-p 08:38
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
brrt but yeah, that would be quite a bit cheaper, there are these very cheap cross-qountry germany tickets
jnthn morning o/
brrt morning
nwc10 jnthn: well spotted :-) 08:40
FROGGS "morning" jnthn :o)
jnthn brrt++ # fixing the JIT
brrt :-)
jnthn should build it :)
FROGGS Stage parse : 35.065 08:41
that's the lowest I've ever seen on my box
brrt you should
hmm, i've seen 25s i think, but only with jit disabled
jnthn hmmmm 08:43
brrt hmm?
jnthn tried to merge in master and it's produced a broken build
brrt uh
and.. without master?
jnthn Probably woulda been OK 08:44
Looks like a mis-merge
yeah, fine now
brrt oh, ok :-) 08:45
FROGGS brrt: I should mention that this was without jit 08:47
yesterday with jit I had about 53s
and that's a core i5 laptop
nwc10 JIT seems to make my setting build a little bit slower 08:48
brrt yeah, mine too 08:50
everybodies
:-)
much sad, but i think the only solution is to start profiling
jnthn: you can push the merged master if it works 08:52
jnthn brrt: Yes, was just checking it did 08:55
Get through the setting build here.
FROGGS brrt: just make it not explode... because the chance that the design is off is pretty non existent me thinks 08:56
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:57
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?
brrt oh yes
FROGGS just carry on
brrt jnthn: indeed
jnthn brrt: For frames below the inlining size limit we still want it. 09:00
For anything larger than that, I think we could drop that step?
brrt could potentially, yes
but codegen also fixes up handlers and all the rest
and deopt indices, and that would have to be moved 09:01
and that is annoying in a way
jnthn hmmm 09:03
Except...it's fixing up handlers and deopt indexes relative to specialized bytecode, rather than JITted code... 09:04
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
is this a hack? yes
could we fix it? also yes
could we fix it without duplicating work? hmmm
but i agree, we should fix it one day or another 09:07
jnthn *nod* 09:08
Yeah, not suggesting it for now
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?
brrt ehm, yes, i think so
FROGGS +1 +1 +1
brrt i suppose i'd like to remove the test files, i have a local repository for them anyway 09:09
but otherwise
dalek arVM/moar-jit: ec09497 | jnthn++ | src/core/ (5 files):
Fix --dump when there are state variables.
arVM/moar-jit: d0c50da | jnthn++ | src/6model/serialization. (2 files):
Provide a way to force-deserialize an STable.

Sometimes, we get ordering dependencies with deserializing REPR data. Now that we deserialize lazily, this can get us into trouble. Enable fixing this by providing a mechanism for enforcing the dependency.
arVM/moar-jit: 693a628 | jnthn++ | src/6model/reprs/MVMArray.c:
VMArray types depend on their element type.

Remove test files, they don't belong here
jnthn That was the (fixed) merge
(Of mater into moar-jit)
uh, master
brrt dura mater 09:13
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?
(here 'you' was plural, btw :-)) 09:14
jnthn No, I'm happy
FROGGS then we all are happy :o)
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
FROGGS though you probably cannot test that something really git JITted
brrt hmm. no
except if you'd have reified access to the frame, the spesh candidate, and the jitcode 09:17
dalek arVM/moar-jit: 79d3e89 | jnthn++ | src/core/op (2 files):
Mark can and can_s as invokish.
09:18
jnthn uh, I probably should wait for the merge, shouldn't I :)
brrt well, yeah, but it'll be easy enough to merge that back too 09:19
nwc10 cation, these goalposts are moving.
jnthn :)
cation, spelling hard :P
nwc10 aye. :-)
dalek Heuristic branch merge: pushed 238 commits to MoarVM by bdw
jnthn 238 :D 09:20
brrt muhahaha!
your project has been irrevocably changed
jnthn brrt++ \o/
brrt feel the wrath!
jnthn ah, my commit did get lost :) 09:21
brrt yes, hadn't merged that in yet
will do just now
jnthn OK 09:22
Or I can rescue it, but if you're doing it anyway... :)
dalek arVM: 79d3e89 | jnthn++ | src/core/op (2 files):
Mark can and can_s as invokish.
jnthn \o/
brrt i'm wondering what will blow up because of can_s and can, but we'll see 09:25
jnthn BAIL: op <const_i64_32> 09:27
srsly?
brrt lol 09:28
jnthn hah, emit_x64.dasc knows it, but graph.c doesn't :)
brrt look unlikely something will blow up because of it :-) 09:29
jnthn hopefully 09:32
I may have something nice to show you in a few minutes :)
brrt nice
but... i'll be off for lunch right now :-)
bye! 09:33
jnthn yay, my changes don't break nqp and rakudo builds 09:39
dalek arVM: e26355e | jnthn++ | src/jit/graph.c:
JIT can and can_s.
09:41
arVM: ca6ee1a | jnthn++ | src/jit/graph.c:
Add const_i64_32 to list of ops we can JIT.

The emitter already knew how, just not the JIT graph builder.
jnthn Without JIT: 09:58
timecmd perl6-m -e "my int $i = 0; while ($i = $i + 1) <= 100000000 { }; 'ok'.say" 09:59
ok
With JIT:
command took 0:0:2.35 (2.35s total)
C:\consulting\rakudo>timecmd perl6-m -e "my int $i = 0; while ($i = $i + 1) <= 100000000 { }; 'ok'.say"
ok
command took 0:0:0.74 (0.74s total)
timotimo that's cute :)
we don't have _I ops in the jit yet, do we?
jnthn No
timotimo gist.github.com/timo/db2770106e0dc58748ab - did you see this? %) 10:00
jnthn Just gonna check my patch for hllize won't blow stuff up
timotimo: Apart from the set that could probably go away, looks like it's making some job of register re-use :) 10:02
10:03 brrt joined
timotimo at least that, yeah 10:04
but spesh will end up with three set operations in a row from code like this %)
dalek arVM: 7671558 | jnthn++ | src/ (3 files):
JIT hllize.

Also mark hllizefor as invokish, for future JITting.
10:05
jnthn Yeah, I know. The set elimination problem needs tackling at some point :)
timotimo maybe it'll fall out naturally from register allocation on the jit side of things? 10:06
but not necessarily on spesh ...
jnthn I think we probably can deal with it more naturally in spesh
timotimo mhm 10:07
jnthn: any idea why the "block eliminated by optimizer" frames end up with an unused register? 10:22
jnthn 'fraid not 10:23
brrt timotimo: it actually something that has to be done at all levels, it seems 10:24
timotimo what, superfluous set removal? 10:25
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
basically, if you do it in spesh, you'll have to make a map for when deopting, right? 10:27
jnthn timotimo: Perhaps
brrt: Not really. When I looked into patch it, I was looking for a set with a single usage
brrt but you'll also have to make the same in the JIT if you're trying to eliminate stores and fetches
ah, ok
jnthn brrt: Using a register the other side of a deopt boundary gives it a bonus usage
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
timotimo jnthn: how impossible would it be to have something like "hot code swapping" supported by moarvm semi-directly? 10:30
that's something that's pretty cool in the java world - i guess CLR has something similar as well?
brrt hot code swapping seems a bit similar to on-stack-replacement? and we do that 10:37
timotimo except the java people replace methods of classes in their IDE and have the change reflected directly in the running VM 10:39
that's a bit more "advanced" because you're not working from having a quasi-direct mapping between the bytecodes
jnthn Aye. It'd be nice to support edit-and-continue debugging some day 10:41
brrt ooh in that sense
well, you'll have to have IDE support too
nwc10 jnthn: PASS (except for sin) 10:42
brrt awesum 10:43
brrt is blogging away, btw
jnthn Cool 10:44
jnthn is going to nom something, then look at async things a bit
timotimo nice :) 10:47
11:26 cognome joined
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␤»
nwc10 JIT setting is slightly slower than JIT-free setting 11:31
timotimo glad to hear it's only a slight change 11:34
... what exactly are these two numbers?
nwc10 first pair are "this run divided by previous run" 11:39
timotimo ah
nwc10 second pair are "this run devided by a run a couple of weeks ago when I started counting
roughly xkcd.com/363/
lizmat so, how can I tell whether I have a jit enabled moar ? 11:43
$ install/bin/moar --version 11:44
This is MoarVM version 2014.07-358-g7671558
jnthn lizmat: MVM_JIT_LOG=jit_log perl6-m -e "say 42" # and see if jit_log is created and non-empty 11:45
lizmat jit_log created but empty 11:46
jnthn empty? Hm
That'd probably mean you didn't get one
We may want to include it in --version
lizmat that explains the lack of difference in spectest timing 11:47
perl Configure.pl --gen-moar=master --moar-option=--enable-jit --gen-nqp --backends=moar
is what I did after rm -rf install
carlin moar-option in rakudo's configure doesn't work
github.com/rakudo/rakudo/pull/300 11:48
lizmat --moar-options is not recognize, --moar-option is
merged, and rebuilding 11:50
timotimo the moar jit will likely increase the spec test time 12:07
jnthn Here it comes out almost even. 12:08
timotimo that is very good 12:23
compared to spesh only, yes?
jnthn Yes
timotimo if we can get the time we spend jitting back that is a good start
would be terrible if we were jvm-slow until the jit kicks in 12:24
I prefer the trade - off this way
12:31 jnap joined 13:04 cognome joined
dalek arVM: a811334 | jnthn++ | / (6 files):
Initial work on async process spawning.

With this, it actually does spawn a process, though the result or any errors are not yet handed back, and there's no I/O with the process yet.
13:52
jnthn bbiab
14:17 brrt joined
[Coke] also has no jit on 64bit mac 14:22
is this a moar config issue?
timotimo it mostly means we didn't implement(/activate?) code-gen for mac yet 14:25
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.
timotimo carlin: i have no intimate knowledge of dynasm
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:28
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:32
brrt \o 14:36
no explicit knowledge of dynasm is necessary, fortunately
basically i hardcoded the check for suppoted platforms like an evil man
i have no idea how to check for x64 support otherwise
jnthn back 14:39
14:42 ggoebel1111114 joined
brrt \o jnthn 15:11
dalek arVM: 7aed82d | jnthn++ | src/ (3 files):
Schedule async proc exit and error callbacks.
15:20
jnthn Now it's vaguely useful... 15:21
16:09 brrt joined
dalek arVM: e034339 | Carlin++ | Configure.pl:
Some platforms use amd64 to refer to x86_64
16:16
arVM: a213518 | lizmat++ | Configure.pl:
Merge pull request #124 from carbin/bsd-users-are-people-too

Some platforms use amd64 to refer to x86_64
lizmat odd that I'm called lizmat here, and on rakudo Elizabeth Mattijsen ?
jnthn Some channels just don't give you the respect you deserve... :) 16:17
Really though, no idea why :)
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?
lizmat web UI
japhb bus stop &
lizmat ah, that could be it
hmmm. after carlin's patch, I still get: 16:19
Configuring native build environment ................... JIT isn't supported on darwin-thread-multi-2level yet.
jnthn Did carlin's patch make it match that string? 16:21
lizmat looks
brrt nah, doesn't
timotimo the "-thread" piece is missing from that regex 16:22
but "darwin-2level" is
lizmat $ perl -V | grep archname
osname=darwin, osvers=13.1.0, archname=darwin-thread-multi-2level
timotimo er, and the -multi is also missing
no clue what it means
lizmat maybe I got a wonky perl5
5.10.1
hmmm...
lee_ i believe that means you have a perl with support for threads 16:23
lizmat indeed
lee_ gist.github.com/leedo/86975efa5f47b7e8344d 16:24
dalek arVM: dbc6cac | (Bart Wiegmans)++ | Configure.pl:
Another attempt at Mac OS X support

I'd say there has to be a better way to detect x64 support, but I don't know it yet.
16:25
lizmat pulled and compiling 16:29
brrt let's hope 16:32
brrt wants this: imgs.xkcd.com/comics/universal_converter_box.png 16:35
carlin Sorry, my patch was just to make *BSDs work, not Mac, but it looks like brrt++ got that covered 16:37
dalek arVM: 6eea4f8 | jnthn++ | src/ (3 files):
Preparation for async read from stdout/stderr.
jnthn Uh, for async processes, that is
timotimo async read from async processes stdout/stderr? :) 16:38
jnthn Yes 16:39
my $proc = Proc::Async.new(path => 'ping', args => ['www.jnthn.net']);
$proc.stdout_chars.tap(&print);
say await $proc.start;
That's the thingy I'm playing with getting working :)
lizmat Success!: $ ls -ls jit_log 16:40
760 -rw-r--r-- 1 liz 501 385987 Aug 11 18:40 jit_log
jnthn So JIT!
brrt++
lizmat indeed, brrt++ 16:41
brrt yay
lizmat would something like 'my $a = 1000000; my int $b; for ^$a { $b = $b + 1 }' be jittable? 17:01
jnthn Potentially 17:02
Well
That'll probably hit MapIter
lizmat I'm not seeing it :-)
jnthn And I've no idea how well that works out
for ^1000000 { ... } is the form that'll get turned into a while loop 17:03
lizmat $ time MVM_SPESH_DISABLE=1 perl6 -e 'my $a = 10000000; my int $b = 0; while $a-- { $b = $b + 1 }' 17:06
real0m5.313s
$ time perl6 -e 'my $a = 10000000; my int $b = 0; while $a-- { $b = $b + 1 }' 17:07
real0m2.526s
the for ^x version is *much* slower
$ time perl6 -e 'my int $b = 0; for ^10000000 { $b = $b + 1 }'
real0m3.667s
$ time MVM_SPESH_DISABLE=1 perl6 -e 'my int $b = 0; for ^10000000 { $b = $b + 1 }' 17:08
real0m3.441s
so, even though apparently for ^x is turned into a while, it's slower than a written out while
jnthn It can't inline that block at present. 17:09
Whereas in the while loop the static optimizer does away with it.
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
jnthn The trouble is, it's swamped by the invocation. 17:11
Which spesh isn't smart enough to know it can remove yet
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:13
lizmat well... it's a start.... 17:18
:-) 17:19
I find the while $a-- difference quite impressive
jnthn lizmat: To see another notable difference, maybe try: my int $i = 0; while ($i = $i + 1) <= 100000000 { } 17:21
dalek arVM: 29d2e7b | jnthn++ | src/ (3 files):
Async process stdout/stderr async reads.

This means tapping either (or both) output stream will now work out.
lizmat $ time perl -e 'my $i = 0; while (($i = $i + 1) <= 100000000) { }' 17:22
real0m4.728s
note, that's Perl *5* 17:23
$ time perl6 -e 'my int $i = 0; while ($i = $i + 1) <= 100000000 { }'
real0m0.658s
this particular piece of code is ~ 7 times as fast in Perl 6 than it is in Perl 5 17:24
$ time MVM_SPESH_DISABLE=1 perl6 -e 'my int $i = 0; while ($i = $i + 1) <= 100000000 { }'
real0m2.819s
even without JIT, perl 6 is faster!
lizmat likes where this is going :-) 17:25
jnthn Still plenty of hard work yet :)
But yes, nice to see such numbers :)
lizmat should we put in spectests to make sure the optimization kicks in ? 17:26
like the above code ?
jnthn Feels more like the kind of thing an automated perl6-bench run could do for us... 17:27
lizmat but that wouldn't target any specific optimizations. would it? 17:29
jnthn The above example code is straight out of perl6-bench :) 17:30
lizmat ah, ok :-) 17:33
jnthn Hm, I should probably not forget to have dinner :) 17:40
bbiab
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.
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
jnthn: Also, is/will it be possible to communicate on FDs other than 0,1,2?
18:32 pmichaud joined
pmichaud jnthn/masak : where are you staying (hotel) at YAPC::EU ? 18:33
FROGGS it is probably dinner time
jnthn pmichaud: www.hotelexposofia.com/ 18:38
pmichaud: There's a note on the website about getting a conf discount
japhb: No writes at all yet; will get to it in the next days.
japhb: Just 0/1/2 so far 18:39
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.
That's pretty hefty.
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
in addition to the usual sinners. Sampling them seems to all be "not ok" rather than ASAN explosion
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
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...
pmichaud the yapceu site mentions sending email but doesn't provide an address :-/ 18:43