Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-02-17

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

All times shown according to UTC.

Time Nick Message
00:51 pyrimidine joined #moarvm
02:35 ggoebel joined #moarvm
02:38 pyrimidine joined #moarvm
02:46 agentzh joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:25 lizmat joined #moarvm
03:37 pyrimidine joined #moarvm
04:07 pyrimidine joined #moarvm
04:10 deepbook5broo joined #moarvm
04:10 deepbook5broo left #moarvm
04:39 MasterDuke joined #moarvm
06:09 pyrimidine joined #moarvm
06:38 pyrimidine joined #moarvm
06:39 brrt joined #moarvm
06:40 brrt timotimo: no, i need the upper 32 bits and the lower 32 bits in two different words
06:45 samcv timotimo, the new datastructure is way easier to debug than the if else change so i'm getting rid of the if else chain and waiting until i get perfect cp to bitfield rows for all cp
06:46 samcv today got it working all the way up to where we start to have gaps (reserved characters)
06:46 samcv never tried to split a 32bit across a word
06:47 samcv oh you just need to split them from that value. i guess gcc determines it at compile time
07:15 pyrimidine joined #moarvm
07:45 brrt joined #moarvm
08:25 Geth ¦ MoarVM/even-moar-jit: d2d4ee0117 | (Bart Wiegmans)++ | 9 files
08:25 Geth ¦ MoarVM/even-moar-jit: Implement ARGLIST-to-storage ref conversion step
08:25 Geth ¦ MoarVM/even-moar-jit:
08:25 Geth ¦ MoarVM/even-moar-jit: The register allocator can work with the storage refs to determinehow to
08:25 Geth ¦ MoarVM/even-moar-jit: move values through the registers in order to compile function call
08:25 Geth ¦ MoarVM/even-moar-jit: arguments.
08:25 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/d2d4ee0117
08:25 brrt design question time, again
08:29 brrt problem: I need a way to make the register allocator 'see' the special tiles and/or special tile register requirements
08:30 brrt they can be 'skipped over' because the register allocator works from live range to live range and these only start at tiles that define a new value; tiles that use values (like ARGLIST) are never even seen
08:31 brrt so there's two ways i can see to deal with that
08:32 brrt a): detect those tiles during live range construction, and maintain a queue of them, and switch-iterate over that queue and the worklist
08:34 brrt b): maintain an index 'last tile idx', that is updated for every live range to their start; and prior to allocating for a live range, iterate over the range between (last_idx and start_of_live_range], and handle special cases in this loop
08:34 brrt they are equivalent, fwiw
08:34 brrt one requires maintaining a queue and splits 'detection' and 'handling', the other does it in a single loop
08:34 moritz is a tile a struct?
08:35 brrt yeah, a tile is an object-representation of an instruction
08:35 moritz so could you give it a boolean (or a bit flag) marking it as special
08:35 moritz so that the register allocator doesn't have to do extra logic
08:35 brrt well, yeah, it's easy enough to detect
08:36 brrt there's actually two cases in which something can be special so far
08:36 moritz as you might gather from my questions, I have no idea what I'm talking about, just bouncing around ideas in the hopes that it helps you make a good decision :-)
08:37 brrt ':-) it's appreciated
08:37 brrt one case: by pure semantics of the node it represents (e.g. argument lists, subroutine calls)
08:38 brrt second case: by special register requirements of the instruction it represents (e.g. div, mul in x86)
08:38 brrt either is a very cheap check
08:39 zakharyas joined #moarvm
08:39 moritz sounds like a simple macro could do then?
08:40 brrt yeah. the question is reallly: which of the two loops should do the check
08:40 moritz which loop is hotter?
08:40 brrt one loop analyzes all code to construct a live range, other loop analyzes all live ranges (i.e. a smaller set) to allocate registers
08:41 brrt makes no difference, both are O(N) to the size of the code
08:41 brrt well, it makes some difference
08:43 brrt the second loop is now O(number_of_live_ranges) and the first O(number_of_tiles)
08:44 brrt number_of_tiles is strictly larger than number_of_live_ranges
08:44 moritz then it sounds like special detection should go into the loop over the live ranges
08:44 brrt but they are in the same order, really
08:44 moritz purely from a performance perspective
08:45 brrt well, i haven't explained the crucial bit
08:45 brrt making the special detection changes the second loop also to O(number_of_tiles), because, well, it now has to loop over all tiles
08:46 moritz then don't do that :-)
08:47 brrt maintaining a queue isn't free, either
08:47 brrt sorry, i can argue this any which way, and I'm not yet decided :-)
08:49 moritz I notice :-)
08:49 moritz re queue isn't free, hence my question earlier if you could store the information in the tile itself
08:49 brrt well, it is already stored in the tile, so to speak
08:50 brrt and pretty cheap to detect
08:50 moritz but not cheap enough to do it where you need the information?
08:50 brrt well, yes
08:51 brrt okay, i guess the question i have to ask myself
08:51 brrt if i put it in a queue, am i going to do something with that data structure or just iterate on it
08:54 brrt is there additional cleverness that can be enabled by the queue, or do i just like queues and that's why i want one?
09:16 pyrimidine joined #moarvm
09:32 geekosaur joined #moarvm
10:33 geekosaur joined #moarvm
10:47 jnthn A queue you just iterate over is called an array, no? ;)
10:48 moritz a qarray :-)
10:50 jnthn On modern hardware, computation is cheap compared to memory access, though
10:50 jnthn Which speaks somewhere against the queue
10:50 jnthn Unless the computation needs memory accesses itself on stuff you'd otherwise not be looking at
11:03 pyrimidine joined #moarvm
11:12 timotimo i've seen an interesting article about a better scheme to locate a tree's nodes inside a flat array, that maximizes cache-locality; i'm sure that can be used for a priority queue
11:13 geekosaur joined #moarvm
11:13 timotimo i think it was actually for an a,b-tree
11:14 timotimo there's a paper by erik demaine called "cache-oblivious b-trees": http://erikdemaine.org/papers/FOCS2000b/paper.pdf
11:14 timotimo oh, hold on
11:15 timotimo won't a priority queue based on a binary tree often pull things from way down below?
11:15 timotimo hm, i don't remember what the access pattern looked like
11:22 Ven joined #moarvm
11:22 timotimo actually, thinking of it i seem to recall it just switches one from the bottom with one along the way each time you pull out one element
11:50 Ven joined #moarvm
11:53 brrt jnthn: great, make it harder
11:53 dogbert17 hmm, we're beginning to run out of MoarVM panics and SEGV's, shocking :)
11:53 brrt well, it acts as a queue, don't it
11:53 brrt :-P
11:53 brrt so yeah
11:53 brrt i would otherwise not be looking at the tiles inbetween that *aren't* special
11:57 jnthn dogbert17: Hm, I thought that RT had around 30 tickets tagged as SEGV, should perhaps check those? :)
11:58 jnthn (And if they no longer SEGV, we can mark them testneeded and remote the label)
11:58 jnthn *remove
12:07 geekosaur joined #moarvm
12:15 dogbert17 jnthn: https://github.com/MoarVM/MoarVM/issues/538 is mildly interesting, there are several RT's describing similar problems
12:16 timotimo dogbert17: could you wrap big chunks of output in ``` ... ``` in github issues and such?
12:16 timotimo actually, apparently i'm allowed to edit your comment. but i won't, that'd be a bit rude
12:16 pyrimidine joined #moarvm
12:16 dogbert17 timotimo: should I have used a gist instead?
12:17 timotimo no
12:17 timotimo it's okay to put it into the issue
12:17 timotimo unless it's three pages big
12:17 dogbert17 or is ``` ... ``` some sort of command of some sort
12:17 moritz it's markup
12:17 moritz for code blocks
12:17 timotimo yeah, it's from github-flavoured markdown
12:17 moritz you can also indent them four spaces instead
12:18 dogbert17 hmm, let me try
12:18 ilmari git glog
12:18 ilmari EWIN
12:19 dogbert17 better?
12:24 timotimo lovely
12:24 timotimo i bet github put a "this issue was mentioned in issue 538" into issues 1 through 15 :D
12:26 dogbert17 thx, you learn something new every day :)
12:27 timotimo you can also turn on syntax highlighting in these blocks by putting the name of the language directly after the opening ```
12:30 dogbert17 aha
12:32 dogbert17 here's a SEGV example from RT which I believe has been fixed, https://rt.perl.org/Public/Bug/Display.html?id=128705 (doesn't crash for me)
12:52 brrt jnthn, i have a MSVC related question
12:53 brrt can MSVC compile assembly files, and if so, what syntax does it use
12:54 brrt i'm betting it can't....
12:55 jnthn Heh, the inline assembly only supports x86
12:55 timotimo m( m( m( m(
12:57 jnthn It does ship with an assembler though
12:57 jnthn ml64
12:58 jnthn https://msdn.microsoft.com/en-us/library/hb5z4sxd.aspx
13:07 brrt that's something
13:08 brrt i'm planning to make a stack walker
13:08 brrt so for that, i need a bit of assembly code
13:09 brrt (the purpose is to figure out the current position of the program in case we're throwing an exception)
13:09 jnthn Aha :)
13:09 jnthn So we don't need to stash labels all over the code? :)
13:17 pyrimidine joined #moarvm
13:30 brrt indeed
13:30 brrt that should save a bit of runtime costs
13:31 jnthn Nice :)
13:41 brrt well, the cost is that you'll have to have -fno-omit-frame-pointer, which *costs* you a bit on runtime
13:41 brrt how much exactly, i don't know
13:59 brrt joined #moarvm
14:04 jnthn Could do a build each way and callgrind some things :)
14:06 IOninja Does MoarVM have some sort of catch phrase? Tag line? Moto?
14:07 jnthn We didn't even get to having a logo, let alone that ;-)
14:08 IOninja heh
14:08 jnthn Though I guess I've quipped a few times that a VM is doing its job right when language users don't know/think about it :-)
14:09 jnthn I mean, the typical Perl 6 user only really cares about MoarVM when it panics or SEGVs. ;-)
14:09 jnthn Or runs stuff too slowly ;-)
14:09 IOninja heh
14:10 * IOninja tries to imagine what that would look like as a tagline...
14:17 timotimo "serving from the shadows"
14:24 IOninja That sounds like something the Protos would say....
14:25 timotimo yup
14:25 timotimo like, the stalker for example
14:25 timotimo "i serve ... for now"
14:25 timotimo did you ever try to do something with the MVM crab concept?
14:28 IOninja Nope. But I'm working from home today and have the work laptop hooked up to big monitor so I can use the design software properly after work. Hence why I was asking about tag lines
14:29 IOninja Not gonna do the crab tho. Crabs are slow
14:29 timotimo *neat*
14:29 timotimo okay.jpg
14:29 timotimo BBL
14:30 timotimo (definitely not going to the corner to cry)
14:34 jnthn Ain't some crabs actually pretty speedy? :)
14:36 IOninja I see several mentions of 0.15m/s on Google. Not even 1km/h
14:38 jnthn Lame :)
15:05 nwc10 jnthn: valgrind (for 3 weeks or so) has not found problems in spectest6
15:05 nwc10 ASAN barfs: http://paste.scsys.co.uk/553224
15:05 nwc10 this seems to be a new variant backtrace
15:07 jnthn It looks like somehow, occasionally, the GC double-frees things :S
15:07 jnthn And only in a full collection
15:08 jnthn Well, either that or an old reference survives
15:09 timotimo there was a paste with a double free not too long ago; was that nwc or was it dogbert?
15:09 dogbert17 jnthn, timotimo: I might finally have something: https://gist.github.com/dogbert17/6cb41a1dad22e7a80158ad8ee886bfe4
15:09 * dogbert17 or it might be useless junk
15:11 dogbert17 heh, the one I posted looks similar
15:12 jnthn Loks like the one nwc10 posted too
15:13 dogbert17 yeah, tried to debug lizmat's SEGV's that she's been complaining about
15:14 * dogbert17 notes that full collections might be more common now, at least on 32 bit
15:16 dogbert17 it can't be my fault can it? https://github.com/MoarVM/MoarVM/commit/18df52c1d472fd176c73f7174df59ac0a477a67c
15:17 timotimo no, don't think so
15:17 timotimo i mean
15:17 timotimo even if your change caused full collections to finally happen during harness6, that just means we never gen2 collected during harness6 and it just ballooned bigger and bigger
15:18 dogbert17 that was indeed the problem I was suffering from before
15:18 timotimo oh, right
15:18 pyrimidine joined #moarvm
15:19 timotimo i hadn't realized it was during harness6
15:19 timotimo oh, but
15:19 timotimo on 64bit systems it used to be just fine
15:19 dogbert17 so now we have both ASAN and gdb data, what else can we do expect contemplating the output over a cup of coffee or beer
15:20 dogbert17 s/expect/except/
15:21 timotimo i haven't looked closely enough; we know what kind of object has been double-cleared, right?
15:33 timotimo how many threads does that actually start, btw?
15:33 timotimo just the event loop thread, i expect?
15:34 dogbert17 there are 17 lines in the gdb output like [New LWP xxxxx]
15:35 dogbert17 I ran harness6 with TEST_JOBS=5
15:38 brrt joined #moarvm
15:39 timotimo i wonder if that's how it fork+execs the async processes?
15:53 dogbert17 tried a run with TEST_JOBS=4, worked like a charm. I usually run it with TEST_JOBS=2 which seems to work well
15:58 dogbert17 my $parser = TAP::Runner::Async.new(:$source, :@handlers, :$killed);
15:58 dogbert17 @working.push({ :$parser, :$session, :done($parser.waiter) });
15:58 dogbert17 next if @working < $!jobs;
15:58 dogbert17 await Promise.anyof(@working»<done>, $killed);
15:59 dogbert17 reap-finished();
16:20 pyrimidine joined #moarvm
16:25 timotimo so it only asplodes when the degree of concurrency increases?
16:29 dogbert17 i think so but that's speculation on my part
16:29 dogbert17 and it doesn't crash every run so its tricky to reproduce
16:55 dogbert17 got it again same gdb backtrace but MVM_dump_backtrace is totally different
17:00 dogbert17 219         method TOP($/) {         # first entry in MVM_dump_backtrace (TAP.pm #219)
17:00 dogbert17 220             make @<line>».made;
17:00 dogbert17 221         }
17:06 dogbert17 gist updated, https://gist.github.com/dogbert17/6cb41a1dad22e7a80158ad8ee886bfe4
18:11 zakharyas joined #moarvm
18:34 brrt joined #moarvm
18:50 agentzh joined #moarvm
21:16 agentzh joined #moarvm
21:18 zakharyas joined #moarvm
21:33 agentzh joined #moarvm
21:37 pyrimidi_ joined #moarvm
21:39 lizmat joined #moarvm

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