Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-11

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

All times shown according to UTC.

Time Nick Message
01:08 colomon joined #moarvm
01:10 agentzh_ joined #moarvm
02:10 agentzh_ joined #moarvm
02:53 colomon joined #moarvm
03:39 agentzh_ joined #moarvm
04:54 agentzh_ joined #moarvm
06:26 FROGGS joined #moarvm
06:49 zakharyas joined #moarvm
06:52 agentzh_ joined #moarvm
06:57 Ven joined #moarvm
07:32 lizmat joined #moarvm
08:10 lizmat joined #moarvm
08:38 lizmat joined #moarvm
08:52 lizmat_ joined #moarvm
08:54 lizmat joined #moarvm
08:58 lizmat_ joined #moarvm
09:34 lizmat_ joined #moarvm
09:39 lizmat_ joined #moarvm
09:43 lizmat joined #moarvm
09:48 agentzh_ joined #moarvm
09:51 lizmat_ joined #moarvm
09:56 lizmat joined #moarvm
09:58 flussence joined #moarvm
10:04 lizmat_ joined #moarvm
10:21 lizmat joined #moarvm
10:34 lizmat_ joined #moarvm
10:37 lizmat__ joined #moarvm
10:37 lizmat___ joined #moarvm
11:19 brrt joined #moarvm
11:25 rurban joined #moarvm
11:26 agentzh_ joined #moarvm
11:28 brrt \o
11:28 masak o/
11:29 jnthn o/ brrt
11:31 brrt o/ jnthn, masak
11:31 brrt you all still as osdc?
11:31 brrt or flying back already
11:33 jnthn brrt: Still here at a small hackathon after it, but leaving by train this evening
11:35 brrt :-o that is quite a distance (google maps tells me 7 h 37 min
11:37 masak I'm not at OSDC :/
11:37 brrt well, too bad, but neither am i :-)
11:39 jnthn brrt: I'm only going as far as Goteborg...
11:39 brrt ah, thats probably more reasonable :-0
11:39 brrt :-)
11:40 brrt is osdc a perl conference?
11:40 brrt they do use act
11:45 jnthn It was Perl and QT and civic hacking and more
11:46 brrt so pretty broad actually. nice
11:46 jnthn Yeah, it was a nice event
12:16 Ven joined #moarvm
12:16 masak seemed like a nice event from the online echoes... :)
13:38 jnthn With MoarVM HEAD, on Windows (64-bit), building NQP immediately explodes like this:
13:38 jnthn JIT: trying to pass arguments  in local space (stack top offset:  64, size: 8) at <unknown>:1  (src\vm\moar\stage0/QRegex.moarvm:!cursor_pass:4294967295)
13:41 agentzh_ joined #moarvm
13:41 brrt what, what
13:41 brrt ow, i see
13:42 brrt two things
13:42 brrt a): that shouldn't be an exception, you silly persion
13:43 jnthn I don't immediately understand enough to fix it but I'm guessing it's the repr op devirt now has an arg list too long to JIT code for on Windows.
13:43 brrt s/persion/person/
13:43 brrt yes, that is precisely what's going on
13:44 brrt ugh, blame me for not checking on windows, i should have
13:44 brrt theres an easy fix though
13:45 jnthn OK, I'll leave it to you :)
13:47 brrt :-)
14:20 FROGGS okay, so this is nothing about my QRegex work?
14:22 jnthn 3No
14:22 timotimo sorry about blowing stuff up with devirt :(
14:23 brrt np :-)
14:23 timotimo the "easy fix" isn't in moar yet, though?
14:23 brrt no
14:23 brrt how much stack space do we want
14:23 brrt we have 64 bytes
14:23 brrt we should increase this to how much?
14:23 timotimo and i'm blowing that already?
14:24 brrt no
14:24 brrt you have something with 8 arguments?
14:24 brrt eh, 9 arguments, probably
14:24 brrt 0..8
14:24 timotimo i don't know actually
14:25 timotimo yeah, one with 9
14:25 timotimo the getattr series of ops
14:25 timotimo and the bindattr series, too
14:26 brrt getattrs and bindattrs, indeed
14:26 brrt anyway
14:27 brrt how much do we want to increase this to?
14:27 jnthn brrt: Is there a cost to increase it?
14:27 brrt 128 bytes?
14:27 brrt hardly
14:27 jnthn OK, then 128
14:27 brrt 128 is 0x100 iirc
14:28 jnthn m: say 0x100
14:28 camelia rakudo-moar f9c982: OUTPUT«256␤»
14:28 jnthn :)
14:28 jnthn m: say 0x80
14:28 camelia rakudo-moar f9c982: OUTPUT«128␤»
14:29 timotimo 88 bytes per hour!
14:29 timotimo (you'll see some crazy shit)
14:29 brrt compiling
14:29 brrt aye, you're right
14:29 brrt hmmm
14:29 brrt wait a minute
14:29 brrt then my check is wrong
14:30 brrt let me think a bit longer
14:30 timotimo if we make the stack much bigger, we'll possibly consume more cache lines with unused data?
14:30 brrt who cares :-)
14:30 brrt but i'm checking the calculation
14:31 brrt ok, we allocate 0x80 bytes, is 128 bytes
14:32 brrt then we pass the arguments by offset from rsp upwards
14:33 masak m: say 128.base(16)
14:33 camelia rakudo-moar f9c982: OUTPUT«80␤»
14:33 masak m: say "0x", 128.base(16)
14:33 camelia rakudo-moar f9c982: OUTPUT«0x80␤»
14:34 brrt we store the work registers from rbp downward, in the range 0...0x20
14:34 brrt m: say 0x20
14:34 camelia rakudo-moar f9c982: OUTPUT«32␤»
14:34 brrt so...
14:34 brrt if we have 0x80 bytes allocated
14:34 brrt and we write downwards as the position gets higher
14:34 brrt m: say 0x80 - 0.20;
14:34 camelia rakudo-moar f9c982: OUTPUT«127.8␤»
14:34 brrt x
14:35 brrt m: say 0x80 - 0x20;
14:35 camelia rakudo-moar f9c982: OUTPUT«96␤»
14:36 brrt we actually have 96 bytes over
14:56 brrt ok, i have time for you again
14:56 brrt :-)
14:57 brrt oh goody, windows uses 0x20 bytes from the 0x96 for the first 4 arguments
14:57 brrt eh not from the 0x96 but from the argument space
14:59 FROGGS joined #moarvm
15:05 brrt but the other bytes, we use for scratch space
15:05 brrt so in short
15:05 brrt we have the following layout
15:06 brrt [ 0x20 (save stable regs) | 0x20 (scratch space) | 0x20 (arg space on windows) | 0x20 (reserve arg space on windows) ]
15:08 brrt for posix that is the same, except that we have 0x40 bytes of stack space near the top
15:08 brrt because posix doesn't reserve the 0x20 bytes near the top
15:09 brrt now, if we use not 0x80 but 0x100 bytes of stack space...
15:09 brrt (that's quite liberal, innit)
15:09 brrt then we have on windows
15:09 brrt [ 0x20 a | 0x20 b | ... | 0x20 d ]
15:10 brrt m: (0x100 - 0x60).say
15:10 camelia rakudo-moar 4c1d2d: OUTPUT«write string requires an object with REPR MVMOSHandle␤  in block <unit> at /tmp/8wjVgHxMg7:1␤␤»
15:10 brrt m: say 0x100 - 0x20
15:10 camelia rakudo-moar 4c1d2d: OUTPUT«write string requires an object with REPR MVMOSHandle␤  in block <unit> at /tmp/LGDkokDxYc:1␤␤»
15:10 brrt m: say (0x100 - 0x60).Str
15:10 camelia rakudo-moar 4c1d2d: OUTPUT«write string requires an object with REPR MVMOSHandle␤  in block <unit> at /tmp/mGa4QMTP1G:1␤␤»
15:10 brrt m: 0x20.say;
15:10 camelia rakudo-moar 4c1d2d: OUTPUT«write string requires an object with REPR MVMOSHandle␤  in block <unit> at /tmp/065b7Rp6bV:1␤␤»
15:10 brrt m: "OH HAI".say;
15:10 camelia rakudo-moar 4c1d2d: OUTPUT«write string requires an object with REPR MVMOSHandle␤  in block <unit> at /tmp/1H9fAjXdWR:1␤␤»
15:10 brrt what
15:11 brrt we have no fewer than 0xa0 bytes left in that case
15:11 brrt or 160
15:12 brrt that means space for 20 arguments in total (windows)
15:13 brrt or 30 arguments on posix, if i'm corrct
15:22 dalek MoarVM: bec36ae | brrt++ | src/jit/emit_x64.dasc:
15:22 dalek MoarVM: Increase stack space for call arguments.
15:22 dalek MoarVM:
15:22 dalek MoarVM: This may be a costly change, because it makes our stack space two
15:22 dalek MoarVM: cache lines large. But it should make moar work on windows again.
15:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bec36aeb56
15:23 agentzh_ joined #moarvm
15:23 nwc10 brrt: presumably you could do that just on Windows? But, for now, I'm assuming KISS is best
15:23 nwc10 (fix it between September and Christmas)
15:37 FROGGS .tell brrt I was able build: perl6 version 2015.04-221-gfce74e1 built on MoarVM version 2015.04-105-gbec36ae
15:39 nwc10 FROGGS: on what OS? (implied is something win)
15:39 FROGGS nwc10: win 7 x64
15:40 TimToady doesn't seem to run any slower here
15:40 FROGGS I'm also checking that as we "speak"
15:40 nwc10 if nothing references those cache lines, it won't matter, other than page size, will it?
15:40 nwc10 by "references" I'm meaning "reads from or writes to"
15:47 FROGGS yeah, does not feel slower
15:52 Ven joined #moarvm
15:59 [Coke] (can't we do a stage0 update in a branch and then when merging, only merge everything else, and redo the stage0 update in master?)
16:11 lizmat I had an unexplained slowdown late last night, that I fixed by nuking install and rebuilding
16:44 lizmat joined #moarvm
16:44 * jnthn waves from a train
16:44 jnthn brrt++ # fixing stuff
16:45 nwc10 jnthn: a moving train? in the right direction?
16:46 jnthn yes, but I managed to get in the carriages that only go part of the way
16:47 jnthn But I've no idea if there are many free seats in the carriages that go all the way, so will not hurry to move :)
17:12 pyrimidine joined #moarvm
17:30 timotimo maybe we should strike that item off the roadmap now? the reprop devirtualization?
17:31 FROGGS joined #moarvm
17:33 jnthn I tend to do it each release.
17:33 jnthn (update it)
17:34 jnthn But feel free to do it now...I think you have a commit bit to the site
17:34 timotimo ah
17:34 timotimo yes, i do
17:34 timotimo will do it later today
17:36 timotimo i still need to find some benchmark that shows a time improvement with devirt'd reprops compared to without
17:36 timotimo perl6-bench didn't show any improvement ;(
17:37 jnthn Did you try getting instruction count numbers under callgrind?
17:37 timotimo i don't think i did, no
17:38 jnthn give it a go mebbe :)
17:38 jnthn Time for a train switch here...
17:38 jnthn bbl
18:11 FROGGS [Coke]: what would that give us? (besides an even bigger repository to clone)
18:12 [Coke] FROGGS: a place where we can test your code? We already gave up on repo size when we checked in stage 0. :)
18:13 jnthn If you go through a few rebootstraps then you can squash them into one when merging a branch and then delete the branch, which can save space :)
18:13 jnthn But you hvae to know that they're coming :)
18:14 FROGGS [Coke]: I extensively tested my code... I only do branches for review/testing in case I'm uncertain
18:14 FROGGS [Coke]: and here jnthn already reviewed it (even when he did not run/test it)
18:14 FROGGS but pushing a stage0 to a branch does not give us any value
18:15 [Coke] I disagree, but ok. it's your branch.
18:15 FROGGS disagree about what detail?
18:15 [Coke] "that it doesn't give us any value"
18:16 FROGGS jnthn: true... maybe we need a 'call for new ops' besides the usual call for papers
18:16 FROGGS [Coke]: I agree that branches are nice when you want to push code that needs testing by other ppl
18:18 FROGGS jnthn: you can't squash jvm's stage0 though, can you?
18:18 jnthn You can't squash shared history, no
18:18 jnthn But when I was doing the moarvm support for example, I had about 6 different state 0s along the way.
18:18 jnthn *stage
18:19 jnthn And squashed those before the merge.
18:19 jnthn Think I did similar with the JVM branch
18:19 jnthn But yeah, once it's in master then...no luck.
18:19 FROGGS well, I think about the scenario where you have new ops in two branches, and these two ops are *used* in nqp...
18:19 FROGGS you won't be lucky there
18:20 [Coke] yes, you don't merge the generated files in that case, you regenerate them.
18:20 FROGGS if new ops aren't used in nqp, you don't need a stage0
18:20 FROGGS so there is no (easy) way to merge stage0's
18:20 [Coke] no one is suggesting that.
18:21 [Coke] sorry: *I* am not suggesting that.
18:21 FROGGS [Coke]: and you only can regenerate stage0 when you can build nqp
18:21 jnthn I don't think it happens often enough to really be worrying over it.
18:24 FROGGS yes, though it would be nice if we did not have to care about stage0... and it would be also nice to be able to refactor moarvm ops, but...
18:25 FROGGS like I would like to change some ops so that they branch
18:25 ggoebel2 joined #moarvm
18:25 FROGGS but that seems impossible, even via creating (and afterwards deleting) a temp op
18:26 betterwo1ld joined #moarvm
18:27 arnsholt joined #moarvm
18:31 jnthn battery out &
18:36 brrt joined #moarvm
19:38 camelia joined #moarvm
20:27 lizmat joined #moarvm
20:31 colomon joined #moarvm
20:44 brrt joined #moarvm
21:16 timotimo brrt: what's the reason behind making the stack bigger on unix as well? i thought we only need that on windows?
21:17 brrt mostly macro trickery, really
21:17 brrt the is-windows flag is set at dynasm time
21:18 brrt whereas we do the check at runtime, so we'd need to convert it at least to a c-preprocessor macro
21:19 timotimo mhm
21:19 brrt or at least something like that
21:19 brrt i'm aware there are msvc-specific flags
21:19 brrt i won't do that because people may well be cross-compiling
21:20 timotimo ah, sure
21:21 timotimo i've just been told intel has the possibility to add into a memory address rather than just a register
21:21 timotimo maybe we could get a decent size improvement if we did that throughout; and also for other opcodes?
21:21 brrt i'm actually not all that familiar with a very clear way to know we're targetting win64 abi
21:21 brrt ehm.....
21:21 brrt well, i'd think at least one of these has to be a register?
21:22 timotimo yes, sure
21:22 brrt then i'm not sure how we could profit (now)
21:22 timotimo but rather than load A, load B, add A B, store A
21:22 timotimo we could have load B, add
21:22 timotimo load B, add to memory of A B, done
21:22 brrt no
21:22 brrt or
21:23 brrt yes, if the destination register C is identical to A
21:23 brrt may be a worthwhile optimization
21:23 timotimo usly
21:25 timotimo ...
21:29 brrt hmm?
21:29 brrt its still a minor optimization since under the cover you'll do the exact same thing
21:29 brrt but in binary size it will help a bit
21:30 timotimo my laptop is oozing hard
21:30 timotimo oom-ing
21:33 agentzh_ joined #moarvm
21:33 brrt out-of-memory?
21:33 timotimo yes
21:33 timotimo unpacked a big tarball in /tmp
21:34 brrt and /tmp is on memory?
21:35 brrt ugh, casts to (void*), one reason not to like c++
21:35 timotimo i just figured that out :)
21:38 timotimo ah
21:38 timotimo the rm -rf just came through in my /tmp
21:41 colomon joined #moarvm
21:43 brrt :-)
21:43 * brrt afk
21:43 brrt see you tomorrow
21:44 lizmat brrt: good night!
21:44 brrt good night :-)
22:36 lizmat joined #moarvm
23:01 timotimo in one case we'd have load accumulator, load argument, add/subtract/whatever, store accumulator; in the other case we'd have load argument, add/subtract/whatever in-place; that could indeed be a little win
23:02 timotimo and i even found an example where there's more adds and subtracts with the accumulator going into the same register as it was loaded from
23:02 timotimo 236 accumulator_stats: sub_i: same
23:02 timotimo 149 accumulator_stats: add_i: same
23:02 timotimo 136 accumulator_stats: add_i: different
23:02 timotimo 58 accumulator_stats: sub_i: different
23:02 timotimo this being t/spec/S05-mass/properties-script.rakudo.moar
23:05 timotimo i could imagine this is the regex engine
23:18 timotimo huh, that test now fails? :\
23:20 agentzh_ joined #moarvm
23:22 timotimo ah, confused by intel syntax
23:22 timotimo haven't asm in a long time, it seems

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