Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-03-20

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

All times shown according to UTC.

Time Nick Message
00:07 MasterDuke `loop (my int $i = 1; $i <= 10_000_000; $i = $i + 1) { my uint64 $a = 2**64-1; my int64 $b = 2**62; my int64 $c = -2**63 }; say now - INIT now` took an average of about 3.5s before, 3.4s after
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
06:27 domidumont joined #moarvm
06:34 domidumont joined #moarvm
06:39 brrt joined #moarvm
06:40 brrt good * #moarvm
06:55 samcv good * brrt
07:04 domidumont joined #moarvm
07:42 brrt joined #moarvm
08:22 zakharyas joined #moarvm
08:30 brrt ohai samcv
08:30 samcv hello
08:31 brrt i've settled on making spills explicit graph-reducing steps (so that they work with the topological sort), but i'm not 100% positive that i'm doing it correctly yet
08:32 samcv where in MoarVM is this code so i can look at it
08:32 brrt if you check out the even-moar-jit branch, it's in src/jit/linear_scan.c
08:33 brrt in the function prepare_arglist_and_call
08:56 samcv kk
08:56 brrt :-)
08:56 brrt it's arguably evil code
08:57 brrt well, or 'rather complex'
10:47 Ven joined #moarvm
11:00 KDr2_c joined #moarvm
11:08 * brrt back
12:26 domidumont joined #moarvm
12:53 brrt so.. i've done more thinking; the trick in topological sort is that all nodes are eventually handled
12:54 brrt or si that all edges? anyway
12:55 brrt so a node (= register) can be blocked due to one of those reasons: it needs to be moved to another register, it needs to be spilled to memory, it needs to be placed on stack
12:57 brrt and there's two reasons a register's value may need to be copied: a): because it needs to be in another register for the arg list, or b): because it's used by CALL as an explicit register
12:57 brrt so any of these 'blocks' should add to the counter, and any of these operations should decrement
13:22 spebern joined #moarvm
13:30 domidumont joined #moarvm
13:59 timotimo so, actually ... would i want to implement a bytecode-level debugger inside moar, or add more features to moar-gdb.py until it's useful for bytecode-level debugging ...
14:00 jnthn Likely the first :)
14:00 brrt joined #moarvm
14:00 timotimo seems like more work :P
14:00 jnthn Doing stuff right often is ;P
14:00 timotimo especially since if you're a plugin for gdb you can also immediately continue C-level debugging if you're doing internals hacking
14:00 timotimo though tbh our ops are usually not terribly buggy :P
14:00 timotimo just the composition of ops
14:01 brrt joined #moarvm
14:18 timotimo of course, i'm already supposed to give spesh line-annotations. can use those for the debugger, too. not just the line-coverage tool
14:29 Ven joined #moarvm
14:33 brrt joined #moarvm
15:10 domidumont joined #moarvm
15:15 brrt joined #moarvm
15:30 timotimo right now i'm running a benchmark for join and \n and \n\r and unrelated control characters
15:31 Ven joined #moarvm
16:09 brrt joined #moarvm
16:10 brrt yeah, it is a bunch of work
16:46 timotimo hm, well, the benchmark proved uninteresting
16:46 timotimo but i probably measured an uninteresting workload
16:48 timotimo https://gist.github.com/timo/7477f7cecfc2a0c5bf8096ac98499740
16:48 timotimo i should probably put in a combining character at the beginning of one of these strings
16:57 agentzh joined #moarvm
17:11 agentzh joined #moarvm
17:15 timotimo this run will take a bit longer :|
17:22 timotimo all it does is get noisier the more elements i'm joining
17:48 dogbert17 joined #moarvm
18:14 domidumont joined #moarvm
20:14 domidumont joined #moarvm
20:15 nebuchad` joined #moarvm
20:18 harrow joined #moarvm
20:19 brrt joined #moarvm
20:23 japhb_ joined #moarvm
21:54 domidumont joined #moarvm

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