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:02 reportable6 left 00:03 reportable6 joined 00:08 ggoebel joined 01:13 ggoebel left 01:43 frost joined 04:32 linkable6 left, evalable6 left, reportable6 left, bloatable6 left, unicodable6 left, greppable6 left, tellable6 left, coverable6 left, squashable6 left, sourceable6 left, releasable6 left, shareable6 left, statisfiable6 left, committable6 left, quotable6 left, notable6 left, benchable6 left, nativecallable6 left, bisectable6 left 04:33 evalable6 joined, benchable6 joined 04:34 bloatable6 joined, quotable6 joined, coverable6 joined 04:35 shareable6 joined, tellable6 joined 05:32 unicodable6 joined 05:33 linkable6 joined, bisectable6 joined 05:34 nativecallable6 joined 05:35 committable6 joined 06:32 sourceable6 joined 06:34 notable6 joined 07:04 reportable6 joined 07:33 greppable6 joined 07:34 squashable6 joined 07:35 statisfiable6 joined 08:34 releasable6 joined
lizmat There's still quite a lot to be regained with spectesting: 08:39
logs.liz.nl/search.html?query=File...ies-pp=500
from 202 in October 2019 (1276 files / 109517 tests) 08:40
to 309 today (1349 files / 117863 tests)
MasterDuke m: say 202/1276 ~ " " ~ 202/109517; say 309/1349 ~ " " ~ 309/117863 08:43
camelia 0.158307 0.0018445
0.229059 0.0026217
jnthnwrthngtn yawns 08:44
Ugh, that was an early start to the day for me...
nine It's not even noon yeat! 08:45
jnthnwrthngtn :) 08:46
I've already been to the other side of the city and back to visit the interior ministry...again, because they were disorganized last time. 08:47
nine Did it go any better today?
jnthnwrthngtn Yes, except sleepy me parse-failed the very first thing the agent said to me. :) 08:48
Anyway, in another month or so I will go to pick up a card and then I in theory don't have to visit them again for another 10 years :)
I suspect spectest is hugely impacted by startup time 08:50
lizmat indeed
also, these numbers are always of a 2nd run, so that all ad-hoc module uses have been pre-compiled already
jnthnwrthngtn I believe github.com/MoarVM/MoarVM/pull/1578 should shave off a few percent 08:51
lizmat we will see!
jnthnwrthngtn However, for me it does not because by this point I see to always be waiting for one test file that takes for bloody ever
t/spec/S32-io/lock.t 08:52
By now all the other tests are done and I wait 5-6 seconds just on this one finishing.
Didn't we have a thingy to run slow tests earlier, and if so, can I mark it up as such? 08:53
nine jnthnwrthngtn: actually that test seems to start a whole lot of child rakudo processes
lizmat doing that right now
jnthnwrthngtn lizmat++
nine: It does but when I glanced it also seems sleepy 08:54
nine So any improvments to startup speed should help a lot with this test
lizmat hmmm... that file is not in spectest.data ?
nine Oh, sleep in tests...that's a plague
jnthnwrthngtn > NMAKE : fatal error U1073: don't know how to make 'gen/nqp-version' 08:55
lizmat ah, that file has moved
jnthnwrthngtn I...what? :)
lizmat jnthnwrthngtn: that test is already marked as slow
jnthnwrthngtn lizmat: Is there a "glacial" marker? :) 08:56
Anyway, not a big deal
nine That marker would cause it to get started before you even start the test run!
jnthnwrthngtn Hm, the dev.azure.com/MoarVM/MoarVM/_build...ed5cabfd35 failure on my frame patch seems to be the thing nine++ already fixed :) 08:57
Ooh, my next grant app is posted! news.perlfoundation.org/post/grant...imizations 08:58
09:00 patrickb joined 09:02 patrickb left
nine jnthnwrthngtn: since the build you linked to was successful: what was the bug I fixed? 09:13
jnthnwrthngtn nine: The recent `make test` flapper 09:14
nine ah the deopt issue 09:15
jnthnwrthngtn Yeah, believe so
Sigh. Why doesn't the link go to the build log I was looking at when I copied it :/ 09:16
nine Modern web crap...
MasterDuke dev.azure.com/MoarVM/MoarVM/_build...108585217d 09:18
nine Yes, that looks like the thing I fixed 09:19
09:19 patrickb joined
jnthnwrthngtn I love how the modern web encourages readable URLs :) 09:20
nine Well, Microsoft has had a fetish for GUIDs even before the web :) 09:21
jnthnwrthngtn: I'm reviewing #1578 and found something. So please hold off the merge 09:27
jnthnwrthngtn Better to catch things in review than after merge :) 09:31
nine Ah, I think I misunderstood it anyway
Well, not totally. Apparently frame->work being NULL had 2 different meanings before. Could be because work_size is 0 or because the frame is no longer in dynamic scope 09:34
jnthnwrthngtn I don't think work_size being 0 ever actually happens 09:35
nine Probably not in any real code :)
jnthnwrthngtn And was slightly tempted to outlaw it at bytecode validation time so we never pay the price for that check 09:36
That said...we may no longer need the check at all 09:37
nine Someone ought to make a badger version with null, null, null, null, null, null, null, null, null, null, null, null, oh it's a return_v!
jnthnwrthngtn We did before because asking the FSA for 0 bytes is an error
09:37 squashable6 left
jnthnwrthngtn null needs a result register :) 09:37
You'd need noop
nine Ah, yes, I meant noop
jnthnwrthngtn Which actually has the same number of syllables as badger
nine oh, even better :) 09:38
jnthnwrthngtn: how often does env_size change during specialization compared to changes in work_size? 09:53
jnthnwrthngtn nine: work_size changes more often 09:55
nine Would it make sense then to have work follow env instead of the other way round? Could save some memory copying
jnthnwrthngtn Hm, fair point. 09:56
otoh, env tends to be smaller than work, so in the case there are things to copy, we'd be copying more 09:57
nine yes, just thought of that, too 09:58
jnthnwrthngtn Given this only happens when we do OSR, and even then only the first time we OSR the frame (because if we deopt and OSR again we already had the specialization), it's not really a hot path 10:00
(Frames only grow, we never shrink them on deopt)
10:00 patrickb left 10:02 CaCode joined 10:30 sena_kun left, sena_kun joined
nine jnthnwrthngtn: why don't we need the special handling of puns in the megamorphic case? 10:44
jnthnwrthngtn nine: Because the megamorphic case is only used when the meta-class is a ClassHOW 10:48
Which means it's certainly not a role
nine Meh... MVM_nativecall_make_cpointer returns a type object for NULL pointers. A distinction that box_i doesn't make. And of course Inline::Perl5 relies on Pointer:D to not be NULL 10:52
10:53 frost left
jnthnwrthngtn Hmm... Tried to get finalization to work by generalizing the deopt mechanism (so we mark a frame as having a tweaked exit sequence and then, as we return into it, do the deopt and additionally trigger the finalizer call) 10:56
But somehow we end up with the top frame sometimes having been tweaked...
Which is never supposed to happen 10:57
nine rr time?
jnthnwrthngtn sigh, yes, if I can get a test to fail standalone rather than under make test or make spectest... 10:59
Which never seems to happen :/ 11:00
11:03 frost joined
jnthnwrthngtn argh, I see, it happens when we have an exception and so are unwinding the stack 11:13
That is certainly a bad time to go and invoke something 11:14
nine Hm... sp_boxifnonzero_i? 11:17
Don't think that would play well with box/unbox pair elimination 11:18
I'll probably have to generate something like set(result_reg, result_type); if_i(temp_result_reg) { box_i(result_reg, result_type) }; 11:20
But of course a conditional means that I have to add a whole new BB 11:25
11:40 squashable6 joined
nine Huh... apparently we have a MVM_spesh_manipulate_split_BB_at function that could make this easier. AFAICT though this function has never been in use in our code base 11:46
MasterDuke added a while ago bdff4dc9e3a35d764523d17ec2a0f76f91ce0387 11:48
11:48 linkable6 left 12:02 reportable6 left
nine Since these manipulations are so complicated, I wonder, can't I just turn it into: set(result_reg, result_type); guardnonzero(temp_result_reg); and have it deopt to after the dispatch instruction. The result_reg would contain the correct value then. 12:07
It would probably work. And it'd have the advantage of having facts about the result's type (if it's non-NULL). It would also be a total abuse of the deopt mechanism which is already so hard to understand and get right without such shenanigans. 12:12
jnthnwrthngtn: would you hate me for ^^^? 12:13
jnthnwrthngtn Sorry, was having lunch, reading 12:25
nine: That'd mean we deopt every time a function returns NULL, which sounds rather sub-optimal if that's a normal behavior 12:27
nine Yeah, there's that
jnthnwrthngtn Also, to where would be deopt?
This is about processing the result?
nine yes
jnthnwrthngtn But the deopt point for a dispatch is before it, so we'd end up running the dispatch again?
nine It's all so we turn a 0 into a Pointer instead of a Pointer.new(0)
We'd have to deopt to after the dispatch 12:28
But yes, it sounds less and less like a winner :)
jnthnwrthngtn Yeah, inserting the new BB and conditional sounds smarter 12:29
nine Ok, I've now written down the details of the transformation. Maybe that helps me with writing the code for it :) 12:32
LOL: MoarVM oops in spesh thread: Too many levels of inlining popped 12:45
tellable6 nine, I'll pass your message to lol
lizmat lol :-) 12:48
13:02 evalable6 left
jnthnwrthngtn Sigh, I guess the deopt-y approach for finalizers is just too fragile to work 13:03
lizmat perhaps a trick like the IV tricks in Perl, would allow for frames to be small without finalizers, and bigger with ? 13:04
or is that way too hacky?
jnthnwrthngtn This isn't really about the frames themselves, it's just trying to find a cheap way to signal a thread that we want to run finalizers 13:05
At the moment we do it by using the special return mechanism 13:06
It's also the only case where we don't install a special return handler on the stack top 13:07
So also the only one where we can't just replace it with what I'm replacing everything else with
lizmat so you'd want to prevent the "do we have finalizers in this frame" check on each frame exit
jnthnwrthngtn They aren't in the frame 13:08
They're a global thing
When GC runs, and there are objects with a DESTROY, we need to arrange for them to be run
lizmat right
jnthnwrthngtn But GC can happen anywhere and it may not be safe to just invoke code on that thread at that point in time
lizmat and we want the DESTROY to run at the same thread always, right? 13:09
jnthnwrthngtn Yes, that's the constraint that makes this tricky.
13:09 discord-raku-bot left
lizmat but maybe we only need that in a few cases? 13:09
jnthnwrthngtn Probably most things really don't care
lizmat perhaps a trait on the DESTROY to force same threadness would already help a lot? 13:10
jnthnwrthngtn But that still means I need a mechanism to allow it.
lizmat true
or maybe postpone that until there's a proven case that it needs it?
13:10 discord-raku-bot joined
lizmat or do you know that some situations need that already ? 13:10
jnthnwrthngtn We already have a case that needs it (Inline::Perl5)
lizmat I see... ok 13:11
jnthnwrthngtn If it wasn't for that, I'd just have introduced a finalizer thread already :)
lizmat but isn't this not more about running on the right Perl interpreter than running on the right thread ?
jnthnwrthngtn Well, those are 1:1 today, but also if it's on the right thread there's no concurrency control issues too 13:12
lizmat fwiw, I think having a finalizer thread makes sense regardless... but may introduce more maintenance cost ?
jnthnwrthngtn I can see why it's really useful to have these run on the same thread, it's just finding a way to make it happen that doesn't cause all kinds of bother. 13:13
Or, well, put costs all over the place
lizmat yup, gotcha 13:18
however, if Inline::Perl5 is the only case that we must finalize on the original thread, maybe that should be made a responsibility of Inline::Perl5 rather than Raku ? 13:19
(sorry nine, playing advocate of the devil here)
jnthnwrthngtn The special return usage dealing with exception unwinding is also rather...interesting 13:44
(as in, simply using the new mechanism doesn't work out)
nine lizmat: chances are, if it's needed once, it will be needed again. 100 year language and all 13:45
If it weren't for that I'd have suggested the same already 13:46
lizmat nine: ok :-)
I guess we would need to have it for Inline::Python as well :-)
nine If that ever gets threading support. But I can imaginge it being necessary for UI toolkits like Qt as well 13:48
14:03 evalable6 joined 14:15 raku_user joined
raku_user nine: I was following your discussion in the logs, does it even makes sense to have MVM_nativecall_make_cpointer return the type object for NULL? Isn’t that just a bizarreness of NativeCall? 14:18
i mean: it return an object for any other values of pointers 14:19
What if a library really meant zero for zero? Will math work on that pointer? 14:20
doués it buys us anything ? 14:22
Well, yes.. 14:23
14:23 raku_user left
jnthnwrthngtn While that's arguably the case for a CPointer, for a CStruct we really do except the type object for NULL there 14:26
I guess the pointer being the type object is consistent with that
Hm, that odd situation where you seemingly fix a problem just by deleting code... 14:42
14:51 linkable6 joined
[Coke] That's a *good* feeling, non? 14:54
er, no?
jnthnwrthngtn Yes, except I wonder if I realized something then that I don't now :) 14:58
15:03 reportable6 joined
nine raku_user: also code in the wild depends on the behaviour 15:05
tellable6 nine, I'll pass your message to raku_user
jnthnwrthngtn OK, got the exception unwind stuff figured out for special return, that leaves just one use in the Rakudo extops 15:13
Well, and an alternative solution needed for finalizers.
Although I think that's going to be "give up and pay a pointer check each return" for now
Given I'm saving plenty of other costs on that path with this
nine Cost savings? Management's gonna be thrilled! 15:14
15:20 coleman-x left
Geth MoarVM/cheaper-frames: 4 commits pushed by (Jonathan Worthington)++ 15:59
jnthnwrthngtn nine: Thanks for the review, fixed the things :) 16:01
16:25 linkable6 left, evalable6 left 16:33 patrickb joined
nine cool 16:39
17:01 rypervenche left 17:10 rypervenche joined 17:26 evalable6 joined 18:02 reportable6 left 19:04 reportable6 joined 19:16 patrickb left
lizmat ok, I found another weird thing, as yet unexplained 19:40
IRC::Log::Colabti entries have a .date method that consists of { $!log.date }, aka fetching the date of the log they belong to 19:41
this returns a Date object
this is used as part of creating the target ID of the message, which is YYYY-MM-DDZHH:MM for the first message of a minute 19:42
when the code is written as: self.date ~ 'Z' ~ hhmm stuff
then in about half of the cases, the date disappears from the target 19:44
if I however add .Str to the .date, all is fine 19:45
will try to golf this down 19:46
20:28 linkable6 joined
lizmat hmmm... adding the .Str makes the 'Z' disappear 20:38
21:03 discord-raku-bot left 21:04 discord-raku-bot joined
Geth MoarVM/master: 5 commits pushed by (Jonathan Worthington)++ 22:17
timo cool 22:41
22:53 linkable6 left, evalable6 left 22:54 linkable6 joined 22:55 evalable6 joined
japhb That looks like a bump-worthy merge .... 23:14
23:55 linkable6 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!