00:26 notable6 left, benchable6 left, squashable6 left, bloatable6 left, releasable6 left, linkable6 left, sourceable6 left, bisectable6 left, nativecallable6 left, greppable6 left, statisfiable6 left, unicodable6 left, tellable6 left, quotable6 left, shareable6 left, committable6 left, evalable6 left, reportable6 left, quotable6 joined, releasable6 joined, greppable6 joined 00:27 notable6 joined, reportable6 joined
timotimo making it easier to write QAST analysis and transformation code by offering some kind of interactive, iterative, fast experimentation mode, like a REPL, would be So Nice 00:27
i know we had something in a gist somewhere in the past
00:27 linkable6 joined, sourceable6 joined, evalable6 joined
timotimo greppable6: QAST.*gist.github 00:28
00:28 shareable6 joined
greppable6 timotimo, Found nothing! 00:28
00:28 unicodable6 joined, statisfiable6 joined, bloatable6 joined, squashable6 joined, nativecallable6 joined
timotimo greppable6: gist.github.*QAST 00:28
00:28 committable6 joined
greppable6 timotimo, Found nothing! 00:28
00:28 bisectable6 joined
timotimo oh i want quotable dont i 00:28
quotable6: QAST.*gist.github
quotable6 timotimo, OK, working on it! This may take up to three minutes (4582161 messages to process)
00:28 coverable6 joined 00:29 tellable6 joined, benchable6 joined
quotable6 timotimo, 7 messages (2013-08-06āŒ2018-01-15): gist.github.com/8b8001bf560d79d203...5dc1cae109 00:29
timotimo oh no, irc.perl6.party isn't there any more, and irc.raku.party isn't there either 00:31
rba timotimo: what would you expect on the irc.*.party urls? 00:34
timotimo it redirects to the colabti online irc logs
rba I think perl6.party is with zoffix. I don't know who controls raku.party though. 00:37
I have rakudo.party under my control. 00:41
Yet not configured to point to a usful place.
Geth_ Ā¦ problem-solving: Kaiepi assigned to jnthn Issue Attributes could use more support for reflection github.com/Raku/problem-solving/issues/174 02:52
03:27 hungrydonkey joined 04:04 Kaiepi left 04:09 hungrydonkey left 04:14 hungrydonkey joined 05:17 hungrydonkey left 05:18 hungrydonkey joined 05:46 hungrydonkey left 06:12 toddr left
MasterDuke timotimo: thinking about one of the tools mentioned here? blogs.perl.org/users/zoffix_znet/20...cious.html 06:52
07:12 hungrydonkey joined, Altai-man_ joined 08:01 hungryd51 joined 08:02 hungrydonkey left
jjatria japhb: I was playing around with Terminal::Print yesterday, and I ran into some trouble when I expected to be able to use `T.blit` to print the grid, but ended up having to use `print T.current-grid` instead, and I still haven't quite figured out if that's a bug or if I was using it wrong 08:34
08:56 hungryd51 left 09:00 hungrydonkey joined 09:12 sena_kun joined 09:14 Altai-man_ left 09:45 lichtkind joined 10:18 lichtkind_ joined 10:21 lichtkind left
AlexDaniel timotimo: yep the redirect is no longer working :( 10:32
10:40 lizmat joined 10:49 hungryd91 joined 10:53 hungrydonkey left
lizmat Files=1306, Tests=111208, 213 wallclock secs (29.41 usr 8.35 sys + 3004.02 cusr 272.79 csys = 3314.57 CPU) 11:06
S06-operator-overloading/imported-subs.t fails with "Missing or wrong version of dependency 'gen/moar/Grammar.nqp'" 11:07
is this a known issue?
11:11 Altai-man_ joined 11:14 sena_kun left
lizmat running a full configure.pl sequence made S06-operator-overloading/imported-subs.t pass again 11:52
12:12 squashable6 left 12:14 squashable6 joined 12:18 squashable6 left 12:20 squashable6 joined
timotimo jnthn: i think something's gone wrong with the optimizer and its block stack; i tried to is_from_core '&infix:<+>' the other day and it couldn't be found at all; it said the block stack is just 2 entries big, too, which would be the mainline of the program and one core setting outside of it. can that be right? 12:40
in particular, i think the .c core setting isn't properly showing up any more for is_from_core 12:41
jnthn timotimo: What if you `use v6.c`? 12:42
timotimo the stack size stays the same whether i use .c, .d, or .e.PREVIEW 12:44
when i find_in_setting with the same name, i at least don't get a null back 12:45
and it doesn't die, which it would if it didn't find it
i'm grabbing my $!symbols via $*OPTIMIZER-SYMBOLS btw, not sure if that could be wrong 12:51
even inside of Perl6::Optimizer using its own $!symbols, &METAOP_HYPER isn't seen as "from core" 12:53
lizmat timotimo: could this be because it is an implementation detaiil 13:06
jnthn Don't think the optimizer would do any such filtering 13:07
I mean, such things ain't hidden from symbol tables?
lizmat if you use PseudoStash.keys or friends, they would
please try passing :implementation-detail 13:08
it should give you *all*
jnthn Worth a check, but I think it looks at what's in the QAST outer scope 13:10
(in the block symbol table)
lizmat: Was it ever proven that there was a slowdown from the move of the scalar container stuff into MoarVM and associated generalization? 13:11
Or was it ambiguous as to whether it was that or something else?
lizmat I could not find another explanation
at least for the slowdown in spectest
13:12 sena_kun joined
timotimo going through the block stack manually right now 13:14
798 &METAOP_HYPER BOOTHash concrete
jnthn OK. The cachegrind run I did while working on it was kinda odd in that it showed an unexpected (though probably in noise without cachegrind) improvement.
timotimo found this in one of the blocks
13:14 Altai-man_ left
timotimo 705 CORE-SETTING-REV BOOTHash concrete 13:15
this is also here
but this is from find_in_setting, not from is_from_core
lizmat m: sub a(|c, :$foo) { dd c, $foo }; a 42, :foo # this should probably have been caught at compile time
camelia Too many positionals passed to 'a'; expected 1 argument but got 1
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
timotimo 240 &infix:<+> BOOTHash concrete 13:17
finally here's the one i was searching for
797 &infix:<*> BOOTHash concrete
and another friend
lizmat: there is nothing here where i could pass :implementation-detail 13:18
lizmat ok, then I didn't bork it :-)
MasterDuke anyone have an opinion on github.com/Raku/nqp/pull/612 ? 13:19
jnthn Did it really need a rebootstrap? 13:20
I'll have to look at the MoarVM PR first, I guess
MasterDuke that kind of got mixed in because i couldn't print uint32s while debugging 13:21
it's not actually required for the change in functionality
also, the part that require the MoarVM PR could be backed out if it isn't desired 13:22
timotimo is it bad that i grab the "array" type (well, the type of a "my int @foo" from the symbol table) and calling .of on it seems to make a pun? 13:35
jnthn Don't think that's a problem 13:38
I think it's a parametric role really
timotimo mhm
i stepped through the creation of a ClassHOW (i.e. its BUILDALL) which had a buildplan with 57 entries 13:39
decided i don't want to manually step through that and called "step out"
turns out that isn't implemented, or buggy, so it finished running the program instead
welp
jnthn d'oh
timotimo i want to start debugging at a later point anyway i guess
haha, the &infix:<*> i have is stored as a strands array 13:46
5 strands
MasterDuke huh, how'd that happen? 13:47
timotimo 6 chars from the first strand, 1 from the other strands each
probably from being parsedā„¢ 13:48
MasterDuke ah
Geth_ roast: 875d15cd88 | (Elizabeth Mattijsen)++ | S03-sequence/exhaustive.t
Add support to test multiple endpoints

Sadly, current implementation of ...^, ...^ and ^...^ do not support that yet, so skip those tests for now.
MasterDuke did you see brrt's desire to remove strands from moarvm and move them to nqp/rakudo? if we have tons and tons of strings with strands because of parsing, would that be an argument for or against his proposal? 13:49
timotimo i didn't know about that
MasterDuke colabti.org/irclogger/irclogger_lo...04-06#l130 13:51
timotimo there can be a calculation for when creating a regularly stored string is less memory usage than having a strands array 13:53
there can also be a nice trick where when we concat two strings and the second string actually starts with what's after the first string's strand ends, we just extend one strand and discard the other 13:54
but the check could be expensive
i see what's up now 14:03
14:04 hungrydonkey joined 14:05 hungryd91 left
timotimo is_from_core looks for the key "value", but the &infix:<*> entry has only lazy_value_from and scope 14:05
Geth_ rakudo: ebb294996e | (Elizabeth Mattijsen)++ | src/core.c/PseudoStash.pm6
Make PseudoStash.sort not reveal implementation details anymore

  - by defailt, pass :implementation-detail to get them all
  - also affects .gist / .raku / .Str, which was really the goal		 14:06
timotimo i'll spectest my fix and push it 14:14
MasterDuke is this conditional correct? github.com/Raku/nqp/blob/master/sr...d.nqp#L444 or should there be parens about the two || tests?
lizmat afk for a while& 14:16
timotimo could very well be wrong
github.com/Raku/nqp/commit/c2362f4...90f8cfR448 - jnthn, have a quick look? 14:17
could be right, too
force_value may set the value slot, and the seen hash also gets an entry set by this
Geth_ rakudo: 604085fb24 | (Timo Paulssen)++ | src/Perl6/Optimizer.nqp
optimizer: consider more kinds of symbol "present"

when checking if something comes from the core or has been overwritten locally; maybe the introduction of nested cores or something else made lots of operators and other subs have only "lazy_value_from" and "scope" keys in their symbol table entry. Until now only the presence of a "value" entry was enough to consider a symbol "present".		 14:27
MasterDuke timotimo: what are the implications of a symbol being "present" or not? 14:29
timotimo many optimizations will bail out if a symbol involved in what it does have been overwritten by the user or a module 14:30
MasterDuke ah, right
timotimo++
timotimo i imagine you'll have a clue or two what i might be up to from the symbols i've been mentioning 14:43
MasterDuke i assume more vectorizing of hyper */+/etc? 14:44
timotimo well, optimization in any case
no full vectorization yet, but at least i should be able to build loop fusing and tiling too at some point 14:45
generating tight loops directly with nqp ops whereever hyperops are used (with plenty of restrictions) will already have a good factor speedup before loop fusing happens, but i will put in loop fusing immediately anyway 14:47
MasterDuke good deal. that seems like the sort of thing that is frequently touted as a feature of julia/numpy/etc, and i'm happy to see raku improve there
timotimo without real vectorization we'll be leaving a factor of whatever left on the table 14:48
dunno, 8x?
MasterDuke yep, but incremental improvements are also nice 14:49
timotimo quite 14:59
i don't have a good intuition what algorithms exist out there that hyper data with bigger chains of hyperops 15:03
but initially i'll only support ops like @a >>+<< @b with +, -, *, and @b >>*>> 123 with +, -, * 15:05
then i think comes -<<@blerp
at some point ++<<, --<<, >>++, and >>-- could be done 15:06
15:07 lichtkind_ left
timotimo should be trivial to add +&, +|, +^, ... for >>x<< hypers once + works 15:08
15:08 lichtkind_ joined
timotimo after that, index calculations would be important. first .reverse, then .head and .tail and such (which will be tricky for >>+<< since that changes a lot how size checks are done) 15:09
and [1,2 ... *] will be important at one point, too 15:10
rotor with "take one each" semantics as well
can you think of anything else? 15:11
15:11 Altai-man_ joined 15:14 sena_kun left
timotimo supporting rotor and index calculations on the result assignment 15:16
15:18 Kaiepi joined 15:27 lichtkind_ left
MasterDuke what would need to be done special for that? 15:32
timotimo naively, just create the whole thing and then do the index stuff 15:33
but if you take only every 3rd entry in the result, you may be able to save two thirds of the work 15:34
other interesting ops from infixes include comparison operators 15:36
numpy has a cool thing where you can index @foo[@foo %% 2], which gives you an array with only the entries of @foo that are even 15:37
in raku that'll be more verbose
i mean we can literally just grep 15:38
whats cool is @quux[@quux == 5] = 123 15:41
MasterDuke what does that do? 15:42
timotimo replaces 5 with 123
also @quux[@baz == 5] = 123
puts a 123 whereever baz has a 5
MasterDuke huh 15:43
nine Looks like there's an easy workaround for my precompilation issue with the package declarator of my custom meta class.
I just have to put the EVAL where that's used into it's own module that's required instead of used 15:44
Then it works just fine, even with everything precompiled.
MasterDuke timotimo: likely going to be afk for a bit, but if you have any ideas for how to debug/fix that profile problem, i might try to take a look at it later 15:59
timotimo i almost forgot hyper method calls 16:02
nine Yes! All tests successful. 16:13
timotimo nice 16:16
nine Stable memory usage in our real world application, much faster and greatly simplified and less hacky architecture. This was a week really well spent :) 16:32
jnthn \o/ 16:33
jnthn is doing lots of thinking about the dispatcher stuff
nine is very much looking forward to the new dispatcher stuff 16:34
And to the Raku AST talk :) 16:38
jnthn Seems that ultimately, certain things will just disappear (like the multi dispatch cache)
Depending on how one sees it, spesh plugins too, though in a sense it seems they're the winners in this in so far as they're closest to what we want. 16:39
nine As long as there's still a possibility to add multi method candidates at runtime with decent performance? Currently I add them to the cache
Or not just candidates, but whole methods i.e. protos as well 16:40
jnthn If anything, adding stuff at runtime will be less fraught after this 16:42
The current thinking I have will make most of the augment + subclass problems go away
And probably all of the practical problems
Well, hmm, ish. :) 16:44
Altai-man_ jnthn, possibly addressing broken master as well? 16:46
nine And, and, and world peace? :D 16:49
jnthn Altai-man_: Broken as in? 16:52
Altai-man_: the nextdispatcher perf regression?
Altai-man_ jnthn, the segfault on windows causing builds to be broken, see github.com/rakudo/rakudo/commits/master every single commit
since two or about three weeks ago 16:53
jnthn Ah...no, that's unrelated to the dispatcher stuff, and I think I've maybe got enough on my plate, so for now I'll leave it and hope somebody else might figure it 16:54
japhb jjatria: Did you T.blit the correct index? (There might have been more than one grid in your T.grids.) 17:00
17:12 sena_kun joined 17:14 Altai-man_ left
[Tux] Rakudo version 2020.02.1-299-g604085fb2 - MoarVM version 2020.02.1-78-ge7fee00d1
csv-ip5xs0.705 - 0.728
csv-ip5xs-206.051 - 6.407
csv-parser27.762 - 28.724
csv-test-xs-200.383 - 0.415
test7.800 - 7.840
test-t2.047 - 2.263
test-t --race0.995 - 1.005
test-t-2033.875 - 33.893
test-t-20 --race9.236 - 10.617
 17:14
