Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-07-31

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

All times shown according to UTC.

Time Nick Message
01:30 deep-book-gk joined #moarvm
01:30 deep-book-gk left #moarvm
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:56 stmuk joined #moarvm
03:24 geekosaur joined #moarvm
03:25 geekosaur joined #moarvm
03:29 geekosaur joined #moarvm
05:46 brrt joined #moarvm
05:53 GK1wmSU joined #moarvm
05:54 GK1wmSU left #moarvm
05:57 brrt good * #moarvm
06:06 _GK1wmSU joined #moarvm
06:09 _GK1wmSU left #moarvm
06:42 brrt joined #moarvm
07:17 brrt one advantage of merging this week; i can start working on a stack-walker branch, without woryying about merging it in both
07:45 zakharyas joined #moarvm
08:04 brrt the dolphin folks have apparently written a JIT: bwiegmans-emkapp.dev.booking.com
08:04 brrt eh
08:04 brrt wrong paste
08:04 brrt https://dolphin-emu.org/blog/2017/07/30/ubershaders/
08:18 vendethiel- joined #moarvm
08:44 jnthn Moarning, #moarvm
08:45 brrt moarning jnthn
08:52 robertle joined #moarvm
09:11 ilmari brrt: they always had the JIT shader compiler, AIUI. they wrote a whole GPU emulator as a shader as well because the JIT latency was unacceptable
09:13 brrt well, that's what makes it a JIT compiler, otherwise it's just a compiler, innit
09:13 brrt :-)
09:13 brrt but it is really really cool work nevertheless
09:14 robertle joined #moarvm
09:14 brrt it's completely irrelevant to me since i own a wii and wii u
09:14 brrt but really cool
09:21 vendethiel joined #moarvm
09:25 Geth ¦ MoarVM: 68031489de | (Jonathan Worthington)++ | src/6model/reprs/P6opaque.c
09:25 Geth ¦ MoarVM: Spesh matches on exact types, so MI is no problem.
09:25 Geth ¦ MoarVM:
09:25 Geth ¦ MoarVM: With slots it is because they are unpredictable in the face of
09:25 Geth ¦ MoarVM: subclasses given MI. But when matching on an exact type and getting
09:25 Geth ¦ MoarVM: the offset for it, as spesh does, then it's safe.
09:25 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/68031489de
09:49 timotimo it's only the jit latency if you consider the code on the gpu to be the target, which i'd claim it isn't
09:51 timotimo because it's the gpu driver that takes ages to turn the glsl (or hlsl on directx) into whatever internal machine-code-like stuff the gpu uses
09:53 ilmari they have to JIT the TEV config to glsl first
09:53 timotimo right, but that's probably the faster step; i might have to re-read
09:54 timotimo hm, looks like you're right, the wording is a tiny bit misunderstandable
10:01 vendethiel- joined #moarvm
10:06 dogbert17 jnthn: dunno if it ties in with your current work, but of the two MoarVM related bugs found during the weekend, I reported one as a MoarVM issue and the other might have already been solved by timotimo :)
10:07 jnthn This one: https://github.com/MoarVM/MoarVM/issues/620 ?
10:09 dogbert17 yes, that's the reported one :)
10:10 dogbert17 the other is hidden here, https://gist.github.com/dogbert17/e23c3340c7d9930ec219f8eda3feb18f, but can be turned into a report should you so desire
10:14 jnthn Yeah, that's worth a MoarVM issue also
10:18 dogbert17 jnthn: done https://github.com/MoarVM/MoarVM/issues/622
10:34 jnthn m: say 220 / 225
10:34 camelia rakudo-moar 3e078d: OUTPUT: «0.977778?»
10:34 vendethiel joined #moarvm
10:47 Geth ¦ MoarVM: 682b8c8694 | (Jonathan Worthington)++ | 5 files
10:47 Geth ¦ MoarVM: Speed up attribute reads during invocation.
10:47 Geth ¦ MoarVM:
10:47 Geth ¦ MoarVM: By caching the offsets when it's a P6opaque (in reality, it pretty
10:47 Geth ¦ MoarVM: much always is) so we don't have to call get_attribute. Profiling
10:47 Geth ¦ MoarVM: showed that about 3% of CORE.setting instructions during compilation
10:47 Geth ¦ MoarVM: go on the get_attribute calls in these functions; a profile after the
10:47 Geth ¦ MoarVM: change shows a drop of around 5 billion instructions when compiling
10:47 Geth ¦ MoarVM: CORE.setting, or about 2.2%.
10:47 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/682b8c8694
10:47 Geth ¦ MoarVM: e3c44fc042 | (Jonathan Worthington)++ | src/core/oplist
10:47 Geth ¦ MoarVM: Document the various op adverbs.
10:47 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e3c44fc042
11:04 Geth ¦ MoarVM: 099764bd92 | (Jonathan Worthington)++ | 3 files
11:04 Geth ¦ MoarVM: Avoid spesh log function call when not logging.
11:04 Geth ¦ MoarVM:
11:04 Geth ¦ MoarVM: The static inline does the check quickly, saving the overhead of the
11:04 Geth ¦ MoarVM: function call in the case we aren't doing spesh logging at this point.
11:04 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/099764bd92
11:05 lizmat jnthn: possibly related to this, do you have a clue why "is default()" is not honoured on attributes ?
11:06 jnthn lizmat: No, no idea why that'd be
11:06 lizmat m: class A { has $.a is default(42) }; use nqp; dd nqp::getattr(nqp::create(A),A,q/$!a/)
11:06 camelia rakudo-moar 3e078d: OUTPUT: «Any $!a = Any?»
11:07 lizmat it's happening at a very low level
11:07 lizmat m: class A { has $.a is default(42) }; use nqp; dd nqp::getattr(nqp::create(A),A,q/$!a/).VAR.default
11:07 camelia rakudo-moar 3e078d: OUTPUT: «42?»
11:09 jnthn Probably that it isn't setting the value into the container that then later gets cloned
11:09 jnthn Just updating the container descriptor won't suffice
11:09 jnthn Note that the variable one does an assignment into the container
11:10 lizmat I've lost you
11:11 lizmat I just wanted to show that the descriptor *is* set up correctly
11:11 jnthn Yes, it is, my point was that this isn't actually very important.
11:11 lizmat but something is stoking an Any into it
11:11 jnthn Because that's only for introspection by runtime
11:11 lizmat I think it's *very* important
11:11 jnthn You can think what you want, but I know how it works :P
11:12 jnthn The mechanism in both cases is that we clone a "prototype" Scalar
11:12 jnthn In Variable.pm where the var default trait is, we have this line:
11:12 jnthn # make sure we start with the default if a scalar
11:12 jnthn $var = $default if nqp::istype($what, Scalar);
11:13 jnthn That is not, however, taking place in the is default trait for Attribute
11:13 lizmat hmmmm
11:13 lizmat ok,
11:13 jnthn The question being, how we do it :)
11:13 jnthn Ah, right
11:13 jnthn Attribute has a $!auto_viv_container
11:14 jnthn So we need to make sure it ends up assigned into that
11:14 jnthn Ah, and it can be done in the Attribute default trait in traits.pm
11:14 lizmat ok, I will take it from there then  :-)
11:15 jnthn The solution will be something like adding:
11:15 jnthn my \cont := $attr.container;
11:16 jnthn nqp::assign(cont, $defualt) if nqp::istype(cont, Scalar)
11:16 jnthn or
11:16 jnthn my $cont := $attr.container;
11:16 jnthn $cont = $defualt if nqp::istype(cont, Scalar)
11:16 jnthn Saves an nqp op and should be equally good code :)
11:16 jnthn (Saves using one, I mean; it'll generate nqp::assign underneath)
11:17 lizmat ack, lemme try  :-)
11:20 Geth ¦ MoarVM: 9720819b96 | (Jonathan Worthington)++ | src/core/frame.c
11:20 Geth ¦ MoarVM: Reduce duplication and simplify logic in invoke.
11:20 Geth ¦ MoarVM:
11:20 Geth ¦ MoarVM: By making the codepaths where we have a specialization already and
11:20 Geth ¦ MoarVM: where we don't have a specialization share most of their code. This
11:20 Geth ¦ MoarVM: also gets rid of the found_spesh flag.
11:20 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9720819b96
11:20 jnthn Meanwhile, lunch :)
11:20 jnthn bbiab
11:32 nine ssh cmsfrontend-public.atikon.io
11:34 timotimo nine: wrong channel again?
11:35 nine Yeah, brane didn't register, that this doesn't really look like normal shell output.
11:36 nine Woke up at 5 in the morning because the roller shutters didn't close and I can't sleep when it's too much light. Turns out my WiFi router which hosts the controller software has got a broken flash or something. Rebooted into an openWRT version that shouldn't have been on that thing for half a year.
11:37 timotimo whoops
11:38 timotimo i, too, can't sleep when there's light; even a little will prevent me from falling asleep, and a bit more than that will easily wake me up
11:46 stmuk we are using a cheap car sunshade to block summer light from the window
11:47 timotimo my shutters are human-powered
11:54 nine Well sometimes that is an advantage indeed :)
12:04 * jnthn back
12:05 brrt \o
12:06 jnthn Darn it. Some update seems to have screwed things up such that when the auto-logout-because-you-were-inactive thing happens, you just get a black screen and, mouse cursor moving aside, a totally unresponsive system :/
12:07 jnthn Occasionally get hangs coming out of hibernate mode too.
12:07 jnthn Don't miss the Windows dev expereince at all but I miss the stability :P :P
12:07 brrt are you on linux now?
12:07 timotimo auto-logout, you mean suspend to ram or just a screen locker?
12:08 jnthn brrt: yeah
12:08 jnthn timotimo: Just screen locker :/
12:08 timotimo that's not nice
12:08 brrt part of 'stability' is dealing with the bugs you know rather than the bugs that you don't though :-P
12:08 timotimo though there's a variety of screen lockers to choose from :D
12:08 timotimo what kind of DE are you running?
12:09 jnthn timotimo: Whatever Ubuntu comes without of the box :)
12:09 timotimo oh
12:09 brrt i always feel like windows is less stable (in my hands) than windows is, but i think i'm ignoring a lot of things that you'd notice :-)
12:09 brrt eh, second windows should be linux :-P
12:09 jnthn tbh I don't even care what it is, in so far as I use the command line + chromium and that's about it :P
12:09 timotimo the ubuntu devs have been brewing their own X replacement for a while that's not gotten any traction outside of ubuntu where you're basically forced to use it :P
12:10 ilmari did they actually switch to it by default?
12:10 timotimo i think they very recently dropped mir development
12:10 brrt ymmv, but you might find fedora to be more polished.
12:10 brrt adn then agian, you might not care
12:12 ilmari has fedora switched to wayland yet?
12:12 jnthn Wow, another 3 billion instructions off as a result of the previous two commits :)
12:14 timotimo i'm still running xorg, but i believe if you install fedora regularly you'll get a gnome3 on wayland now
12:14 timotimo i started out with the xfce4 spin
12:14 * brrt wonders how many bitcoin can be mined with all the instructions jnthn has saved
12:14 brrt yeah, wayland is standard by now
12:14 brrt i notice a very occasional bug in Qt integration, but other than that
12:16 jnthn Current project: trying to heap-allocate frames that'll obviously get promoted there anyway
12:16 nine jnthn: so you're already outdating the blog post you just wrote?
12:16 brrt and how will you know how obvious that is?
12:16 jnthn Yeah :P
12:17 jnthn brrt: Well, my Plan A is to mark ops that force it (done) and have the bytecode validation note if it seems such an op (done), and then use that flag (doing it now)
12:17 jnthn I think spesh can in the future try to be more accurate
12:29 jnthn Boom, sigsegv
12:33 * lizmat misses RabidGravy
12:35 [Coke] soooo much burnout since y2k.
12:43 jnthn Hm, nearly got it to work, just some SEGV in a few spectests
12:48 timotimo you must know how much it costs to promote frames during core setting compile?
12:48 jnthn About 2.15% of CPU cycles
12:49 jnthn ho, interesting
12:49 jnthn Was hyper.t flappy?
12:49 jnthn Just tracked down the SEGV in it and...it wasn't anything new
12:49 jnthn Just uncovered
12:51 Zoffix wasn't a flopper for me
12:53 timotimo curious
12:54 timotimo i'm going to look closer at the high occurence of memset during Terminal::Print thing
12:57 jnthn I guess it coulda shown up in various places
12:58 jnthn Plus a second one I just found
13:00 Geth ¦ MoarVM: ae86ef0620 | (Jonathan Worthington)++ | src/core/frame.c
13:00 Geth ¦ MoarVM: Ensure allocd_work and allocd_env are zeroed.
13:00 Geth ¦ MoarVM:
13:00 Geth ¦ MoarVM: Otherwise they may be junk which will break OSR by causing it to
13:00 Geth ¦ MoarVM: try and free a bogus pointer.
13:00 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ae86ef0620
13:00 Geth ¦ MoarVM: a539212457 | (Jonathan Worthington)++ | src/spesh/log.c
13:00 Geth ¦ MoarVM: Handle log getting full between making entries.
13:00 Geth ¦ MoarVM:
13:00 Geth ¦ MoarVM: This could occasionally lead to a NULL pointer dereference.
13:00 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a539212457
13:04 ggoebel joined #moarvm
13:05 jnthn Seems I've a working patch to allocate on the heap straight off in some cases
13:05 jnthn callgrind is measuring its worthiness
13:05 jnthn Seems to knock some seconds off spectest though
13:10 zakharyas joined #moarvm
13:13 timotimo nice
13:15 jnthn The callgrind takes ages but at least it takes less ages than it used to :)
13:16 timotimo fewer ages*
13:16 timotimo :P
13:16 jnthn *groan*
13:21 jnthn So I realized over the weekend that there's actually a much simpler solution to getting most of our Perl 6 pass-a-thing-in-a-container dispatches and inlines back
13:21 jnthn Than the super-clever alias analysis
13:22 jnthn Which we'll want some of anyway for doing EA but still
13:22 jnthn We know the type tuples, including deconts, of our callees
13:23 jnthn We can also stash those away at the callsite too
13:23 jnthn Then, provided it's stable, we can trace back from the args to where there's something that fetches the arg and, provided it's a deopt-able instruction, insert a decont + guard there
13:24 jnthn The decont would then be subject to the fetch lowering
13:24 jnthn And the guard a normal STable one
13:25 * jnthn sets about figuring out the details of that
13:27 jnthn Also, going to make decont a deoptonepoint so we get guards on it
13:27 jnthn Which will also get us some Perl 6 spesh mojo back
13:27 jnthn I like how this guard splitting also naturally means we only enforce the content of the container when we care, whereas before we always did it
13:43 jnthn Oh dear. Things get *worse* after my patch. Hmm.
13:47 jnthn Oh, hmm
13:47 jnthn Of course, since I marked exception
13:47 jnthn But there's loads of code like
13:47 jnthn nqp::die(...blah...) unless $foo
13:48 jnthn hm, though I forgot to mark die
13:49 lizmat .oO( I always use die to mark )
13:50 lizmat or dye rather :-)
13:52 dogbert17 jnthn: yes hyper.t was flappy
13:52 jnthn dogbert17: OK, hopefully no longer on HEAD :)
13:55 dogbert17 :)
13:58 dogbert17 TBH, I've only had it flop once or twice
14:04 lizmat http://news.perlfoundation.org/2017/07/grant-extension-approved-perl-.html  # jnthn++
14:04 Zoffix w00t \o/ jnthn++
14:05 timotimo cool
14:07 * jnthn is quite relieved by this
14:09 jnthn Some weeks back I got told it was approved. So I didn't take on $other-work so I could focus on Perl 6 for the summer and dug in. Then got a mail some days later saying some legal process needed to be completed first before the approval could be posted. I figured eh, I'll just get on with stuff, guess it's just a couple more days. Took some weeks in the end. TPF++ for sorting it out, anyways.
14:12 Geth ¦ MoarVM: c7be0ee7f5 | (Jonathan Worthington)++ | src/spesh/stats.c
14:12 Geth ¦ MoarVM: Fix a typo.
14:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c7be0ee7f5
14:12 Geth ¦ MoarVM: c5be4dd59a | (Jonathan Worthington)++ | 3 files
14:12 Geth ¦ MoarVM: Move checking part of force_to_heap into an inline
14:12 Geth ¦ MoarVM:
14:12 Geth ¦ MoarVM: Since quite often - increasingly so if we allocate directly on the
14:12 Geth ¦ MoarVM: heap - the answer will be that it's already promoted.
14:12 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c5be4dd59a
14:12 jnthn I think more checks were part of the added cycles, but there's no getting away from the other numbers: we really are causing a lot more GC
14:13 jnthn So a static approach isn't going to fly, I don't think
14:13 jnthn I guess takeclosure must happen more conditionally in NQP than I expected
14:13 jnthn I guess it makes sense given it can flatten more aggressively
14:14 jnthn Guess I'll try a dynamic approach :)
14:15 brrt that smells like it's going to want a counter
14:15 jnthn Yeah
14:15 jnthn Nice thing is, we already have one
14:15 jnthn An invocations counter
14:16 jnthn So if I also count in the heap promotion code
14:16 jnthn I guess we can stop counting once the frame is specialized also
14:22 jnthn oh, even easier, just latch once it's promoted
14:27 jnthn Mmmm...fresh watermelon jice
14:27 jnthn *juice
14:32 timotimo so ... water? :)
14:33 dogbert17 tried to check out MoarVM master and rebuild it. It worked but when running 'perl Configure.pl --gen-moar --gen-nqp --backends=moar' I get SEGV's
14:33 travis-ci joined #moarvm
14:33 travis-ci MoarVM build failed. Jonathan Worthington 'Move checking part of force_to_heap into an inline
14:33 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/259383987 https://github.com/MoarVM/MoarVM/compare/a5392124579d...c5be4dd59a61
14:33 travis-ci left #moarvm
14:33 jnthn Hm, maybe my pulling apart of stuff into commits didn't quite go to plan :)
14:34 dogbert17 :)
14:34 jnthn Not sure why htough
14:35 dogbert17 perhaps one important change didn't make it through
14:36 jnthn Dunno. After latest round of changes I also see segv
14:38 * dogbert17 tries ASAN
14:38 jnthn oh duh duh duh
14:39 dogbert17 ASAN:SIGSEGV
14:39 dogbert17 =================================================================
14:39 dogbert17 ==9221== ERROR: AddressSanitizer: SEGV on unknown address 0x00000006 (pc 0xb566b9a0 sp 0xbfdf2070 bp 0xbfdf6328 T0)
14:39 dogbert17 AddressSanitizer can not provide additional info.
14:39 dogbert17 #0 0xb566b99f in MVM_interp_run /home/dogbert/repos/rakudo/nqp/MoarVM/src/core/interp.c:304
14:39 dogbert17 #1 0xb59d2d3a in MVM_vm_run_file /home/dogbert/repos/rakudo/nqp/MoarVM/src/moar.c:331
14:39 jnthn I somehow got the conditional totally backwards
14:40 ilmari[m] joined #moarvm
14:40 * dogbert17 has done that more times than I want to admit
14:40 Geth ¦ MoarVM: 4a92691268 | (Jonathan Worthington)++ | src/core/frame.h
14:40 Geth ¦ MoarVM: Correct inverted conditional.
14:40 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4a92691268
14:43 jnthn timotimo: It turns out the juice is a pink/red color and quite sweet :)
14:44 dogbert17 and .... the SEGV has mysteriously disappeared :)
14:47 nine Amazon++ # sending a replacement for my faulty router without making a fuzz about me running openWRT on it.
14:48 jnthn Hm, wallclock numbers aren't immediately encouraging after my change, but could be noise. Also, increasing heat in the office thanks to heatwave outside. :/
14:48 nine Though I had some funny 10 minutes on the phone with the helpdesk lady how faught with their system which needed confirmation of my payment data but did not accept the correct one (despite amazon.com showing the exact same numbers)
14:49 lizmat which is why I run my spectest bench at 5am in the morning or so   :-)
14:50 ilmari as opposedt to 5am in the afternoon or 5pm in the morning?
14:51 jnthn Well, callgrind can give me better numbers
14:51 jnthn Much of what I'm doing is within noise so far as wallclock goes
14:55 jnthn ah, a chrome tab was hungry
14:55 * jnthn offers his latest to callgrind
14:55 lizmat ilmari: ah, indeed    5 in the morning  :-)
14:56 ilmari lizmat: am/pm sucks, just use 24h time :)
14:56 lizmat ok, I run my spectests at 0500  :-)
14:57 ilmari I remember seeing "02:30 pm" somewhere recently, which is just weird
14:57 ilmari who the hell uses leading zeros with 12h time?
15:10 brrt joined #moarvm
15:12 travis-ci joined #moarvm
15:12 travis-ci MoarVM build passed. Jonathan Worthington 'Correct inverted conditional.'
15:12 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/259395289 https://github.com/MoarVM/MoarVM/compare/c5be4dd59a61...4a9269126861
15:12 travis-ci left #moarvm
15:13 jnthn yay :)
15:13 dogbert17 callgrind?
15:13 jnthn No, the travis report agreeing with the earlier fix
15:13 jnthn callgrind still grinding
15:13 jnthn I'm already working on the next thing while it does so :)
15:16 dogbert17 saving even more cycles?
15:19 jnthn Well, that's the eventual goal, for now just getting spesh to propagate information about type tuples seen in callees back to their caller's callsite, so we can do better optimization
15:21 jnthn This is more for Rakudo than NQP, though, so will be looking less at CORE.setting compilation during it
15:31 MasterDuke joined #moarvm
15:32 japhb timotimo: What is "the high occurence of memset during Terminal::Print thing"?
15:33 japhb jnthn++  # Memory use and performance hacking
15:34 jnthn Gahhh. :( Latest version of the frame promotion changes are even worse.
15:35 * lizmat knows that feeling
15:35 lizmat :-(
15:40 MasterDuke i've been experimenting with making MVMString.num_graphs an MVMuint64 (instead of MVMuint32)
15:40 yoleaux 27 Jul 2017 18:37Z <AlexDaniel> MasterDuke: I'm going to take a nap now, but… bots are broken :) Feel free to investigate: https://github.com/perl6/whateverable/issues/24#issuecomment-318444466
15:40 yoleaux 27 Jul 2017 18:38Z <AlexDaniel> MasterDuke: well, not completely broken, but a chance of getting MoarVM panic when you do something is really high.
15:40 MasterDuke however, there are lots of places where some MVMint64 value is compared against num_graphs (or something similar, like a substring length)
15:41 MasterDuke i supposing introducing an MVMint128 would not be the preferred solution
15:45 jnthn No.
15:49 jnthn Ok, with thresholds tweaked the wallclocks look better
15:49 MasterDuke right, i'm thinking that a bunch of checks will get/have to go away at the moar level (e.g., if (length < 0) { MVM_exception_throw_adhoc() } else { })
15:50 MasterDuke and such a check would have to be moved up to the nqp/rakudo level
15:50 jnthn Uh
15:50 jnthn No
15:50 jnthn I mean, we have to do checks at VM level to make sure we don't go writing over the ends of buffers and stuff
15:51 MasterDuke well, i mean convert the MVMint64 parameter to an MVMuint64
15:51 jnthn Oh
15:51 jnthn Yeah, that we can do
15:51 jnthn Though
15:52 jnthn A lot of the reason we have MVMint64 is because we receive the value in an i64 register
15:52 jnthn And so it's passed that way from the interp 'cus that's how the interp sees it
15:52 MasterDuke yeah, and uints aren't handled well
15:52 MasterDuke which was also something i had tried to start on a fix for, but didn't make much progress
15:53 MasterDuke but Zoffix has also mentioned he might work on it
15:54 MasterDuke anyway, afk for probably until tomorrow, but will backlog if there are any further thoughts/comments
16:08 brrt joined #moarvm
16:29 jnthn Urgh, no, things are even worse. Doesn't make much sense. :/
16:29 nwc10 step away from the keyboard and check the stock level in the beer fridge?
16:29 jnthn Either the predictor is really wrong, or we must have frames that start out getting promoted a lot and then cease to be
16:29 nwc10 any test cases that the rest of us can play with?
16:34 Geth ¦ MoarVM/frame-heap-prediction: 2184a05861 | (Jonathan Worthington)++ | 3 files
16:34 Geth ¦ MoarVM/frame-heap-prediction: Allocate frames on heap that will need promotion.
16:34 Geth ¦ MoarVM/frame-heap-prediction:
16:34 Geth ¦ MoarVM/frame-heap-prediction: By trying to use existing promotions as an indicator. This somehow
16:34 Geth ¦ MoarVM/frame-heap-prediction: seems to end up doing *worse* for the CORE.setting build, however
16:34 Geth ¦ MoarVM/frame-heap-prediction: it looks like it helps `make spectest` wallclock time a bit (though
16:34 Geth ¦ MoarVM/frame-heap-prediction: it's all within noise).
16:34 Geth ¦ MoarVM/frame-heap-prediction: review: https://github.com/MoarVM/MoarVM/commit/2184a05861
16:34 jnthn There's waht I tried
16:34 jnthn Off home now
17:06 robertle joined #moarvm
18:40 praisethemoon joined #moarvm
18:40 praisethemoon joined #moarvm
18:41 timotimo japhb: profiling moarvm while running the examples from that library gives a surprising amount of time spent in memset
18:46 nwc10 jnthn: frustratingly ASAN makes no comment
18:47 nwc10 but I'm guessing that wasn't the problem. It was "why is this slower?"
18:47 timotimo yeah, it was
18:48 timotimo we might want to debug-printf stats about what exact frames used to get promoted (how often) and which frames are now being pre-promoted and post-promoted
18:49 nwc10 oh gosh it's fast when you build O2 rather than ASAN :-)
20:04 japhb timotimo: Interesting.  Maybe because of all the 2D-array slinging or the string joinging or the I/O?  There's a lot of copying between backing buffers and the screen grid, and then outputting massive strings of grid updates to the TTY.
20:05 japhb (Terminal::Print::Grid should show a fair number of low-level and high-use actions.)
20:05 japhb If you're seeing it in the particle-rendering code, that gets even more interesting, because there's a particle-to-grid-cell collation pass.
21:04 mtj_ joined #moarvm
21:22 lizmat and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2017/07/31/2017-31-moar-smaller/
22:35 timotimo cool. fprinting the numbers that take part in the "if" for resolving annotations makes the "use of uninitialized value" messages go away
23:29 bisectable6 joined #moarvm
23:29 quotable6 joined #moarvm
23:29 committable6 joined #moarvm
23:29 evalable6 joined #moarvm
23:29 coverable6 joined #moarvm
23:29 greppable6 joined #moarvm
23:29 unicodable6 joined #moarvm
23:29 bloatable6 joined #moarvm
23:29 benchable6 joined #moarvm
23:29 statisfiable6 joined #moarvm
23:51 sivoais joined #moarvm
23:52 https_GK1wmSU joined #moarvm
23:55 https_GK1wmSU left #moarvm

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