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 01:05 reportable6 joined 01:32 ggoebel_ left
Geth MoarVM: 79ac88eae7 | Ruben++ | src/bithacks.h
Improve MVM_bithacks_next_greater_pow2 function
 02:09
MoarVM: a11b2c3833 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/bithacks.h
Merge pull request #1167 from rbnx/master

Improve MVM_bithacks_next_greater_pow2 function
02:24 frost joined 03:03 frost left
timo gist.github.com/timo/4e8d37590e744...b6a26fa1b0 - the spesh log parser script i'm working on offers this datastructure right now. for the moment it's ignoring comments, annotations, and even operators of instructions in BBs, and stats and spesh slots in specializations, but that stuff is on the map 04:02
also, no reason not to offer json export or something 04:05
but i'm expecting some interesting questions may be answerable when you've got the data in a format that's more structured than just lines 04:06
04:28 evalable6 left, linkable6 left 05:29 linkable6 joined 05:30 evalable6 joined
Nicholas good *, * 05:47
06:02 reportable6 left 06:04 reportable6 joined 07:15 nativecallable6 left, benchable6 left, linkable6 left, reportable6 left, sourceable6 left, evalable6 left, squashable6 left, releasable6 left, bisectable6 left, notable6 left, bloatable6 left, unicodable6 left, committable6 left, greppable6 left, shareable6 left, quotable6 left, tellable6 left, coverable6 left, statisfiable6 left 07:16 quotable6 joined, bisectable6 joined, coverable6 joined, linkable6 joined, evalable6 joined, releasable6 joined 07:17 tellable6 joined, nativecallable6 joined 07:18 unicodable6 joined, bloatable6 joined, reportable6 joined 08:16 statisfiable6 joined 08:17 greppable6 joined, squashable6 joined 08:22 psydroid left, AlexDaniel left 08:25 AlexDaniel joined 08:36 psydroid joined
lizmat interesting question: www.reddit.com/r/rakulang/comments...ce_hybrid/ 08:42
09:16 sourceable6 joined 09:18 committable6 joined
nine lizmat: I'm not sure I actually understand the question though 09:18
lizmat But I'm not clear by far, what's the approach for Raku code with native parts get developed with good ergonomics? 09:19
moon-child I think they want numpy but in raku
(technically inline::python, buut) 09:20
nine lizmat: there's that sentence, but then they're also going on about Go, Rust, Julia and JITs 09:21
lizmat well, the same question was asked on the mailing list as well, and Simon Proctor already started answering :) 09:23
09:35 JimmyZ joined
JimmyZ looks like tc->current_frame_nr is assigned but never used. 09:36
jnthnwrthngtn:^ 09:38
09:40 JimmyZ left
jnthnwrthngtn Curious, I thought the JIT uses it, but indeed, I see no references to it in the JIT 09:49
nine Has last been used before commit github.com/MoarVM/MoarVM/commit/8d...4b84fbcf12 09:53
jnthnwrthngtn has a go at removing it 09:56
jnthnwrthngtn doesn't see the Windows JIT bug get solved in backlog 10:03
Geth MoarVM/new-disp: a65827dc7b | (Jonathan Worthington)++ | 7 files
Eliminate unused tc->current_frame_nr

This ceased to be used in 8d97efcf but was not removed. JimmyZ++ for noticing.		 10:06
jnthnwrthngtn I'm now wondering if we can get rid of next_sequence_nr too
uh, next_frame_nr
The JIT and OSR both look at tc->cur_frame->sequence_nr 10:07
Ah, the JIT only in debug output 10:08
nine So what does OSR use it for? 10:09
jnthnwrthngtn Reducing the cost of polling for a ready candidate 10:11
But I think we could replace it with something else 10:12
10:12 ggoebel_ joined 10:17 notable6 joined
Nicholas "a small shell script"? :-) 10:18
Geth MoarVM/new-disp: a00870b6de | (Jonathan Worthington)++ | 7 files
Eliminate frame sequence numbers

