Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:07 reportable6 left 00:08 reportable6 joined 01:20 evalable6 left, linkable6 left 01:21 evalable6 joined 01:23 linkable6 joined 02:23 evalable6 left, sourceable6 left, notable6 left, bloatable6 left, statisfiable6 left, benchable6 left, committable6 left, nativecallable6 left, quotable6 left, releasable6 left, linkable6 left, nativecallable6 joined, evalable6 joined 02:24 quotable6 joined, releasable6 joined 02:25 bloatable6 joined, statisfiable6 joined 02:26 linkable6 joined, benchable6 joined, sourceable6 joined, notable6 joined, committable6 joined 02:30 japhb left 02:37 japhb joined 04:15 frost joined 06:06 reportable6 left, reportable6 joined 06:08 kjp left, codesections left 06:09 kjp joined 06:12 jnthn left, SmokeMachine left, jnthn joined, SmokeMachine joined 07:27 sena_kun joined
timo what can the fallback resolvers be used for? could this lazily load parts of the core setting perhaps? 07:47
nine It's the "a bit smarter" version of: github.com/rakudo/rakudo/blob/mast....nqp#L2886 08:01
timo oh my 08:05
sounds like it could be a nice impact for compilation time when this setup can be lazy like that
but i don't know how often this code actually runs and how many symbols it tends to see 08:06
nine Being smarter there can easily cut > 10 % off core settings compilation time, maybe even 20 %. That's according to my first attempt in the improved_wrapper_frames branch. 08:08
The other reason for doing this is, that while implementing such a fallback resolver is downright trivial in RakuAST, creating the old fashioned wrapper frame is not.
timo ah! :) 08:10
nine The caveat is, that apparently that last commit slows down setting compilation from ~35 to 42s here, even though we do not yet use those fallbacks. Do you have any idea how that could be the case? 08:12
timo huh 08:23
have you checked things like "suddenly nothing can be jitted any more" and such? 08:26
not sure why that would happen of course 08:27
nine It may actually be spesh related. Compilation times with disabled spesh are within .5s of each other 08:28
timo right, since resolvers try to get translated into spesh code, 08:39
something something etc etc
i must be missing the commit that actually uses the resolvers 08:43
oh, it's not moarvm duh
but i still dont see it
nine This would be it: github.com/rakudo/rakudo/commit/f6...db5ee3f96c 08:45
But that's the thing: the slow down happens in rakudo master where there is no fallback resolver
That commit is not even on rakuast proper yet. It's just my rakuast_wip 08:46
timo ah, in *master*
have you bisected to make sure it's actually your commits? 08:48
08:50 evalable6 left, linkable6 left, evalable6 joined 08:51 linkable6 joined
nine It's just that last one: 6822c790ce | Support fallback resolver in *getlex* 09:03
It's not JIT-related. Still see a 5s difference with JIT disabled 09:04
lizmat hmmm... I guess the reason I don't see that, is that hasn't been bumped yet 09:06
nine It's just in a branch
lizmat right... ok 09:09
*phew*
nine It's definitely still logging types of found lexicals. 09:24
Ooooh...but it's logging these types at the wrong offset! 09:25
Yep, that was it 09:30
timo wow how did that happen? 09:38
Nicholas decaf? 09:39
nine Since MVM_frame_find_lexical_by_name now can dispatch, we must run it after updating cur_op. MVM_spesh_log_type on the other hand must run before updating cur_op. Solution is to introduce a new MVM_spesh_log_type_at that takes an explicit bytecode offset 09:41
Nicholas is this bug likely to repeat if we add dispatch inside other API calls that didn't use to? 09:43
timo a-ha! 09:49
Nicholas: now that we have an op that uses dispatch and logging of results, others will just copypaste the right code :D 09:56
since rakuast won't be merged this week, will you replace the outer symbol lookup thing for compile-in-context in the master branch as well? :D 09:58
i know at least two raku users who would really be happy about faster compiles for their modules, but i'm not sure if this particular code path is hot for their use cases compared to compiling the core setting 10:03
jnthn Depends how much BEGIN-time stuff they do, I guess. 10:06
10:07 Altai-man joined
timo and how much implicit begin-time stuff happens on their behalf 10:07
also, o/ jnthn :) 10:08
jnthn Well, yeah, there's role bodies
timo how about nativecall? there's the compilation of the optimized bodies, but i think it's optimized to happen in just one context all at once? 10:09
jnthn I think the optimized body compilation went away totally in favor of a new-disp-based approach? 10:23
timo oh, cool 10:26
nine Yes, it did. 10:35
jnthn Nice to see new-disp feature in the lexical lookup failover too :) 10:36
Seems we're getting as much out of it as I hoped :)
nine++ for doing much of the heavy lifting 10:37
nine jnthn: about BEGIN-time stuff... Most of that seems to work fine now on RakuAST. One problem I've come across yesterday though is that packages are composed too late, which breaks e.g. BEGIN time checking of types since their MRO isn't set up at that point. So far I have failed to make it compose earlier though. There are problems like attributes getting attached multiple times.
As always, the hard part seems to be timing 10:38
jnthn nine: Indeed, that's part of what I was trying to tease out with the parse time / begin time (and other times) stuff 10:45
timo timing and the three hardest problems in computer science are naming things and off by one errors
jnthn :P
I suspect the attachment wants to happen as a begin time action 10:46
nine Two insights into RakuAST: the difficult problems are always in the timing. And if you have no idea where to find something, it's in src/Raku/ast/scoping.rakumod
Which is weird.... attaching attributes and methods should not happen in attach but in PERFORM-BEGIN. But then, that's just the naming problem again. 10:47
jnthn That that in general, while AttachTarget is probably about right, the Attaching is wrong.
Because we can attach many times, whereas in reality we want to do it at The Right Time
And once
Geth MoarVM/fallback_resolver: 49d9f5e071 | (Stefan Seifert)++ | 8 files
Support fallback resolver in *getlex*
 10:51
