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.
MasterDuke ah, i thought we were already doing that now. i was wondering if you had some way of knowing how many lines would be in a file and would have been impressed if so 02:07
Geth MoarVM/main: 7c4149096f | (Daniel Green)++ | 3 files
Fix some compiler warnings

Format string directive and two function return value types.		 02:45
MoarVM/main: d3f7bc1fca | (Daniel Green)++ | azure-pipelines.yml
Remove mingw from CI

It's been broken for a while, I tried to fix it and couldn't, nobody has complained, and it makes every CI run red regardless if everything else passes.
MoarVM: MasterDuke17++ created pull request #1819:
Bump mimalloc to 2.1.7		 02:47
MoarVM/main: 397bb29613 | (Daniel Green)++ | src/jit/stub.c
Missed updating jit stub signatures

GCC compiled without warning, but clang complains.		 03:15
MoarVM/main: 78b8650f68 | (Daniel Green)++ | src/profiler/heapsnapshot.c
Completely comment out some debugging variables
 03:46
MoarVM/main: 021e22e25d | (Daniel Green)++ | 6 files
Remove unused variables
MoarVM/main: 0f5f11f2a7 | (Daniel Green)++ | src/spesh/optimize.c
Ensure a variable is initialized before it's used
MoarVM: MasterDuke17++ created pull request #1820:
Update OS versions in Azure CI config		 03:52
MasterDuke hopefully that cleanup didn't cause problems for anybody, but if so, all those commits should be easily revertable 03:53
07:21 vrurg_ joined 07:23 vrurg left 07:24 vrurg joined 07:25 vrurg_ left 07:53 sena_kun joined
lizmat will bump MoarVM just in case 09:12
09:23 sena_kun left
timo1 i have a super silly little tool (idea) 10:54
lizmat shoot! 11:07
timo1 a second, please :) 11:08
> The autodict function returns a special kind of Python dictionary that implements Perl’s autovivifying hashes in Python i.e. with autovivifying hashes, you can assign nested hash values without having to go to the trouble of creating intermediate levels if they don’t exist. 11:09
perf devs know what's up
say lizmat, would you like to know how fast the parser went through the core setting file, or any file that is parsed? with fine details? 11:12
lizmat eh, yes! 11:15
timo1 in order to run the data collection yourself you will need a linux system with perf working 11:56
lizmat ah... that excludes me with MacOS :-( 11:59
timo1 could be faked with a properly placed fprintf
lizmat ? 12:02
12:10 Woodi joined
timo1 it doesn't actually have to use perf 12:41
13:10 MasterDuke left
timo1 opening the result in the browser is very tough on the browser 14:06
for the core.c setting
i'm using HTML::Entity::Fast and i see the &newline; show up literally in my browser; could it be not all browsers handle that entity? 14:27
lizmat I don't think that's a supported entity? 14:29

 maybe ?
afk& 14:31
timo1 oh huh i did not expect case to make a difference but yeah with NewLine it works but not with newline 14:43
lizmat, here's an HTML for you to download with the first $amount of stuff from the core setting gist.github.com/timo/3086df220b1b7...eecd3ae034 14:45
i'm not sure how useful it actually is, since it is extremely naive
it takes the time when nqp::nfa_run is called on the string, and notes down the exact time
then i subtract the time of one position from the time of the next position and divide by the number of characters 14:46
but of course a lot can happen between two runs of nqp::nfa_run, plus it goes a little bit back and forth sometimes
like GC runs, and of course the Actions run at that time as well 14:47
there's no reason why we wouldn't use the position-time association from nqp::nfa_run to map other metrics to the source file being parsed. like major and minor gc runs would probably be a relatively obvious next thing to try 14:52
lizmat timo1: I'm not sure what the colors mean? 15:50
timo1 you can hover the text as well to get the actual number 15:51
but the redder it is, the longer it took from the call to nfa_run at the start position to the call to nfa_run at the end position of the colord text
which is very roughly and kind of indirectly a measure of how fast we parse i guess 15:52
lizmat aahh...ok
timo1 we might not actually be seeing every single call to nfa_run as a split in positions 15:55
so as long as you don't rely too much on that... should be fine?
lizmat it's nice to see... but it's not easy to find any hotspots that we could act on 16:00
also: I wonder how much difference there would be between runs
aka: how much of the red spots is random, and how much is systemic 16:01
timo1 it's also a bit tricky because i color by percentiles. otherwise everything is bright green except for a single spot that takes too long 16:06
oh that problem probably sorted itself out when i divided by segment length? 16:14
0 0.000096 1 0.001259 5 0.002606 10 0.003624 25 0.005971 50 0.010151 75 0.017244 95 0.044895 98 0.091657 99 0.153758 16:15
i think &hat; has a similar problem as &newline; 16:18
grab the new version of the file, you can now jump from one 99pct bit to the next and back with little links on the page 16:46
lizmat will do after finishing the weekly 17:02
17:17 sena_kun joined
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/07/08/2024-...-year-llm/ 20:32
21:55 vrurg_ joined 21:57 vrurg__ joined 21:58 vrurg left 22:01 vrurg_ left 22:33 sena_kun 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!