The only remaining uses were:
  * In the JIT, but there only for debug output, so easily removed
  * In OSR to reduce the cost of polling for new candidates. We need two
   things: the number of candidates last observed and a way to know if
... (8 more lines)		 10:25
10:27 Altai-man joined
Altai-man Blin? 10:28
jnthnwrthngtn Can do.
Is it working?
Altai-man yes, I pinged and the domain was fixed
so should be
I'm doing bumps
jnthnwrthngtn ok 10:31
We may drop them again pre-merge, but if the blin needs it...
I have a windows vm on this box, so currently downloading a compiler to see if I can figure out the Windows JIT bug
lizmat why am I seeing a conflicts now on pulling new-disp ? 10:35
jnthnwrthngtn Because we rebased it 10:36
git reset --hrad origin/new-disp
(And `git fetch origin` instead of `git pull` before running that, if you don't want to see the erorr on pull :)) 10:37
nine Or `git remote update`
jnthnwrthngtn That's a new one on me :) 10:38
lizmat well, all of these fail to make: perl Configure.pl --force-rebuild --gen-moar=new-disp --gen-nqp=new-disp --make-install work for me 10:39
nine To be clear: git remote update is an alternative to git fetch origin. the reset --hard is still needed 10:41
I wonder why there's no convenience command for this though :) Or maybe there is but no one knows it?
Altai-man ā³ 338 out of 1698 modules processed 10:43
I'll do fast and slow runs today
dogbert17 Altai-man: what does that mean?
lizmat tools/templates/MOAR_REVISION: needs merge 10:44
error: you need to resolve your current index first
Altai-man dogbert17, I'll run Blin with pakku and then zef to be extra sure we have more coverage.
dogbert17 aha, thx for the explanation
nine lizmat: that's what git reset --hard should have taken care of? 10:45
lizmat yeah... I guess it should've but it didn't
did I ever mention I hate branches ? 10:46
:-)
ok, so I reset --hard it to a few commits ago 10:48
what should I do now?
git remote update 10:49
git reset --hard origin/new-disp
?
jnthnwrthngtn lizmat: Yes, you'll need to do it in each of the repos
lizmat ah! 10:50
rm -rf nqp 10:51
is less work (for me)
nine I'd say that too with a half a gigabit internet connection... 10:52
lizmat :-)
Altai-man ā³ 1085 out of 1698 modules processed
jnthnwrthngtn Windows is doing a good job of reminding me why I gave up developing on it... 10:57
nine Yeah, it has this habit
Yeah, it has this habit 10:58
lizmat test-t: 1.115 / .665 11:00
feels a tiny bit faster again 11:01
jnthnwrthngtn wonders how long until we break the 1s barrier :)
timo i was thinking, maybe instead of main we want to go old-school and call it "trunk" but then maybe instead we use a synonym, like "boot" and then i was just thinking "shoe" ... 11:06
Altai-man hmmm, perhaps it's something we should investigate... So there is a module called Grammar::Profiler::Simple. It does some magic with GrammarHOW and it fails because its tests are expecting the regexes to be called some exact number of times and the new times are lower! So the tests are wrong. Or so I thought... On the second thought, it's probably something we should look into? 11:09
I'll try to golf it, though the module is tiny.
ā³ 1507 out of 1698 modules processed 11:10
EXPORTHOW.WHO.<grammar> = ProfiledGrammarHOW; 11:11
oh no, I cannot golf it
anyway, is it normal we do less find_method calls now? 11:12
nine Altai-man: could be. After all new-disp tries to cache results of dispatch decisions (which find_method is part of) agressively 11:13
Altai-man see github.com/raku-community-modules/.../Simple.pm for the implementation
and github.com/raku-community-modules/...er/t/csv.t for the tests
jnthnwrthngtn Altai-man: Yes, it is 11:14
Altai-man the difference is in this table: github.com/raku-community-modules/....t#L15-L18 <- it expects for the token "value" to be called 6, 7, 14 times, but now it's called 3, 4 and 5 times, same as TOP and line.
jnthnwrthngtn That's odd, it's the closure returned from `find_method` that does all of the work, not `find_method` itself 11:16
(Which is how it should be.)
So I'm not sure why this would have changed
Altai-man ouch
then it's something to investigate, I guess. :/
I see some new modules, though not sure yet if races 11:17
ā³ 1638 out of 1698 modules processed
11:17 benchable6 joined 11:18 shareable6 joined
jnthnwrthngtn Also: is this a regression since the last blin run? 11:28
Altai-man jnthnwrthngtn, Grammar one? No. 11:29
I was considering it to be the "tests are implementation-defined" case of failure. 11:30
jnthnwrthngtn Well, that may be true, but I'll look into it 11:31
11:32 squashable6 left
Altai-man no hurry, I'll do a more complete overview for the fast round soon (8 modules to test left). 11:32
because I see some regressions compared to the last run, yes
Nicholas "Anything is better than windows installers"? (this seems to be like my daughter - anything is better than cleaning her rook. Even baths and homework) 11:33
11:34 squashable6 joined
jnthnwrthngtn wtf, so I installed MSVC and ActivePerl becuase that's the thing I was used to when developing on Windows. Then I get to the NQP Configure script, it wants the module Win32::Console, which is apparently not included, so I try and install it from CPAN and it fails because it's looking for dmake (what on earth make is that...) 11:36
Nicholas In the context of windows, I don't know. 11:37
I think the native Solaris make might (also) be called dmake, but likely it's a different 'd' 11:38
jnthnwrthngtn "It looks like you don't make nmake.exe"...yes I do, I just built MoarVM with it
[Coke] jnthnwrthngtn: reminds me of tryign to run things from a not-configured cmd prompt 11:39
jnthnwrthngtn [Coke]: I'm using the developer one that should have all the compiler stuff on path 11:40
I'd expect this if I wasn't
[Coke] huh.
jnthnwrthngtn (I can run nmake for sure) 11:42
Altai-man alright, not when you fight with windows, but the blin run ā„–1 (we need ā„–2 for more info) is done. aside from the Profiler issue there is a new regression since last run, `Unexpected multi dispatch step VMNull`). Affected modules are: BioPerl6, HTTP::Request::FormData, SupplyTimeWindow. I updated the wiki page. 11:43
jnthnwrthngtn Sigh 11:45
OK, my patience with the Windows thing is shot, I think 11:46
This is SEP.
I don't really understand why NQP's Configure script is using ExtUtils::MakeMaker 11:47
Oh, apparently IPC::Command::can_run uses it 11:48
[Coke] I'm using activeperl & msvc here, but installing any perl5 deps was a long time ago. 11:52
I appreciate you trying to resurrect your windows env. though.
jnthnwrthngtn How did you install them? I thought there was some ppm thing that pulled down binaries, but it seems gone in the ActivePerl I downloaded and there's just the CPAN client, which wants to build things 11:53
ah, it's been dropped 11:54
The CPAN client spits out a bunch of undefined warnings too, so I guess something is pretty busted somewhere 11:56
[Coke] it was probably 3 years ago I installed perl on this box, so I don't recall, apologies. 12:01
12:02 reportable6 left
[Coke] I am using strawberry perl. 12:04
... which contradicts what I just said. one sec. :)
yes, strawberry. wtf. I read my path, saw your send, and typed what you had instead. wtf. 12:05
[Coke] wanders off for another coffee
Nicholas coffee bootstrapping fail?
(You typed that faster)
[Coke] I made a cup at like 9pm last night, fell asleep having drunk like a tablespoon, and was finishing that cup this morning. guessing it's somehow lost its mojo? 12:07
Or... I'm an idiot. Probably that one.
Nicholas If you fell asleep despite drinking coffee, maybe you need more cups of sleep, not more cups of coffee
[Coke] I will try to spend some time this evening figuring out which commit broke the JIT on windows, but I'm sure we can sort it out, I'd say go ahead with the merge. 12:08
Nicholas: revenge bedtime procrastination!
crap, 2 blin failures? 12:10
Altai-man so far, yes
we came a very long way, though
lizmat reminds me of the time I needed a cup of coffee at 11pm to be able to sleep at all 12:11
unhealthy lifestyle, I might add
not recommended
ggoebel_ strawberry perl++ comes with everything you need. I haven't used ActivePerl since the days of Perl 5.6. Maintaining legacy perl with the occassional major perl version update was much easier with Strawberry Perl 12:18
jnthnwrthngtn ggoebel_: I think I found ActiveState played better with MSVC back when I was regularly doing stuff on Windows, but perhaps that's no longer true 12:21
Altai-man: The multi regression was a silly thinko; already got a patch locally, spectesting it 12:23
Altai-man jnthnwrthngtn, you mean the one with VMNull? Great, glad to know it's a simple case. 12:25
ā³ 650 out of 1702 modules processed
doing the slow run in the meanwhile...
jnthnwrthngtn Altai-man: Yeah, I just looked at recent dispatcher commits, looked at where it broke, and it was obvious which commit must be to blame 12:26
OK, on the profiler one...the problem is that the grammar never actually matches 12:31
And that's why the numbers are wrong 12:32
Not sure why yet
Pushed the fix for the VMNull issue 12:40
lizmat did we lose Geth ? 12:41
ah, a rakudo fix 12:42
jnthnwrthngtn Argh, I see the issue 12:43
Yeah, we need to patch the module, I tink
*think
Altai-man ā³ 926 out of 1702 modules processed 12:44
jnthnwrthngtn I'll send a PR. It's using the wrong variable somewhere, got away with it before, but doesn't now
Altai-man jnthnwrthngtn, it's a community module, so I'll merge it 12:46
ā³ 983 out of 1702 modules processed 12:47
and the crunching continues
jnthnwrthngtn Tursn out I had write access so github.com/raku-community-modules/...44501774bb 12:48
Altai-man yes, saw that 12:49
then we're out of regressions for now!
jnthnwrthngtn Also checked that Grammar::Tracer isn't vulnerable in the same way; it isn't 12:50
ggoebel_++ # Strawberry went much better 12:54
Nicholas "Strawberry Perl Forever" (nothing to get hung about) 12:56
jnthnwrthngtn :P 13:07
Darn it, it installed successfully here
Let's try with MVM_SPESH_BLOCKING=1 13:08
Altai-man jnthnwrthngtn, there is also a spectest failure, so your efforts were not in vain... 13:09
jnthnwrthngtn Spectest failure? 13:11
Altai-man oops, not spec, but "On windows, running 'make test' with TEST_JOBS > 1 causes sporadic failures in nativecall tests. Different tests fail each time; running the tests one at a time do not fail.". 13:12
jnthnwrthngtn OK, I've tried with MVM_SPESH_NODELAY=1 as well and I still can't hit the JIT bug 13:14
So, no luck
Can't fix what I can't repro, alas. 13:15
Running parallel nmake test now
Hm, I see two native call test failures that are independent of if running in parallel 13:21
They are about C++ name mangling
And fail even without parallel make
13:22 patrickb joined
jnthnwrthngtn So it seems I've failed to reproduce both of the Windows issues :( 13:22
patrickb the c++ name mangling failures are known and can also be observed on master
jnthnwrthngtn Ah, thanks 13:23
patrickb iirc that is
jnthnwrthngtn At a guess it'll depend on MSVC version
Just realized I still had spesh blocking/nodelay set when I did the nmake test run, so trying again without it 13:28
Alas, no, still only the name mangling failures
So yeah, really no luck reproducing either issue. :( 13:29
[Coke] jnthnwrthngtn: thank you for trying!
jnthnwrthngtn Altai-man: Any more news from blin? 13:30
[Coke] I also should see if I can repro the make test failures with the various DISABLE flags set
Altai-man ā³ 1426 out of 1702 modules processed
jnthnwrthngtn, nothing new
[Coke] jnthnwrthngtn: what does systeminfo | findstr /B /C:"OS Name" /C:"OS Version" say? 13:31
OS Name: Microsoft Windows 10 Enterprise
OS Version: 10.0.18363 N/A Build 18363
jnthnwrthngtn OS Name: Microsoft Windows 10 Pro 13:32
OS Version: 10.0.18362 N/A Build 18362
Typical enterprise software :P 13:33
Altai-man (unrelated to new-disp) also, that's old news, but github.com/MoarVM/MoarVM/pull/1472 has increased size of our release sources tarball from 5 mb to 13 mb. :( 13:34
jnthnwrthngtn Also
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30133 for x86
Altai-man: Due to the ryu submodule being huge? 13:35
Altai-man jnthnwrthngtn, yes, I think so.
jnthnwrthngtn oh goodness, yes, it's got a load of Java JARs int ehre
Wonder if we can exclude them if it's our fork of it 13:36
Yeah, it is
Nicholas: ^^
Altai-man probably worth experimenting, for the bisectable6's sake
[Coke] jnthnwrthngtn: ah: maybe this: 13:37
jnthnwrthngtn
.oO( gotta be careful if saying "huge jars" out loud.. )
[Coke] Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27035 for x64
you have x86, I have x64. 13:38
jnthnwrthngtn Wait, huh
Then how do I have a MoarVM with JIT support, we don't do x86...
Oh, bother 13:39
The moar it found when I checked that was a different one on path from a Rakudo installation I did in the past when testing Comma on this machine
Trying again with x64 13:40
timo d'oh 13:41
Nicholas "you say x86, I say x64" ... "let's call the whole thing off" 13:43
jnthnwrthngtn: the ^^ is "we want to exclude JARs from our ryu submodule" ? 13:44
jnthnwrthngtn Nicholas: Yes, if possible 13:45
patrickb jnthnwrthngtn: Did you use the devenv bat files to set up the build env in a console window? If yes, did you realize there are multiple such bat scripts for x64 and 86 and non C development? 13:46
jnthnwrthngtn patrickb: Yeah, I'm already using the x64 one of them now 13:47
Not sure why the one that looks like the standard one isn't that
patrickb I was bitten by this in the past as well. It's a mystery to me why MS doesn't improve the abysmal developer experience with the Build Tools. 13:50
nine patrickb: I think their fix is "use Windows Subsystem for Linux" 13:51
And "stay within Visual Studio" for the rest
patrickb :-( 13:54
jnthnwrthngtn make test is clean for me with x64 13:56
(no mangling errors)
Sadly that means not the parallel nativecall errors either 13:58
JIT is certainly built this time 13:59
nine And make install? 14:00
jnthnwrthngtn I just tried it with no options, with blocking and with nodelay, and it completes successfully under all of them :( 14:01
Altai-man one small case is Cro::HTTP with `Tests out of sequence. Found (49) but expected (48)` in the `http2-request-parser.t` but I don't know if it's a flapper or not, I'd say it is.
jnthnwrthngtn I think it is 14:02
Altai-man ā³ 1663 out of 1702 modules processed 14:03
jnthnwrthngtn So, really no luck on Windows repro, even with the JIT :(
I kinda wanted to figure it out pre-merge, but I guess it can come after.
nine If you can't repro, that probably also means that fewer people would be affected 14:08
jnthnwrthngtn This is true. I'm just a bit surprised I can't given we're on very close OS and compiler versions 14:20
nine And given that Windows is usually the much more standardized environment 14:23
[Coke] weird. 15:02
I also figured you'd have a much more recent version of cl, but those seemed close, too. 15:03
close-ish, anyway
moved the windows failures on github.com/rakudo/rakudo/wiki/Raku...isp-branch to a separate section. 15:05
lizmat: be nice if we can solicit more windows feedback on the weekly once we merge.
15:05 reportable6 joined
jnthnwrthngtn This time we fixed everything blin found before blin got done :D 15:06
But it's completed now, any nothing extra 15:07
I think we can go for a merge
Nicholas does the beer fridge agree?
15:08 discord-raku-bot left 15:10 discord-raku-bot joined
timo very glad to hear, good work everybody 15:10
[Coke] jnthnwrthngtn: one other difference is that I was always building with --moar-option=--debug, which shouldn't matter, but trying without that. 15:11
jnthnwrthngtn Yeah, I didn't add that 15:12
[Coke] I needed it for previous debug efforts. 15:13
jnthnwrthngtn If that is the difference it'd be...curious
15:16 patrickb left
jnthnwrthngtn Merge is done locally, currently running tests 15:23
The beer fridge is at home and I'm at the office, but yes, it's ready :) 15:24
Nicholas and the callwith work from the office is pushed somehwere safe so that you can carry on with it safely next week?
jnthnwrthngtn I'll be at the office for the rest of this week anyway ;)
*:)
gfldex Is this a good time to get unreasonably excited? 15:25
jnthnwrthngtn I'm so excited I even prepared a blog post... 15:31
gfldex I know that feeling! :D
Nicholas Hopefully slightly longer than the speech described after " being invited back to Shrewsbury to open a new wing at his old school" in fampeople.com/cat-willie-rushton_2 15:34
jnthnwrthngtn :D 15:35
[Coke] uh, I just did nmake instll without failure.. 15:50
tryin test now... :)
oh wait. I might have env vars set.
I did have jit disabled, but reran teh install with jit and it was fine. 15:53
wtf.
WTF. nativecall tests are passing. Was it really --moar-option=debug ?? 15:57
jnthnwrthngtn++ for making me double check 15:58
er, --debug. you know
Nicholas jnthnwrthngtn++ # for many things
[Coke] I'll try a fresh build also with the debug option and check again. 15:59
I also did some git cleans recently; maybe something was sticky before? 16:01
Geth MoarVM/master: 576 commits pushed by 9 authors
review: github.com/MoarVM/MoarVM/compare/a...2e835dc1c8		 16:07
jnthnwrthngtn The merges are pushed. 16:08
timo party time
[Coke] just saw Unhandled exception: The invoke ops are superseded by the general dispatch mechanism on current build on new-disp 16:15
timo then your nqp or rakudo is out of date 16:16
[Coke] weird. build died in new weird way using --debug
jnthnwrthngtn 6guts.wordpress.com/2021/09/29/the...m-is-here/ 16:17
[Coke] switching to master... 16:18
nine wooohooooooooo 16:23
jnthnwrthngtn [Coke]: I wonder if --debug makes for a different stack frame layout and this somehow confuses the JIT, which relies on that... 16:24
Nicholas new-disp is dead. Long live new-disp 16:30
timo jnthnwrthngtn++ 16:36
after new-disp comes new-new-disp 16:37
Nicholas At some point. But I think a beer or two comes first
and a good night's sleep 16:38
Your branch is behind 'origin/master' by 578 commits, and can be fast-forwarded. 16:49
172 files changed, 20425 insertions(+), 12190 deletions(-) 16:50
Thud!
16:50 nige joined
nige just wanted to pop in from the irclogs - to say thanks to Jonathan++ and everyone on the team++ for your work! well done everybody 16:52
jnthnwrthngtn :) 16:53
nige very exciting to see the progress :-) 16:55
MasterDuke congrats all around, very cool 16:56
looks like a new warning, `src/spesh/graph.c:322:68: warning: passing argument 4 of ā€˜MVM_spesh_disp_initialize_resumption_op_infoā€™ discards ā€˜constā€™ qualifier from pointer target type [-Wdiscarded-qualifiers]`, also seen at src/spesh/disp.c:450:68: 17:00
17:01 nige left, nige joined 17:06 nige left, nige joined 17:07 ggoebel_ left
Geth MoarVM: c33111fd64 | (Jonathan Worthington)++ | 2 files
Be more constsistent to fix some const warnings
 17:15
