github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:58 Util joined 03:48 evalable6 left, linkable6 left, evalable6 joined 03:49 linkable6 joined 06:18 domidumont joined 06:31 frost-lab joined
nwc10 good *, #moarvm 06:52
07:58 sena_kun joined 09:04 zakharyas joined 09:06 Altai-man joined 09:09 sena_kun left 09:46 zakharyas left 09:53 patrickb joined 10:43 zakharyas joined
timotimo yo 10:48
jnthn morning o/ 10:51
Altai-man o/ 10:52
nwc10 \o 10:54
jnthn Awww...the snow we got yesterday has almost already melted
nwc10 ours is still here for now. but probably will be gone by this evening. 10:55
jnthn Thanks to having a terrace, I even get a private supply of snow now :) 10:56
11:02 patrickb left 11:31 patrickb joined
nine Anyone else also likes trudging on snow? :) 11:41
jnthn Yes, though I find it quickly tiring when it's deep or uphill (probably lack of proper footwear though) 11:42
nine That and pacing. The first time I went with snowshoes I was exhausted after about 10 steps... 11:45
That's acutally a good analogy for my in-process-precompilation failure. I always treated it like something where just a few final kinks needed working out which I could do with just one more push and a little sprint. A hundred of those and I was just empty. Should have treated it like the marathon it is. 11:51
lizmat nine++ perseverance 11:57
jnthn A lot of things are a lot more work that one likes to imagine at the start of them... 12:08
(new-disp, rakuast... :))
Altai-man Planning fallacy is around the most horrible cognitive issues. On the other hand, one step at a time can take you a lo-o-ong way. 12:10
jnthn I suspect if I enumerated up front what some of these things would take then a) it'd be wrong anyway, and b) it'd probably put me off getting started :) 12:13
It's not so much the overall goal, it's that there's always sub-problems along the way that are a bit trickier than expected 12:14
nine Like that little parametrics interning detour :D 12:27
13:05 lucasb joined 13:08 sena_kun joined 13:09 Altai-man left 13:35 zakharyas left
nine Is there any way at all to get from a Pointer to a real MVMObject via NativeCall? 13:43
jnthn What's meant by "real MVMObject"? 13:45
nine Something I can access like any other 6model object, i.e. use nqp::getattr on 13:46
I have an SpeshLogEntry is repr('CStruct') with a $.sf field and I'd like to access the static frame's spesh attribute 13:47
jnthn Oh...no
You'd have to write out CStruct reprs to mimic it 13:48
A static frame doesn't implement getattr anyway, though
nine not...yet
jnthn o.O
nine I did, but then I'd like SpeshStats to be a P6opaque based class, so I can store a lookup hash in there 13:49
jnthn OK, but...why?
nine Exploring the possibility of having parts of spesh implemented in HLL code. Most of all the optimizer 13:50
So I'd need a new op for getting at the StaticFrameSpesh's spesh_stats. 13:53
14:04 frost-lab left 14:54 patrickb left 14:55 patrickb joined 16:27 cog joined, cog left 16:28 cog joined 17:01 domidumont left 17:07 Altai-man joined 17:09 sena_kun left 18:21 domidumont joined 18:24 domidumont left
timotimo nine: perhaps try going via the vmevent subscription thing, which can turn it into a simpler structure and deliver it to your code 19:25
19:41 MasterDuke joined
nine timotimo: only if there's an actual spesh worker thread :) 19:48
21:05 Altai-man left 21:22 patrickb left 21:23 patrickb joined
timotimo ah, you're going to fully toss that out 21:29
jnthn I'm not quite sure trying to move *all* of spesh into HLL land is going to be especially feasible without quite some sacrifices - probably including a large increase in warm-up time 22:41
I know I've talked about there being too much stuff in the VM that's very specific to certain language features 22:42
But I was more imaging that the VM would retain a generic, teachable, layer, with stuff written in a HLL to "explain" the more involved features to it in optimizable terms (and on what conditions the optimizations hold up) 22:44
To take new-disp as one example, it means we get to toss out the multi dispatch cache, the invocation spec mechanism, the method cache, and spesh plugins, and replace them with one thing, and then write the logic that maps onto these in the HLL 22:45
I think there's more places we can do things like that 22:46
Moving the SSA calculation and optimization and bytecode generation and JIT out to HLL is possible but it's a hell of a lot of effort to effectively stand still 22:47
Because the HLL code implementing it will start out unoptimized, and then have to itself be optimized. We don't have AOT-ish things to avoid that yet. While today spesh causes no GC work, that'd not be true if it was in HLL. And even after we're optimized, we're still some way off being as efficient as C. 22:50
One especially strategic area to shrink the C is around all the stuff that call frames do 22:51
Exit handlers. State vars. Flags for whether we can `FIRST` yet. And potentially much more. 22:52
Those are all things that probably needn't be baked in
The whole frame introspection relationship with inlining is horribly fragile. We've gotten burned multiple times there. 22:53
We also have some weird scoping hacks in place for BEGIN-time evaluated things 22:55
There's no mechanism for a scope we're still working on, making us create huge throw-away frames at BEGIN time evaluation with all lexicals known so far 22:57
nine I think my main motivation for even thinking about spesh that way comes from simply wanting to be able to write unit tests easily...
jnthn Ah! 22:58
nine But yes, the sloooow start could be a killer. Unless of course, the HLL shinyness makes it simple to actually keep stats or even optimized code around.
jnthn Yeah, the more involved spesh gets, the more concerning that is
Though surely we can find ways to better test what we have 22:59
nine Being able to have spesh on other backends by just providing stat collection and deoptimization would be a nice bonus though
nine is off to bed now 23:00
jnthn Sleep well 23:02
I note libuv seems to have a good test suite, I wonder what harness they use
MasterDuke hm, deopt...i should give debugging that MVMSpeshCandidate another go sometime now that rr works. the whole reason was so we could throw away optimizations if they caused to many deopts
23:10 leont joined 23:13 patrickb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!