11:07 linkable6 left, evalable6 left
nine My current attempt is running $package.IMPL-CHECK($*R, $*CU.context, True); $package.meta-object; in the package_def action. But that leads to strange errors (as if there ever were others) like Type check failed in binding to parameter '$version'; expected Version but got Code (Code.new) 11:07
11:08 evalable6 joined
nine Possibly because $resolve-only = True actually still does much more than just resolving 11:08
11:09 linkable6 joined 12:07 reportable6 left 12:08 reportable6 joined 12:34 frost left
nine Oh LOL! And Why does IMPL-CHECK do too much even if I pass True for $resolve-only? Because truth is a pretty difficult philosophical concept. What's True in Raku is not necessarily true in NQP. It can be, like in the bootstrapping code (of which RakuAST is part of), but not in Perl6::Actions where I tried it. 12:37
There it probably parses as a package name which is not known and yields an NQPMu at runtime. Because NQP doesn't complain about unknown packages. 12:38
s/Perl6::Actions/Raku::Actions/
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/07/11/2022-...nciations/ 13:03
13:04 Kaiepi joined 13:07 Kaipei left 16:14 Altai-man left, Altai-man joined 16:25 dogbert17 left 16:28 dogbert17 joined 17:11 Altai-man left 18:06 reportable6 left 18:08 reportable6 joined 19:54 [Coke] left 19:55 [Coke] joined
nine 511 passing spec tests on RakuAST. That's 1 down, but that's just because of new tests and the rakuast falling further behind master. 20:19
20:22 sena_kun left
timo will it be rough to get master merged into rakuast? 20:26
20:28 sena_kun joined 21:00 lizmat_ joined 21:03 lizmat left 22:22 lizmat_ is now known as lizmat

Powered by Cro and the Raku® Programming Language.

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

Thank you!