dogbert17 hmm, shouldn't test-t be around 1.7 17:37
also, is there a description somewhere about how to set up rakudo on Windows? Is it enough to install MinGW and git? 17:39
timotimo all the hyper optimizations i do i should also put in checks to make extra sure that nothing on the objects that go in has been changed 17:40
like, if i optimize @blehĀ».sqrt, i have to bail if dispatch:<hyper> or the sqrt method aren't right
i wonder how sensitive the check should be, though
at some point, we reach DIHWIDT territory i guess 17:41
actually maybe i should leave the method call be and rely on spesh to inline the methods 17:51
18:06 hungrydonkey left 18:10 Kaiepi left 18:13 Kaiepi joined
timotimo if i turn @native-int-array>>.sqrt into a low-level loop with nqp::sqrt_n instead of a method call, the speedup can be pretty big 18:17
potentially from >2 minutes down to ~3 seconds in this one manual example test 18:21
MasterDuke does it depend on the op/method? i.e., is it something about sqrt, or does turning any hyper into a loop provide that much speedup? 18:24
timotimo i tried sqrt, abs, and sin. those three are about the same 18:26
do you have other suggestions? 18:27
MasterDuke hm, abs should be much faster than the others, so i would think the main speedup is from re-writing >> into a low-level loop
which is good, right? because that can be a more general optimization
timotimo yeah
pushing the results into the array seems to be a big portion of total time 18:28
keeping the method call around and hoping spesh will do a good job inlining isn't quite good enough; it causes a whole lot of unnecessary boxing and unboxing, making GC a significant portion of run time 18:29
MasterDuke is it just me, or does this code create a whole bunch of QAST::Ops, only to keep the very last one? why not just create the last one directly? github.com/rakudo/rakudo/blob/mast...5123-L5128
timotimo no, look, it puts $path into the tree 18:31
MasterDuke oh, good spot
timotimo the difference between >>.abs and the equivalent nqp op thing may be even more stark 18:34
i tried to get an approximation by doing only 1 million values 10 times instead of 10 million ten times
but now i did ten million once and it took almost a minute 18:35
when i did one million ten times it was just 20 seconds
MasterDuke that makes sense right? when the op itself is cheap, the reduced overhead will stand out more 18:37
timotimo not sure what exact overhead is causing this nonlinearity 18:38
MasterDuke profile isn't showing it? what about perf?
timotimo i didn't run it through the profiler just yet %) 18:39
do you want to? :D 18:40
my int @a = ^10_000_000; my int @result; for ^1 { @result = @a>>.abs; Nil }
vs
my int @a = ^1_000_000; my int @result; for ^10 { @result = @a>>.abs; Nil }
19:11 Altai-man_ joined 19:14 sena_kun left 19:49 lichtkind joined
MasterDuke back now. the 10m run did the same number of GCs. half the number of full collections (5 vs 10). but, total time and percentage of time were much greater. 13s vs 3s and 57% vs 23% 20:36
same number of frames entered and inlined 20:38
20:40 sena_kun joined
MasterDuke gc times look like sawteeth for the 1m profile, but just a single sawtooth for the 10m (no surprise there i guess) 20:40
20:42 Altai-man_ left
MasterDuke routines look almost identical 20:47
timotimo weird, what could it be keeping around that long? 20:53
MasterDuke what do you mean? isn't the gc moving @a around? 20:56
timotimo do the "gen2 roots" go up?
oh i'm not even sure if the profiler also includes managed memory
it could very well be that that's the size of the result array
can you have a look what they allocate? i would expect a boatload of Num and Int 20:57
MasterDuke nope. starts out at some larger number, but then drops to 24 and pretty much stays there
allocations are pretty much the same between them, but the Int allocations are half red for the 10m case 20:58
19999892 Int, 10003609 BOOTHash, 10000011 Scalar, 10000000 IntPosRef, 9999993 BOOTCode 20:59
linkable6 (2016-03-02) github.com/nadade/attributes-kit-g...19999892ce Update apiary.apib
(2014-11-06) github.com/simonbasle/.dotfiles/co...10003609a3 added osx detection and bundles
timotimo oh, is that so?
MasterDuke the red ones are all in STORE, SETTING::src/core.c/native_array.pm6:661
timotimo why is that not being speshed, i wonder. it should totally OSR, i'd imagine 21:00
but that's also setup work that only happens once up front
gotta go take care of a food
MasterDuke those Ints from STORE for the 1m case are ~90% green 21:01
[Coke] what group of opcodes would 'getcodename' and 'setcodename' be under? (looking to add them to the docs)
github.com/Raku/nqp/blob/master/do...s.markdown
[Coke] just goes with misc for now. 21:10
lizmat timotimo: after your last commit, I see S10-packages/basic.t fail reliably 21:15
timotimo oh crap what
lizmat timotimo: do you see that as well? 21:16
timotimo i had a clean spec test run
lizmat lemme see if a configure.pl fixes it
MasterDuke just had a clean run here 21:21
timotimo could still be flappy 21:22
lizmat after a configure.pl it tests ok 21:23
what failed was: Failed tests: 47-48, 50 21:24
Geth_ nqp: 31e8d7d394 | Coke++ | docs/ops.markdown
add docs: iscoderef, getcodename, setcodename
 21:32
nqp: 4d88e3d3e7 | Coke++ | t/docs/opcodes.t
If a variant is doc'd for an opcode, that's OK.

For now, it's fine if "isle" is documented by "isle_i"
[Coke] wonders why the JS version of NQP has several variant opcodes that try harder to do unicode. Shouldn't they all try hard? 21:42
isne_snfg, iscclassnfg, etc.
Geth_ nqp: e70a759b40 | Coke++ | docs/ops.markdown
briefly doc some JS opcodes
 21:46
[Coke] tags pmurias on that commit. 21:47
down to 339 doc failures. gist.github.com/coke/325a98074f317...7266df7da4 is the list if anyone wants to steal some of the easy ones. :) 21:48
Geth_ roast: f67431adcc | (Elizabeth Mattijsen)++ | S03-sequence/exhaustive.t
Add some more tests with multiple endpoints
 22:10
22:15 lichtkind left, toddr joined 22:39 Altai-man_ joined 22:42 sena_kun left 23:05 Kaiepi left 23:09 Kaiepi 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!