[Coke] jnthnwrthngtn: there were a bunch of warnings on the windows build for moarvm also. I had a list, can update it. 17:21
jnthnwrthngtn Hm, it looked relatively quiet for me 17:23
I did see a const mention, so maybe that was the one I just fixed
MasterDuke master already had some windows-specific warnings
one was kind of impossible to fix, caused by a macro that gets expanded to early or something like that 17:24
"unrecognized escape characters'J'" or some such
jnthnwrthngtn I spent a while trying to fix that a while back and concluded it'd need patching dynasm 17:25
And that it wasn't worth it
(For me :))
MasterDuke Nicholas: my daughter probably wouldn't like cleaning a bird either 17:30
jnthnwrthngtn: here's a significant perf regression from new-disp colabti.org/irclogger/irclogger_lo...09-29#l199 17:53
jnthnwrthngtn Interesting. Guess a profile will tell all... 17:55
MasterDuke 31mb html profile
jnthnwrthngtn Probably will need to look at a master one too 17:57
Nicholas it's all master now! :-)
jnthnwrthngtn :P 17:58
17:58 Altai-man left
jnthnwrthngtn home time, bbl 17:59
MasterDuke only 3.38% of callframes were eliminated by inlining
71% exclusive time in `build-flat-method-tablegen/moar/stage2/NQPCORE.setting:5653907927039030630503162` 18:00
18:02 reportable6 left 18:05 reportable6 joined
lizmat feels to me the EVAL $_ for @tests is maybe a sort of worst case for the new dispatch mechanism? 18:15
dogbert17 on my system it takes 38s on master but only 5 with 2021.04 18:17
lizmat on mine 41 18:24
I've just done a profile on a subset of the tests: There were 531 global deoptimization triggered by the profiled code. 18:25
so that's... bad
Nicholas hopefully also "target rich environment" 18:26
lizmat but indeed: build-flat-method-table is at the top with 54%, yet it claims to have been OSRd ?
18:31 nige left
lizmat doesn't look like that sub itself can be made any better 18:31
18:31 nige joined
[Coke] turning new-disp wiki page into two blocker tickets (which are sparse on details) 18:35
18:36 nige left, nige joined 18:39 nige left
[Coke] done, 4541, 4542 on rakudo 18:40
Nicholas jnthnwrthngtn: ASAN is unimpressed by all your hard work. Or maybe it is. It's not saying anything. 18:51
jnthnwrthngtn How many times is build-flat-method-table being run?! 18:54
lizmat in the subset of the tests I did: 17K+ times (at 54% of wallclock) 18:55
jnthnwrthngtn A quiet ASAN is a happy ASAN
lizmat: That...should not happen. :)
lizmat yeah... figured it's tickling something :-)
jnthnwrthngtn Megamorphic blowup prevention mechanism in megamorphic blowup shocker...
lizmat yeah... something's off :-) 18:59
MasterDuke build-flat-method-table was run 503k times in my profile of the whole test file 19:29
jnthnwrthngtn Hm, the profile I ahve here...oh, I was about to say what MasterDuke just did :) 19:42
Full polymorphic dispatch inline cache at:
at gen/moar/stage2/QRegex.nqp:560 (/home/jnthn/dev/MoarVM/install/share/nqp/lib/QRegex.moarvm:mergesubrule) 19:43
There's handling of a big variety of method names, which suggests the problem here is a big variety of types.
Question is, why.
(Alternatively, said handling is busted too.) 19:44
lizmat maybe some recursive snafu ? 19:45
jnthnwrthngtn I wonder if we don't cache regex languages that we derive 19:46
Then the cursor type would vary wildly
MasterDuke it's compiling a lot of regexes, but i don't see any particular reason there should be new types created with a quick look through
jnthnwrthngtn oh, no, we just don't share said quote lang caches, they seem to hang off $*W 19:48
So it'll derive the same one hundreds of times 19:49
dinner, bbiab
19:54 brrt joined
brrt \o 19:54
tellable6 2021-09-28T22:36:18Z #moarvm <MasterDuke> brrt thanks, i'd forgotten there was a letv. that plus a fix for an actual error i'd made elsewhere and it's working
brrt .tell jnthnwrtngtn that the frame sequence nr was quite useful in debugging... oh well 19:55
tellable6 brrt, I haven't seen jnthnwrtngtn around, did you mean jnthnwrthngtn?
brrt yes, I did mean that tellable6
wasn't just 'jnthn' available? :-P
Nicholas o/
lizmat brrt: no, it wasn't :-( 19:56
Nicholas brrt: new-disp has landed. SMOP is now "JIT all the things". No pressure. :-)
brrt: someone else registered "jnthn" first, but last I looked they had never logged in again. 19:57
brrt sadly
AlexDaniel lizmat: how come? Somebody squatting on it on the new network?
Oh
:-/
brrt that sucks...
Nicholas libera *now* has a policy of (roughly) "use it or loose it" - nick registrations only stick if you log in again within [I forget] 19:58
brrt ... so no time for playing earthbound then
MasterDuke should become available after 10 weeks of non-use
changing to 20 weeks soon
libera.chat/news/lengthening-nick-expiry
lizmat jnthnwrthngtn: fwiw, it feels to me that Cro::WebApp templates also take significantly longer to parse now 20:02
it feels related to what Juerd found 20:03
20:03 brrt left
[Coke] how can you see the last-used date of another nick 20:07
?
Nicholas IIRC I was trying /whowas until I got bored
MasterDuke can we call the mutex (un)locking functions in the jit? 20:17
e.g., uv_mutex_lock 20:18
20:28 ggoebel_ joined 20:42 squashable6 left
jnthnwrthngtn lizmat: Yeah, if the profile also points to the flat method table calculation and mergesubstates is high in the profile, it will be 21:16
Will implement something for when the megamorphic explosion is in invocant type tomorrow. 21:17
I figure we also will want a way to ask for new dispatch programs to be prepended at the callsite, not appeneded as they are now. Or maybe we should just switch to prepend as the default. 21:22
For monomorphic sites it isn't an issue, for polymorphic ones latest first might reflect the current phase the program is in, and for megamorphic ones we want to hit the megamorphic handler ahead of any of the other things we stacked up at the callsite previously before we knew it was megamorphic. 21:23
MasterDuke huh, gist.github.com/MasterDuke17/129ca...beeef36731 (jit of getcomp) causes a segfault in nqp's t/qregex/01-qregex.t (and the rakudo build) 21:25
in uv_mutex_lock
oh, uv_mutex_t is a struct. don't you have to do something different to pass a struct into a function call in asm? 21:27
maybe that's why the (un)locking functions are never (explicitly) called in the jit 21:30
jnthnwrthngtn I may be forgetting, but I thought it wanted a pointer to the struct? 21:33
afk again for a bit
MasterDuke oh, i completely missed the & in front. jnthnwrthngtn++ 21:34
hm, switching the last `mov ARG1, MVMINSTANCE:ARG1->mutex_compiler_registry` to `lea ARG1, MVMINSTANCE:ARG1->mutex_compiler_registry` gives a different segault (but still in nqp's t/qregex/01-qregex.t (and the rakudo build)) 21:39
japhb MasterDuke: Wouldn't you need to do it for both the first and last? 21:58
Or is the & only on *one* of the lock/unlock pair?
MasterDuke huh, don't know why i said 'last', i did it for both 21:59
22:34 ggoebel_ left
MasterDuke hm. mostly unrelated other question, why doesn't the jit MVMROOT anything? obviously the macro wouldn't work, but i don't see any MVM_gc_root_temp_(push|pop) used either 22:53
timo every register that can hold object pointers is already rooted 22:55
by register i mean WORK[blah]
japhb Noticed that myself as I've been reading through. *So far*, my guess would be that you only care about opportunities for allocation (triggering GC), because the registers ... what timo said ... so in the case that you're calling some MVM_routine, you'd expect that any rooting needed would happen there. 22:56
There are a couple cases I haven't researched enough to feel sure about though. 22:57
Turns out the JIT is *way* bigger than I expected. A lot of that seems really repetitive though. 22:58
timo i think we have at least one spot where we refresh a pointer from the frame's WORK space
the exprjit also has information about which ops allocate, maybe it does something with that 23:17
23:37 evalable6 left, linkable6 left 23:43 squashable6 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!