Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-05-08

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

All times shown according to UTC.

Time Nick Message
00:00 lizmat joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:24 lizmat joined #moarvm
06:08 lizmat joined #moarvm
06:19 Zoffix joined #moarvm
06:49 domidumont joined #moarvm
06:54 domidumont joined #moarvm
07:19 brrt joined #moarvm
07:34 zakharyas joined #moarvm
07:46 lizmat joined #moarvm
07:52 lizmat joined #moarvm
08:10 geekosaur joined #moarvm
08:11 geekosaur joined #moarvm
08:19 geekosaur joined #moarvm
08:25 geekosaur joined #moarvm
09:04 geekosaur joined #moarvm
09:08 geekosaur joined #moarvm
09:43 AlexDaniel joined #moarvm
10:00 stmuk joined #moarvm
10:16 geekosaur joined #moarvm
10:27 zakharyas joined #moarvm
10:49 colomon joined #moarvm
11:32 brrt joined #moarvm
11:32 praisethemoon joined #moarvm
12:09 stmuk_ joined #moarvm
12:14 geekosaur joined #moarvm
12:53 brrt joined #moarvm
12:57 geekosaur joined #moarvm
13:28 robertle joined #moarvm
15:06 brrt joined #moarvm
15:07 brrt good * #moarvm
15:08 brrt i've implemented hole-finding and it's doing all sorts of weird things
15:10 brrt which valgrind tells me is because i'm writing beyond my buffer
15:10 brrt actually, ASAN, wasn't using valgrind
15:21 timotimo that's good to know, though
15:21 timotimo imagine we had found this out after a year of production use
15:27 brrt heh, my code is much to brittle to work with a buffer overflow ????
15:27 timotimo so it doesn't crash, it just gives strange results, yeah?
15:33 brrt it does crash in fact
15:34 brrt but i've resolved the issue, i was using the wrong iterator value to index the list
15:42 timotimo ah
15:46 Geth ¦ MoarVM/even-moar-jit: ce585eea23 | (Bart Wiegmans)++ | src/jit/linear_scan.c
15:46 Geth ¦ MoarVM/even-moar-jit: Minor cleanliness improvement
15:46 Geth ¦ MoarVM/even-moar-jit:
15:46 Geth ¦ MoarVM/even-moar-jit: handle_requirements can be called process_tile, which is slightly
15:46 Geth ¦ MoarVM/even-moar-jit: more accurate, and doesn't need to modify the cursor, because
15:46 Geth ¦ MoarVM/even-moar-jit: we can just ignore any requirements.
15:46 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ce585eea23
15:46 Geth ¦ MoarVM/even-moar-jit: ed212e35d0 | (Bart Wiegmans)++ | 2 files
15:46 Geth ¦ MoarVM/even-moar-jit: Find live range holes
15:46 Geth ¦ MoarVM/even-moar-jit:
15:46 Geth ¦ MoarVM/even-moar-jit: Per Wimmer (2010), find 'holes' in live ranges (i.e. ranges within the
15:46 Geth ¦ MoarVM/even-moar-jit: live range in which the value is not defined). Strategy is to iterate
15:46 Geth ¦ MoarVM/even-moar-jit: backwards over all basic blocks and instructions. If a value is used,
15:46 Geth ¦ MoarVM/even-moar-jit: that means it must be live in the code preceeding it (otherwise the
15:46 Geth ¦ MoarVM/even-moar-jit: program is wrong). If a value is defined, that means it must be
15:46 Geth ¦ MoarVM/even-moar-jit: <…commit message has 15 more lines…>
15:46 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ed212e35d0
15:47 brrt hehe, i'm to noisy even for geth
15:47 brrt anyway, that fixes that, yay
15:47 timotimo i find that acceptable
15:48 ilmari[m] joined #moarvm
15:49 brrt minor design issue
15:51 brrt do I generalize the binary heap code in linear_scan for the management of live range holes
15:51 brrt we can do that easy
15:51 brrt or, do i use the existing list structure destructively, i.e. do i merge the holes into a sorted array of live range holes.
15:52 brrt (i need it to be able to answer 'gee, is this structure in a hole right now)
15:52 brrt or, do i not do that at all
15:53 brrt and simply iterate over the list of holes per live range whenever i want to find out if it's currently in a hole
15:57 timotimo i don't know what's at stake here
15:57 brrt performance, obviously
15:57 brrt and complexity
15:57 brrt and bugginess
15:57 brrt but i'm decommuting
16:14 domidumont joined #moarvm
16:32 Ven joined #moarvm
17:13 tbrowder joined #moarvm
17:41 Ven joined #moarvm
18:01 lizmat joined #moarvm
18:22 robertle joined #moarvm
18:23 Geth ¦ MoarVM: MasterDuke17++ created pull request #592: Add at_pos support for VMHash
18:23 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/592
18:41 Ven joined #moarvm
19:56 MasterDuke_ google offers $ rewards for integrating with their free fuzzing tool https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.html
20:14 nine .tell brrt "First make it work, then make it fast" can be an iterative game with even the new JIT that's there to be faster first having to work.
20:14 yoleaux nine: I'll pass your message to brrt.
21:09 lizmat where could I find more info on what "telemeh" means / does ?
21:12 brrt joined #moarvm
21:16 timotimo oh
21:16 timotimo i'm the only source on that
21:16 timotimo lizmat: any particular question?
21:16 lizmat is there a writeup about it somewhere ?
21:16 timotimo not really, no
21:17 timotimo it basically just can spit out little status messages with tiny bits of extra data at a very high speed
21:17 timotimo and with high accuracy
21:17 timotimo because instead of asking a clock of some kind, it just reads the "number of cycles elapsed since some point near the beginning of the process" register out of the CPU
21:17 timotimo that's, sadly, why it's got problems on architectures besides x86
21:17 timotimo and also, it's not in older compilers
21:18 lizmat ok, I'll digest
21:18 timotimo it's also thread-safe, much like the other profiler absolutely isn't :)
21:18 timotimo well, the other one is thread-safe in recording its stuff
21:19 timotimo but we don't have a safe way to get the data out at a certain point, because the other threads just keep changing the data while we're trying to collect ... or something :D
21:19 timotimo you can try looking at the telemeh log generated by any multithreaded thing
21:19 timotimo the idea is to eventually have a nice GUI-ish frontend that could let you analyze the log at a higher level
21:20 timotimo it's inspired by a product called "telemetry" by RAD Game Tools
21:25 lizmat thanks!
21:55 lizmat and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/05/08/2017-19-albatross_i/
21:56 timotimo oh, if i had known you'd put it up without much editing i would have formulated things better %)
21:57 lizmat timotimo: I did a *bit* of editing  :-)
21:59 timotimo yeah
22:00 timotimo i'm not sure we should say the other profiler "absolutely" isn't
22:00 timotimo it just fails pretty hard at the moment, but conceptually it can be made threadsafe with a bit of work
22:01 jnthn In theory it doesn't need that much work...it just needs the right work :)
22:01 jnthn (And a lot of care, 'cus the mechanism we could bust if we get it wrong is GC sync-up)
22:02 jnthn GC sync stuff *is* going to get a re-work in the not too distance future, however, as it's also quite inefficient
22:02 timotimo nice to hear. i wasn't very aware of trouble in that area
22:02 jnthn Well, it was always a factor, but previously the pricey FSA dominated
22:03 timotimo oh yes, and how :)
22:03 jnthn Now that's out of the way, this is the next biggest easily-observable overhead.
22:03 lizmat timotimo: rephrased it a bit
22:03 timotimo last time i looked, the FSA exploded during full-cleanup, i should look again tomorrow or so
22:03 * lizmat gets some sleep
22:04 timotimo have a good rest, lizmat!
22:04 timotimo and thanks for the weekly :)
22:04 jnthn ooh, midnight...I probably should too :)
22:04 jnthn 'night all
22:33 lizmat_ joined #moarvm
23:39 SmokeMachine joined #moarvm

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