Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-09-10

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

All times shown according to UTC.

Time Nick Message
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:26 tokuhiro_ joined #moarvm
03:27 tokuhiro_ joined #moarvm
03:39 tokuhiro_ joined #moarvm
07:03 Ven joined #moarvm
07:59 Ven joined #moarvm
07:59 zakharyas joined #moarvm
08:26 JimmyZ A very nice book 'Static Single Assignment Book': http://ssabook.gforge.inria.fr/latest/book.pdf  # almost complete, project address https://gforge.inria.fr/scm/?group_id=1950
08:48 FROGGS joined #moarvm
08:50 lizmat joined #moarvm
09:09 FROGGS joined #moarvm
09:42 jnthn JimmyZ++ # nice link indeed!
09:45 JimmyZ https://scm.gforge.inria.fr/anonscm/svn/ssabook/slides/tutorial.pdf # PPT for some more info :)
09:48 jnthn m: say "SSA".flip # :P
09:48 camelia rakudo-moar c54773: OUTPUT«ASS␤»
09:49 timotimo i wonder how many techniques we cannot reliably implement because older versions are not available in our ssa implementation
09:50 timotimo of course we can always allocate a temporary register and set its value right after the desired version gets written
09:50 jnthn "older versions"?
09:51 jnthn Oh, I think know the issue you mean
09:51 jnthn It's a trade-off.
09:51 jnthn If you make the other one you get more costly/difficult deopt
09:52 timotimo yes
09:52 timotimo i remember that
09:53 timotimo hum, now i remember i got nowhere with my deopt bridges thing yet
09:54 timotimo not getting paid enough for complicated things :)
10:12 timotimo not actually convinced i really can deal with complicated things that much better when I'm getting paid...
10:15 Ven joined #moarvm
10:18 timotimo i think i have the impostor syndrome
10:18 timotimo but still better than impastor or inpasta
10:26 arnsholt Is that where you make a lot of copy-pasta?
10:30 timotimo mhhh pasta
10:47 timotimo jnthn: were you able to find out why MapIterCommon doesn't have its new method spesh'd?
10:47 timotimo if not, do you want me to litter the code with debug statements and figure it out?
10:47 jnthn timotimo: No, if you could look into that it'd be great
10:47 jnthn Because it's the kind of method that *should* spesh really well
10:48 timotimo sure, did you use a specific benchmark for it?
10:48 jnthn 'cus it's jsut a bunch of binds to attributes
10:48 jnthn for ^1000 { for ^1000 { } }
10:48 jnthn Well, that may hit the for -> while opt maybe
10:48 jnthn If that still works
10:49 timotimo i recently fixed it
10:49 timotimo it used to look for an &infix:<,> in th QAST, which was reoved duringGLR
10:49 jnthn OK, well, just my @a = ^1000; for @a { for @a { } }
10:50 timotimo rebuilding rakudo now
10:55 timotimo interesting
10:55 timotimo in the profile i'm looking at it gets called 1001
10:55 timotimo 1001 times, about 4/5th of those calls were even jitted
10:55 jnthn Probably something initializ-y
10:55 jnthn Oh?
10:55 timotimo how did you reach the conclusion it doesn't get speshed?
11:00 timotimo that piece of code initializes a crapton of IntLexRef
11:00 timotimo 3005001
11:00 timotimo 2002000 of those in sink-all and 1002001 in pull-one
11:02 timotimo same with a :=, but i suspect that can be eased by implementing push-exactly or something in range's iterator
11:03 jnthn Wow
11:03 jnthn I need to look at the lex ref issues there
11:03 jnthn Maybe that's what I'll do this evening
11:03 jnthn I really need to do several hours on a $other-job today
11:03 timotimo ah, sure
11:03 jnthn But good to know
11:03 timotimo there's a infix:<<> in the code you gave that gets only speshed, not jitted
11:04 timotimo 1002001 calls, 7.04% (155.9ms)
11:04 jnthn How did I conclude it wasn't? Because in the Text::CSV profiler output it isn't being
11:04 timotimo (exclusive time)
11:04 jnthn So we'll need to look deeper :(
11:04 timotimo i'll grab Text::CSV onto my laptop as well
11:05 timotimo all the flaky mobile connections :|
11:06 jnthn if you liked it shoulda put 4G on it
11:06 timotimo occasionally i do get 4G
11:07 timotimo how do you invoke the benchmark?
11:08 jnthn I created a file with this 1000 times:
11:08 jnthn hello,","," ",world,"!"
11:08 jnthn And then
11:08 jnthn cat test-small.csv | perl6-m -Ilib --profile test-t.pl
11:08 jnthn You'll need to grab Slang::Tuxic and File::Temp and File::Directory::Tree also
11:10 timotimo just noticed that
11:11 timotimo rebootstrapping panda right now
11:15 timotimo um ... even with test-t.pl i get almost 99% jitted new
11:15 timotimo src/gen/m-CORE.setting:2696
11:16 timotimo perhaps more worrying is sink-all of sequential map being 100% interpreted and 4.66% exclusive time
11:17 timotimo and 520351 BOOTCode being allocated inside BUILDALL's while loop
11:18 timotimo there's only 5010 calls to BUILDALL according to the routines tab
11:25 timotimo hehe.
11:25 timotimo List's iterator method has a class :: does Iterator in it
11:25 timotimo that generates code to take a whole bunch of closures
11:25 timotimo it gets called 36013 times
11:26 timotimo allocates 180065 BOTOCode in total
11:30 timotimo m: say 180065 / 36013
11:30 camelia rakudo-moar 7c9911: OUTPUT«5␤»
11:30 timotimo that's how many methods that class has :P
11:30 timotimo i've just moved it out of the method and i'll see if it makes a big difference
11:38 timotimo yeah, though i couldn't report it due to flaky network >_>
11:40 timotimo 55 instead of 59 gc runs
11:40 timotimo we may want to move some more classes for iterators out of the methods that use them, to prevent taking closures fro all the methods
11:40 jnthn Wait, why are they taking closrues?!
11:41 jnthn If they are something's up with our code-gen
11:41 timotimo they shouldn't be?
11:41 jnthn The only time a method should take a closure is if it's an l-value
11:41 jnthn uh damn
11:41 jnthn r-value
11:42 jnthn In a class body it's always in sink context
11:42 timotimo how else would we have classes defined in inner scopes be able to refer to closed-over values?
11:42 jnthn Classes aren't closures
11:42 timotimo ah!
11:42 timotimo well, then you can fix it :)
11:42 jnthn Thus why we've had and fixed various bugs where people did refer to lexicals :)
11:43 jnthn OK, I'll put it on my todo list along with looking at the code-gen issues that make too many lexicalrefs
11:43 jnthn Hm, if we can fix these two then we would get GC runs down a lot
11:44 timotimo likely (and hopefully)
11:44 jnthn And so improve performance a whole lot
11:47 nwc10 other bloggage: http://morepypy.blogspot.co.at/2015/09/pypy-warmup-improvements.html
11:48 timotimo our GC isn't the fastest
11:48 timotimo we still have those bunchtons of gen2 roots that are irking me a bit
11:48 timotimo i'd love common gc run times to dwindle below 2ms :|
11:52 timotimo actually, if we want to ever be able to do 60fps game development or something, 2ms is still more than a single video frame
11:55 Ven joined #moarvm
11:59 timotimo maybe incremental GC would be a thing to consider at some point? i have no idea what requirements that adds to the rest of the VM and if we can get there easily enough
12:02 jnthn On my box I see GC times of 3ms-4ms in various cases
12:03 nwc10 for now, I suspect that we get bigger net wins by doing other stuff, relying on KISS and the tail end of Moore's Law.
12:03 nwc10 but that's just an opinion.
12:05 jnthn m: say 1/60
12:05 camelia rakudo-moar 7c9911: OUTPUT«0.016667␤»
12:05 jnthn That's a lot more than 0.002 :P
12:05 nwc10 jnthn: even if you're now in SECAM territory, surely as you're still in Europe, the correct fraction is 1/50 :-)
12:07 timotimo wow, i want some of these gc times
12:07 timotimo oh, i thought millisecond meants 1/100 second, haha, that's fail
12:10 timotimo but still, i hardly ever get gc times as good as jnthn's getting :(
12:10 timotimo or is that really just "in some cases"?
12:11 jnthn I had 3.x ms average GC for the for lines('file'.IO) { }
12:11 jnthn 6-7ms is common in apps that are retaining more stuff
12:12 timotimo let's see.
12:12 timotimo ah, for that test-small.csv isn't big enough by far :)
12:13 timotimo 7 to 8 ms in that
12:13 timotimo can our machines' performance differ this drastically?
12:18 timotimo i'll teach the jit about continuationreset, that'll make pull-one jittable, which is at 15% exclusive time in the for-lines benchmark
12:19 jnthn Wait, are you on latest?
12:20 jnthn I made for 'foo'.IO.lines { } not use continuations
12:20 timotimo oh!
12:20 jnthn But sure, do that anyway :)
12:20 timotimo shall i still go ahead?
12:20 jnthn Because it'll make every gather/take thing faster :)
12:20 timotimo right. first i'll have to get off this train, though
12:20 timotimo damn, and my fav song of this album just came on :(
12:47 JimmyZ left #moarvm
12:47 JimmyZ joined #moarvm
12:50 timotimo if something in interp.c sets the cur_op before calling the C function in question, i'll mark it :invokish in the oplist, so that the jit doesn't explode, right?
12:50 FROGGS sounds reasonable
12:51 timotimo though in this case it's not because it invokes stuff, but because it records the cur_op into the continuation's address
12:52 FROGGS :throwish seems to have a similar effect
12:59 timotimo BBL
13:18 virtualsue joined #moarvm
13:37 brrt joined #moarvm
13:37 brrt \o
13:37 Ven joined #moarvm
13:41 FROGGS hi brrt
13:42 brrt hi FROGGS
13:49 virtualsue left #moarvm
14:33 tokuhiro_ joined #moarvm
14:48 Ven joined #moarvm
15:21 hoelzro jnthn: regarding that string heap optimization, is the optimization that MoarVM SCs no longer have their own string heaps, and just expect the code to refer to the string heap in the bytecode itself?
15:21 hoelzro I really want to fix the nqp-js problem, and I think the only way to do that is to truly understand that optimization
15:22 jnthn hoelzro: It's exactly that, yes
15:22 jnthn hoelzro: Actually all we used to do was just build a string array
15:22 Ven joined #moarvm
15:22 jnthn So there was a huge push arr, "foo" sequence
15:23 jnthn And the change was just to get SCs to use identical indexes to the string heap of the bytecode file itself
15:23 jnthn So we could save that
15:23 jnthn Which saved a bunch of work at startup
15:25 hoelzro so the dependency string heap reference will almost definitely have a different index after the optimization, right? since it's referring to all strings in the compunit?
15:25 hoelzro or is that wrong? a compunit with a single SC would have essentially the same string heap as the SC itself, maybe?
15:26 * hoelzro looks as this as a good thing, because he never really understood the serialization stuff before
15:26 jnthn iirc, the serializer pushes the unique strings into a list
15:27 jnthn And then keeps that list somewhere internal in the VM
15:27 jnthn Oh, on the current CompUnit I think
15:27 hoelzro is there a way to get --dump to dump things like the string heap, or lower level info on the SCs in the compunit?
15:27 jnthn And then uses it when it does the MAST -> bytecode
15:27 jnthn Not that I'm aware of
16:04 FROGGS joined #moarvm
17:14 Ven joined #moarvm
18:30 arnsholt joined #moarvm
18:45 timotimo i'm puzzled
18:46 timotimo as soon as the jit kicks in on "my num @values; loop { @values.push: 0.0e1 }" it complains "expected num register!"
18:46 vendethiel joined #moarvm
18:47 timotimo but the jit code that's responsible for what gets emitted there should really put MVM_reg_num64 into the slot that decides what happens
19:16 brrt joined #moarvm
19:26 tokuhiro_ joined #moarvm
19:38 Peter_R joined #moarvm
20:07 Ven joined #moarvm
21:03 brrt joined #moarvm
21:07 brrt holy mother of irregular instruction encoding
21:08 brrt timotimo: is that the old JIT? and what line says that?
21:10 brrt apparantly, kids, if and only if the register number of an indexed register is 4, then we need a second modrm byte, or something
21:11 timotimo m)
21:12 timotimo brrt: what do you mean "what line says that"?
21:12 brrt what line says 'expteced num register!'
21:12 timotimo ah
21:12 timotimo that's from push
21:14 brrt i expect we use push_n for that?
21:14 timotimo it's as if this line was wrong:
21:14 timotimo m)+                                             (op == MVM_OP_push_n || op == MVM_OP_unshift_n) ? MVM_reg_num64 :
21:14 timotimo (without the facepalm smiley in front)
21:14 timotimo jitlog says it's been devirtualized
21:14 timotimo and speshlog says it's actually a push_n
21:15 brrt hmmm
21:15 timotimo oh, my str @foo is NYI?
21:15 timotimo perhaps a GLR thing?
21:15 brrt i think .. i dunno
21:17 timotimo it was also NYI pre-glr
21:24 brrt the bytecode generation issue is an irregularity in the encoding of rbp
21:24 timotimo x86 is hard
21:24 FROGGS rbp?
21:24 timotimo base pointer?
21:26 brrt yes.... and also r12, since that looks just like rbp from the perspective of x86
21:26 brrt x86 is really, really hard
21:28 tokuhiro_ joined #moarvm
21:30 brrt actuayll, it's rsp, not rbp
21:31 brrt anyway...
21:31 brrt it looks like something i can crack
21:31 FROGGS ++brrt
21:31 brrt keep the ++'s for when the commit comes :-P
21:31 FROGGS sure :o)
21:32 FROGGS always got some in my pocket
21:32 timotimo sounds like you know what way to go and all that might stand in your way is missing infrastructure for keeping the information that modrm needs to become bigger ... or something
21:34 brrt hmm yeah, i guess
21:35 timotimo does it seem like that's the last problem on your way?
21:35 brrt last instruction encoding problem i'm aware of, yes
21:35 timotimo awesome :)
21:35 brrt there is a cheap-but-ugly workaround. it means giving up r12
21:36 brrt and not use it at all
21:36 timotimo sure
21:36 timotimo then you'll see if everything else works but that :)
21:36 brrt that'd work. but it'd only be a matter of time before somebody would choose to push dynasm over the limit again
21:36 brrt possibly me
21:36 timotimo giving up just a single register doesn't sound terrible
21:37 brrt well, it's also all stack relative stuff
21:37 brrt r12 and rsp
21:37 timotimo oh
21:37 timotimo that's more interesting, then
21:37 brrt why they are irregular, i don't know
21:37 timotimo otherwise i'd have said "if fixing this takes too long, skipping it will get us to a working code gen faster"
21:38 brrt well, i'm going to think about it more
21:38 brrt fairly sure this can be fixed
21:38 timotimo mhm
21:38 brrt we have the 'meaning' of the vreg at runtime
21:38 brrt so we can actually add/rewrite the bytes
21:39 brrt but it's tricky
21:39 brrt (the good bit is, it was already broken before i started ^^)
21:39 timotimo yeah :)
21:39 timotimo "we" being "inside the dynasm internals", right?
21:41 brrt yes
21:41 brrt the runtime
21:42 brrt but it requires i study the entire bytes-meaning table
21:42 timotimo urgh
21:42 timotimo you'll has a bachelor of ft'aghn after that
21:43 brrt http://wiki.osdev.org/X86-64_Instruction_Encoding#32.2F64-bit_addressing
21:43 brrt and this beaty here: http://wiki.osdev.org/X86-64_Instruction_Encoding#32.2F64-bit_addressing_2
21:43 timotimo oh, that's not gigantic
21:44 timotimo it's just a lot
21:44 brrt yeah, it's managable, it's just highly irregular
21:45 kjs_ joined #moarvm
21:45 timotimo turn off your patern recognition brain parts and it'll feel better, eh? :D
21:45 timotimo you won't even notice there's no regularity to it!
21:45 brrt right :-)
21:45 brrt i'm going to sleep
21:45 brrt see you tomorrow!
21:46 timotimo good night brrt!
22:29 tokuhiro_ joined #moarvm
22:53 kjs_ joined #moarvm
23:40 tokuhiro_ joined #moarvm

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