🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm Set by lizmat on 22 May 2021. |
|||
00:02
reportable6 left
00:35
Xliff joined
00:55
frost joined
01:04
reportable6 joined
01:12
rakuUser left
02:12
bloatable6 left,
squashable6 left,
sourceable6 left,
coverable6 left,
reportable6 left,
quotable6 left,
nativecallable6 left,
greppable6 left,
benchable6 left,
linkable6 left,
notable6 left,
statisfiable6 left,
committable6 left,
tellable6 left,
bisectable6 left,
shareable6 left,
releasable6 left,
unicodable6 left,
evalable6 left,
committable6 joined
02:13
nativecallable6 joined,
greppable6 joined,
quotable6 joined,
tellable6 joined,
benchable6 joined
02:14
linkable6 joined,
squashable6 joined,
notable6 joined,
evalable6 joined
03:14
bisectable6 joined,
shareable6 joined,
coverable6 joined
03:15
reportable6 joined,
sourceable6 joined
04:03
discord-raku-bot left
04:04
discord-raku-bot joined
04:15
unicodable6 joined,
bloatable6 joined
05:13
Xliff_ joined,
statisfiable6 joined
05:17
Xliff left
06:02
reportable6 left
06:03
reportable6 joined
06:13
releasable6 joined
08:05
linkable6 left,
evalable6 left
08:28
patrickb joined
|
|||
patrickb | o/ | 08:28 | |
Can someone remove the Raku Con banner from raku.org? | 08:29 | ||
09:20
lizmat_ joined,
lizmat_ left,
lizmat_ joined
09:23
lizmat left,
TempIRCLogger left
09:24
lizmat_ left
09:27
lizmat joined
09:28
lizmat joined
09:29
TempIRCLogger joined
10:07
linkable6 joined
10:08
evalable6 joined
|
|||
nine | Oh darn. Setting RAKUDO_MAX_THREADS to anything doesn't have any effect. Why? Because we create the ThreadPoolScheduler object during the settings compilation. | 10:13 | |
MasterDuke | doh! | 10:16 | |
lizmat | ?? I think it is set during execution ? | ||
are you saying it gets serialized ? | |||
nine | Apparently so. As can be seen by the absence of any "Created scheduler" message, when run with RAKUDO_SCHEDULER_DEBUG=1 | 10:22 | |
lizmat | wow | ||
that's bad, I'd say? | |||
but but the settings compilation doesn't do any shelling or start or anything async that I know of? | 10:23 | ||
nine | Indeed. github.com/rakudo/rakudo/blob/mast...ue.pm6#L82 | 10:24 | |
lizmat | WOT | 10:28 | |
nine | One can work around this somewhat with PROCESS::<$SCHEDULER> = my $*SCHEDULER = ThreadPoolScheduler.new(:max-threads(4)); | 10:30 | |
lizmat | but, that's execution, is it not ? | ||
nine | The documented way of just setting $*SCHEDULER is not enough | ||
But I still get the impression that 2 schedulers are active | |||
yes, I put that line into our service.pl6 | 10:31 | ||
MasterDuke | greppable6: ThreadPoolScheduler | ||
greppable6 | MasterDuke, 16 lines, 7 modules: gist.github.com/0733e291bae1725288...c9d3dca659 | ||
MasterDuke | greppable6: SCHEDULER | ||
greppable6 | MasterDuke, 192 lines, 18 modules: gist.github.com/482740f5bdbb598506...9297e17f86 | ||
10:56
squashable6 left
10:58
squashable6 left
11:06
sena_kun joined
11:49
lizmat left
11:50
lizmat joined,
lizmat left
11:51
lizmat joined
11:53
TempIRCLogger left
11:54
lizmat left,
lizmat joined
11:55
TempIRCLogger joined
12:03
reportable6 left,
reportable6 joined
|
|||
Geth | rakudo: b14d404a19 | (Elizabeth Mattijsen)++ | 2 files Make the default scheduler see RAKUDO_MAX_THREADS Not sure why it wouldn't see this otherwise, as the other settings *are* apparently seen correctly. Assume it is some weird bootstrap issue at process startup. |
12:21 | |
MasterDuke | looks like a space was accidentally moved from github.com/rakudo/rakudo/commit/b1...630bc7L807 to github.com/rakudo/rakudo/commit/b1...b10bd252R1 | 12:25 | |
12:29
patrickb left
12:39
patrickb joined
12:42
AlexDaniel left
12:45
AlexDaniel joined
|
|||
MasterDuke | given that coercion parameters are so slow, should they be used in the core setting? | 12:59 | |
e.g., github.com/rakudo/rakudo/blob/mast...tr.pm6#L52 | 13:00 | ||
m: use nqp; class A { has str $!value; submethod BUILD(Str() :$value = "" --> Nil) { nqp::bindattr_s(self, A, q|$!value|, nqp::unbox_s($value)) }; method Str(A:D:) { self }; }; my $a; $a := A.new(:value($_)) for ^1_000_000; say now - INIT now; say $a | |||
camelia | 1.684516707 A.new |
||
MasterDuke | m: use nqp; class A { has str $!value; submethod BUILD(:$value = "" --> Nil) { nqp::bindattr_s(self, A, q|$!value|, nqp::unbox_s($value.Str)) }; method Str(A:D:) { self }; }; my $a; $a := A.new(:value($_)) for ^1_000_000; say now - INIT now; say $a | 13:01 | |
camelia | 1.033107545 A.new |
||
13:06
rakuUser joined
13:19
Xliff_ left
13:29
Xliff joined
13:37
frost left
|
|||
lizmat | MasterDuke: that would only apply to someone doing Str.new | 13:45 | |
which not many people are ? | |||
but yeah | |||
going afk now& | |||
MasterDuke | yeah, github.com/rakudo/rakudo/blob/mast....nqp#L1345 is the only place i found so far | 13:46 | |
but that was really just one specific example | 13:47 | ||
greppable6: Str.new | 13:54 | ||
greppable6 | MasterDuke, 88 lines, 13 modules: gist.github.com/5aa8d642fb3eaa0db5...9679366c5c | ||
14:15
b2gills left,
b2gills joined
|
|||
Geth | nqp/new-disp: 65d7bb8592 | (Jonathan Worthington)++ | 2 files Add nqp-istype dispatcher Which will be used when we can't resolve an istype using the type check cache. This follows the current semantics of nqp::istype(...), although we may want to revisit this in the future. |
14:17 | |
rakudo/new-disp: 5d6a45cec8 | (Jonathan Worthington)++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp Register nqp-istype dispatcher for Raku also We'll write a Raku-specific one at some point since we can likely rewrite some type checks (for example, on definedness types) into simple dispatch programs. For now, this will keep things working as MoarVM moves istype over to using a dispatcher for the fallback cache-mess case. |
14:18 | ||
rakudo/new-disp: 8c8c91cc71 | (Jonathan Worthington)++ | src/Perl6/Metamodel/MROBasedMethodDispatch.nqp Cease publishing legacy method cache on MoarVM |
14:36 | ||
nqp/new-disp: 2470be00cc | (Jonathan Worthington)++ | 4 files Cease publishing legacy method cache on MoarVM |
14:42 | ||
MasterDuke | this wasn't a completely rigorous benchmark, but changing github.com/rakudo/rakudo/blob/mast...m6#L52-L54 from `submethod BUILD(Str() :$value = '' --> Nil) { nqp::bindattr_s(self, Str, '$!value', nqp::unbox_s($value)) }` to `submethod BUILD(:$value = '' --> Nil) { nqp::bindattr_s(self, Str, '$!value', | 14:49 | |
nqp::unbox_s($value.Str)) }` seemed to bring stage parse from ~42.5s to ~42.0s | |||
Geth | nqp/new-disp: f46dae9f6c | (Jonathan Worthington)++ | src/core/dispatchers.nqp Fix a typo |
14:52 | |
Kaiepi | MasterDuke, is the read of @!concretizations relevant to the lock in Metamodel::Concretization.'!maybe_rebuild_table'? | 15:03 | |
MasterDuke | not sure what you mean. which read? | 15:11 | |
Kaiepi | if nqp::elems(%new_conc_table) < nqp::elems(@!concretizations) | 15:13 | |
i think there's a way to make it more sparing with the nqp::objectid calls, just how it would be done depends on where that condition needs to be | 15:15 | ||
vrurg | Kaiepi: it is now me missing the point. How could objectid replace number of elements? | 15:19 | |
MasterDuke: a side note. There is another potential race we've missed in Concretization.add_concretization method. Resetting of %!conc_table is not protected. This may result in delayed cache update if %new_conc_table gets assigned too early. I'll try to remember to take care of this when done with pseudos. | 15:26 | ||
Kaiepi | because %new_conc_table is a clone of %!conc_table, it already has each of the concretizations that existed in the prior call to !maybe_rebuild_table. with the size of the clone, you get the starting position of any newly added concretizations in @!concretizations, since those can only be appended | 15:28 | |
the resetting of %!conc_table can go that way | 15:29 | ||
Geth | rakudo/new-disp: d15098d850 | (Jonathan Worthington)++ | 2 files Remove meth cache auth op uses on MoarVM |
15:30 | |
nqp/new-disp: 9c64b44e04 | (Jonathan Worthington)++ | 2 files Remove method-cache related ops on MoarVM |
|||
Kaiepi | if that condition doesn't need to be protected, then the lock can be skipped when no update is needed | ||
resetting from add_concretization, i mean | 15:33 | ||
15:36
patrickb left
|
|||
Geth | rakudo/new-disp: 080c43425a | (Jonathan Worthington)++ | 2 files Update p6invokeunder to use MVM_frame_dispatch Its ultimate destiny is to go away, as it's a quite terrible hack; that can happen when we make the final push to eliminate the extops as a whole. |
15:52 | |
16:57
squashable6 joined
17:22
rakuUser left
17:32
rakuUser joined
|
|||
Geth | rakudo/new-disp: e109bf0e06 | (Jonathan Worthington)++ | 3 files Replace p6getouterctx with dispatcher + syscall |
18:00 | |
18:02
reportable6 left
18:36
sena_kun left
18:38
SmokeMachine__ left,
SmokeMachine__ joined
|
|||
Geth | rakudo: 94462dfab8 | (Elizabeth Mattijsen)++ | src/Perl6/Grammar.nqp Remove use of Str.new from grammar FROGGS added this in 2014, when perhaps this was needed because of Parrot. Removing it completely and just using whatever self.orig gives us, does not break any spectest, nor does it inhibit installing slangs like Slang::Tuxic or Slang::Piersing. So I assume this was really an old wart, which is now gone. Should a blin run show that this *did* break something, then just revert this. |
19:10 | |
lizmat | MasterDuke ^^ | 19:11 | |
MasterDuke | ha, nice | 19:16 | |
huh. inspired by ^^^ to try and make $!orig here github.com/Raku/nqp/blob/master/sr...sor.nqp#L4 a str, but it turns out it's specced to not always be a string github.com/Raku/roast/blob/master/...ject.t#L89 | 19:55 | ||
vrurg | Kaiepi: it was a hash-updating algorithm initially. But there was something broken about it and I had to switch to run-time update with resetting. Though a lot has changed in moar since then, perhaps it would make sense to try it again. | ||
lizmat | MasterDuke: when is it not a string? | 19:57 | |
MasterDuke | m: say 12345 ~~ /2../ | 19:58 | |
camelia | 「234」 | ||
MasterDuke | it's an Int there | ||
lizmat | isn't that a string that can be an Int ? | 20:01 | |
MasterDuke | i'd say it's an Int that can be a string | ||
12345 by itself is an Int | 20:02 | ||
lizmat | yeah, but the smartmatch works on "12345" | ||
it can not work on the Int | |||
MasterDuke | m: say "src/Perl6".IO ~~ /6/; say $/.orig.WHAT | 20:03 | |
camelia | 「6」 (Path) |
||
MasterDuke | after my change the .WHAT is `(Str)` | ||
20:04
reportable6 joined
|
|||
MasterDuke | m: Str.can('split') ~~ /split/ # another breaking change (so far, haven't tried to fix yet), i get 'This type cannot unbox to a native string: P6opaque, Method' | 20:07 | |
camelia | Method object coerced to string (please use .gist or .raku to do that) in block <unit> at <tmp> line 1 |
||
MasterDuke | m: use Test; ok Str.can('split') ~~ /split/ | 20:08 | |
camelia | Method object coerced to string (please use .gist or .raku to do that) in block <unit> at <tmp> line 1 ok 1 - |
||
Geth | rakudo: 3aba97077b | (Elizabeth Mattijsen)++ | src/core.c/Promise.pm6 Save 2 Scalar containers per Promise.new GC runs from 18 -> 14 for Promise.new for ^50000 No change for subclasses of Promise |
20:18 | |
MasterDuke | that can probably be fixed relatively easily, but the Str vs whatever-type-the-object-actually-is case is a change in spec | ||
lizmat | yeah, reminds me of my Match refactor work :-( | ||
[Coke] | does t/02-rakudo/18-pseudostash.t fail everywhere or just on my machines? | 20:24 | |
(windows, os x) | |||
lizmat | does not for me on master | 20:26 | |
MacOS | |||
MasterDuke | nor for me on master/linux | 20:40 | |
Geth | rakudo/new-disp: bade712274 | (Jonathan Worthington)++ | 3 files Unwrap Code outside of p6setfirstflag So that it doesn't need to do it inside of the op, removing one more place that we rely on the legacy invoke spec. |
20:45 | |
rakudo: 3c1c709cea | (Elizabeth Mattijsen)++ | src/core.c/Promise.pm6 Make allocations of Promise.thens list lazy Saves one BOOTArray allocation for each Promise.new that doesn't do any .then. |
20:47 | ||
japhb | Loving the Promise improvements, lizmat++. What triggered this? And are you planning to attack any of the other concurrency classes? :-) | 20:53 | |
gfldex | lizmat: that improvement might pay of later :-> | ||
Xliff | japhb: How many Promise improvements (actually, this might be better for lizmat) | 20:54 | |
Hmm... git log --grep=Promise? | |||
lizmat: Actually....after reading, I definitely agree with japhb!\ | 20:57 | ||
japhb | Xliff: She's done optimization passes of the scheduler and such in the past, but when I saw the drop in GC runs from Promise building earlier today, I got excited. :-) | ||
Xliff | I've just started using Promises in earnest, so I'm happy to see these. | 20:58 | |
m: my $p = Promise.new; Promise.in(5).then: { $p.keep }; react { whenever $p { done } } | 20:59 | ||
camelia | ( no output ) | ||
Xliff | Basic react with a time limit. | ||
MasterDuke | Xliff: btw, istr that nine++ made a bunch of moarvm improvements on master recently that might help your usecase (i.e., large projects with lots of dependencies). have you noticed any changes? | 21:04 | |
japhb | m: react whenever Promise.in(5) { say "done!"; done } | ||
camelia | done! | ||
japhb | Xliff: ^^ Simplified | ||
Xliff | MasterDuke: You mentioned that, before. Is that for precompilation or recompilation. | 21:11 | |
I have not been noticing much in the way of precompilation improvements? If there have been any, they've been eaten up by other things. | 21:12 | ||
MasterDuke | whoops, forgot i'd mentioned it. i'm not 100% certain, but i think mainly (re)compilation | ||
Xliff | Please see recent timings: github.com/Xliff/p6-GLib/blob/mast...ounts.xlsx | 21:13 | |
Check the "Regular Timings" tab | |||
MasterDuke: Yeah, I don't have any baseline to test (re)compilations against./ | |||
Although I might want to have both of you check out the slowness of github.com/Xliff/p6-X11 | 21:14 | ||
Particularly Display.pm6 | |||
It's slow. It acts as if "no precopilation" has been issued. | |||
MasterDuke | i think it's a little late for nine to be online, but i'll mention it next time i see him in a channel | 21:17 | |
just clone and run build.sh? | |||
no meta6.json? | |||
21:29
rakuUser left
21:43
MasterDuke left
|
|||
[Coke] | rebuilt, still getting the error on t/05-messages/02-errors.t | 21:44 | |
japhb | When your own code doesn't even appear on the first *page* of exclusive-sorted profile output, sorting by entries (total call count) puts the bootstrap and setting in the top slots, and inclusive time shows nothing but concurrency code ... >.< | 21:46 | |
[Coke] | ww | 21:47 | |
japhb | Even on a per-call basis, a naive reading would indicate that *by far* the slowest routines are in the scheduler. Which I'm guessing most likely means that's an area that the profiler doesn't have enough visibility into. :-( | 21:52 | |
japhb rages against his machine for a bit | 21:53 | ||
Is there a way to "name" an anon block so that it appears as such in the profile data, but without causing a performance difference? I finally found a view on the SQL profile that was actually showing me heavy bits of my own code, and it was mostly anon blocks. | 21:58 | ||
Also, is there any way to see when a Raku problem is suffering lock or queue contention? | 21:59 | ||
*program | |||
22:15
rakuUser joined
22:19
rakuUser left,
rakuUser joined
22:49
MasterDuke joined
|
|||
MasterDuke | japhb: perf maybe? | 22:49 | |
japhb | MasterDuke: Hmmmm. Any guidelines on using that with Rakudo? | 22:54 | |
MasterDuke | i use `MVM_JIT_PERF_MAP=1 perf record -z -g --call-graph dwarf raku <...>` | 23:22 | |
and then `perf report --call-graph=none --no-children` | 23:32 | ||
japhb | Why use --call-graph on the record and --call-graph=none on the report? | 23:49 |