00:00 lizmat joined 01:48 ilbot3 joined 04:24 lizmat joined 06:08 lizmat joined 06:19 Zoffix joined 06:49 domidumont joined 06:54 domidumont joined 07:19 brrt joined 07:34 zakharyas joined 07:46 lizmat joined 07:52 lizmat joined 08:10 geekosaur joined 08:11 geekosaur joined 08:19 geekosaur joined 08:25 geekosaur joined 09:04 geekosaur joined 09:08 geekosaur joined 09:43 AlexDaniel joined 10:00 stmuk joined 10:16 geekosaur joined 10:27 zakharyas joined 10:49 colomon joined 11:32 brrt joined, praisethemoon joined 12:09 stmuk_ joined 12:14 geekosaur joined 12:53 brrt joined 12:57 geekosaur joined 13:28 robertle joined 15:06 brrt joined
brrt good * #moarvm 15:07
i've implemented hole-finding and it's doing all sorts of weird things 15:08
which valgrind tells me is because i'm writing beyond my buffer 15:10
actually, ASAN, wasn't using valgrind
timotimo that's good to know, though 15:21
imagine we had found this out after a year of production use
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?
brrt it does crash in fact 15:33
but i've resolved the issue, i was using the wrong iterator value to index the list 15:34
timotimo ah 15:42
Geth MoarVM/even-moar-jit: ce585eea23 | (Bart Wiegmans)++ | src/jit/linear_scan.c
Minor cleanliness improvement

handle_requirements can be called process_tile, which is slightly more accurate, and doesn't need to modify the cursor, because we can just ignore any requirements.		 15:46
MoarVM/even-moar-jit: ed212e35d0 | (Bart Wiegmans)++ | 2 files
Find live range holes

Per Wimmer (2010), find 'holes' in live ranges (i.e. ranges within the live range in which the value is not defined). Strategy is to iterate backwards over all basic blocks and instructions. If a value is used, that means it must be live in the code preceeding it (otherwise the program is wrong). If a value is defined, that means it must be ... (15 more lines)
brrt hehe, i'm to noisy even for geth 15:47
anyway, that fixes that, yay
timotimo i find that acceptable
15:48 ilmari[m] joined
brrt minor design issue 15:49
do I generalize the binary heap code in linear_scan for the management of live range holes 15:51
we can do that easy
or, do i use the existing list structure destructively, i.e. do i merge the holes into a sorted array of live range holes.
(i need it to be able to answer 'gee, is this structure in a hole right now) 15:52
or, do i not do that at all
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:53
timotimo i don't know what's at stake here 15:57
brrt performance, obviously
and complexity
and bugginess
but i'm decommuting
16:14 domidumont joined 16:32 Ven joined 17:13 tbrowder joined 17:41 Ven joined 18:01 lizmat joined 18:22 robertle joined
Geth MoarVM: MasterDuke17++ created pull request #592:
Add at_pos support for VMHash		 18:23
18:41 Ven joined
MasterDuke_ google offers $ rewards for integrating with their free fuzzing tool opensource.googleblog.com/2017/05/...r-and.html 19:56
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.
lizmat where could I find more info on what "telemeh" means / does ? 21:09
21:12 brrt joined
timotimo oh 21:16
i'm the only source on that
lizmat: any particular question?
lizmat is there a writeup about it somewhere ?
timotimo not really, no
it basically just can spit out little status messages with tiny bits of extra data at a very high speed 21:17
and with high accuracy
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
that's, sadly, why it's got problems on architectures besides x86
and also, it's not in older compilers
lizmat ok, I'll digest 21:18
timotimo it's also thread-safe, much like the other profiler absolutely isn't :)
well, the other one is thread-safe in recording its stuff
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
you can try looking at the telemeh log generated by any multithreaded thing
the idea is to eventually have a nice GUI-ish frontend that could let you analyze the log at a higher level
it's inspired by a product called "telemetry" by RAD Game Tools 21:20
lizmat thanks! 21:25
and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2017/05/08/...batross_i/ 21:55
timotimo oh, if i had known you'd put it up without much editing i would have formulated things better %) 21:56
lizmat timotimo: I did a *bit* of editing :-) 21:57
timotimo yeah 21:59
i'm not sure we should say the other profiler "absolutely" isn't 22:00
it just fails pretty hard at the moment, but conceptually it can be made threadsafe with a bit of work
jnthn In theory it doesn't need that much work...it just needs the right work :) 22:01
(And a lot of care, 'cus the mechanism we could bust if we get it wrong is GC sync-up)
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
jnthn Well, it was always a factor, but previously the pricey FSA dominated
timotimo oh yes, and how :) 22:03
jnthn Now that's out of the way, this is the next biggest easily-observable overhead.
lizmat timotimo: rephrased it a bit
timotimo last time i looked, the FSA exploded during full-cleanup, i should look again tomorrow or so
lizmat gets some sleep
timotimo have a good rest, lizmat! 22:04
and thanks for the weekly :)
jnthn ooh, midnight...I probably should too :)
'night all
22:33 lizmat_ joined 23:39 SmokeMachine joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!