🦋 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:03 reportable6 joined 00:37 nine left, nine joined 01:37 quotable6 left, benchable6 left, linkable6 left, committable6 left, notable6 left, squashable6 left, nativecallable6 left, unicodable6 left, reportable6 left, coverable6 left, bloatable6 left, shareable6 left, releasable6 left, tellable6 left, sourceable6 left, greppable6 left, statisfiable6 left, bisectable6 left, evalable6 left 01:38 sourceable6 joined, committable6 joined, unicodable6 joined, evalable6 joined, notable6 joined 01:39 quotable6 joined, reportable6 joined, tellable6 joined, nativecallable6 joined, benchable6 joined 01:40 bisectable6 joined, statisfiable6 joined, linkable6 joined, shareable6 joined, bloatable6 joined, squashable6 joined 01:41 releasable6 joined, coverable6 joined, greppable6 joined 02:11 nine left, camelia left 02:12 camelia joined, nine joined 03:43 linkable6 left, evalable6 left 03:44 evalable6 joined 03:45 linkable6 joined 04:00 frost joined 06:03 reportable6 left 06:04 reportable6 joined 09:13 evalable6 left, linkable6 left 09:14 evalable6 joined, linkable6 joined 10:36 evalable6 left, linkable6 left 10:38 linkable6 joined 10:39 evalable6 joined
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/06/22/2021-...all-steps/ 11:57
with apologies for being 1 day late 11:58
12:02 reportable6 left 12:05 reportable6 joined 12:10 frost left
Altai-man lizmat++ # thanks a lot! 12:33
13:54 frost joined 14:20 frost left 17:21 melezhik joined
melezhik .tell lizmat maybe I am missing the point, however my tests do not show performance increase for twitter.com/liztormato/status/1397...8448548864 , see gist.github.com/melezhik/26d77b06b...c978768e20 17:22
tellable6 melezhik, I'll pass your message to lizmat
melezhik oh, maybe I just test it wrong ...))) 17:23
the last comment in gist 17:25
18:03 reportable6 left 18:04 reportable6 joined
lizmat melezhik: maybe because github.com/rakudo/rakudo/commit/0d...d69cba1b47 makes that basically happen automatically now ? 18:26
melezhik lizmat: I mean I tested this against various Rakudo versions and they all give comparable times ... 18:29
lizmat what is the exact check that you use ? 18:30
melezhik gist.github.com/melezhik/b291f58fb...346ab0b97e 18:32
it's seen in report
maybe is too naive but `time $RAKUBIN -e 'my $txt = slurp "/usr/share/dict/words"; for (1..10) { my (@m) = $txt.grep( { m:i/ <!after i> e / } ) }'`
and then just compare times 18:33
oh, may be I just need to increase loop, to eliminate rakudo start time factor ? so that we see the ration for big times ? 18:35
lizmat so what is the other code ? 18:36
melezhik other?
lizmat that version, versus a version that uses .contains ? 18:37
melezhik oh .contain, I missed the point, sorry ))) 18:38
let me change my test, sure
lizmat :-) 18:41
melezhik I took as old grep.regexp should work faster ... 18:44
now looks good to me - gist.github.com/melezhik/b291f58fb...nt-3789308 18:45
lizmat and with .grep( /:i <!after i> e / ) ? 18:46
that should be a little faster still ?
melezhik you see both times in one case 18:47
report formatting is not perfect, but you want to see in between 'grep' .. 'end' - "standard" version and 'grep.containts' 'end' - improved, faster version 18:48
I'd tweak my test so it compares times and fails if the grep.contains version time is bigger then grep.({}) time 18:49
> that should be a little faster still ? - I guess it is, if you talk about older Rakudo versions 18:50
you can always run this by r3 :] this is why the tool exists
gist.github.com/melezhik/8a74d4b45...0b08367339 19:05
lizmat I think that you will find that the .contains performs relatively better on a regex that isn't as expensive 19:07
melezhik so, to make it clear, "Make .grep(Regex) and .first(Regex) about 40% faster" what should we measure here? times for different rakudo versions or? 19:08
I guess `grep(.*contains)` is not relevant for github.com/rakudo/rakudo/pull/4383 right? 19:09
lizmat also, I think the original benchmark was more about checking each word in the list, rather than checking whether there is *a* word 19:10
indeed, you might want to check a before the merge and after ? 19:11
melezhik I do ... I use 2020_12 against 2021_06 ...
lizmat ok 19:12
melezhik if you tell me the correct code for check
lizmat :-), sorry am a bit distracted with other stuff happening
melezhik NP
I was under impression that original twitter code is good for test - `my $txt = slurp "/usr/share/dict/words"; for (1..1000) { my (@m) = $txt.grep( { m:i/ <!after i> e / } ) }` , right? 19:13
lizmat .grep( /:i <!after i> e / )
melezhik ok 19:14
lizmat only *then* are you passing a Regex as the test to .grep
{ m:i/ <!after i> e / } is passing a Callable
melezhik ok, I see 19:15
let me modify test
lizmat - gist.github.com/melezhik/a147c176b...eded5cb864 20:43
I am still not sure why 2020_12 beat 2021_06 in that test ... 20:44
MasterDuke i believe the new coercion protocol was merged after 2020_12 and that caused some slowdowns in a lot of places. 2021_05 would likely be slower than 2021_06 20:52
melezhik it's easy to check with r3 tool 20:53
let me do this
weird, but 2021_05 appears to be faster then 2021_06 - gist.github.com/melezhik/a147c176b...nt-3789446 20:57
or I miss something in my test 20:58
lizmat Built on MoarVM version 2021.05. vs Built on MoarVM version 2021.06 ?? 21:06
MasterDuke c: HEAD say lines().elems 21:08
committable6 MasterDuke, ¦HEAD(37dd25f): «10␤»
MasterDuke c: HEAD say lines.join.chars 21:09
committable6 MasterDuke, ¦HEAD(37dd25f): «490␤»
MasterDuke c: HEAD my $t = lines.join; $t.grep( /:i <!after i> e / ) for 1..1000; say now - INIT now 21:11
committable6 MasterDuke, ¦HEAD(37dd25f): «0.130523028␤»
MasterDuke c: HEAD my $t = lines.join; $t.grep( /:i <!after i> e / ) for 1..10_000; say now - INIT now
committable6 MasterDuke, ¦HEAD(37dd25f): «0.92320538␤»
MasterDuke c: 2021.05,2021.06 my $t = lines.join; $t.grep( /:i <!after i> e / ) for 1..50_000; say now - INIT now
committable6 MasterDuke, ¦2021.05: «4.686483287␤» ¦2021.06: «4.081395001␤» 21:12
MasterDuke c: HEAD my $t = lines.join; $t.grep( /:i <!after i> e / ).elems.say
committable6 MasterDuke, ¦HEAD(37dd25f): «1␤»
MasterDuke c: HEAD my @t = words; @t.grep( /:i <!after i> e / ).elems.say 21:14
committable6 MasterDuke, ¦HEAD(37dd25f): «1␤»
MasterDuke c: 2021.05,2021.06 my @t = words; @t.grep( /:i <!after i> e / ) for 1..50_000; say now - INIT now 21:15
committable6 MasterDuke, ¦2021.05,2021.06: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»»
MasterDuke c: 2021.05,2021.06 my @t = words; @t.grep( /:i <!after i> e / ) for 1..1_000; say now - INIT now
committable6 MasterDuke, ¦2021.05: «1.178698748␤» ¦2021.06: «0.830773224␤»
Altai-man releasable6, status 21:16
releasable6 Altai-man, Next release in ≈30 days and ≈21 hours. 1 blocker. Changelog for this release was not started yet
Altai-man, Details: gist.github.com/23f353c67303b16989...d5c5dac01f
MasterDuke so committable6 thinks 2021.06 is faster
benchable6: 2021.05,2021.06 my @t = words; @t.grep( /:i <!after i> e / ) for 1..1_000 21:17
benchable6 MasterDuke, starting to benchmark the 2 given commits
MasterDuke, ¦2021.05: «1.2089» ¦2021.06: «0.9567»
MasterDuke, benchmarked the given commits and found a performance difference > 10%, now trying to bisect
MasterDuke, benchmarked the given commits and found a performance difference > 10%, now trying to bisect 21:18
MasterDuke, ¦2021.05: «1.2089» ¦faec804: «0.9722» ¦48de177: «0.9487» ¦2021.06: «0.9567»
MasterDuke benchable6: 2021.05,2021.06 my @t = words; @t.grep( *.contains(/:i <!after i> e /) ) for 1..1_000 21:20
benchable6 MasterDuke, starting to benchmark the 2 given commits
MasterDuke, ¦2021.05: «1.1604» ¦2021.06: «1.1165»
MasterDuke, No new data found
melezhik MasterDuke hm. I 21:26
lizmat sleep&
melezhik I have rewritten the test using `now - INIT now`, still 2020_05 is faster then 2021_06, strange ... - gist.github.com/melezhik/a147c176b...eded5cb864 21:27
^^ MasterDuke
gist.github.com/melezhik/a147c176b...nt-3789473 21:28
MasterDuke well, committable6 has a small text it working against. so maybe whether it matches or not many times makes a difference
i.e., 2021.06 is faster when it doesn't match frequently, but 2021.05 is faster when it does? 21:29
melezhik I don't know I use dictionary installed as `yum install words` in my centos ... at least what I can tell 21:30
how can I get committable6 words? btw 21:33
MasterDuke c: HEAD words.say 21:36
committable6 MasterDuke, gist.github.com/0d5699f14e90c14371...1babbdae37
MasterDuke it's just a bunch of random-ish stuff i believe 21:37
AlexDaniel c: HEAD words.grep(/\w/).say 21:39
committable6 AlexDaniel, ¦HEAD(37dd25f): «(hello world 4𝟮)␤»
AlexDaniel c: HEAD say +words 21:40
committable6 AlexDaniel, ¦HEAD(37dd25f): «100␤»
AlexDaniel c: HEAD say +lines
committable6 AlexDaniel, ¦HEAD(37dd25f): «10␤»
AlexDaniel not entirely random :)
but yes
perhaps too unicodey 21:41
committable6: stdin hello world this is just some normal text
committable6 AlexDaniel, STDIN is set to «hello world this is just some normal text»
AlexDaniel c: HEAD dd words
committable6 AlexDaniel, ¦HEAD(37dd25f): «("hello", "world", "this", "is", "just", "some", "normal", "text").Seq␤»
AlexDaniel 😌
melezhik Uploaded file: uploads.kiwiirc.com/files/70194ef8...pasted.txt 21:43
MasterDuke 2021_06 is still slower then 2021_05 for committable6 words - gist.github.com/melezhik/a147c176b...nt-3789490 21:44
MasterDuke huh. maybe moarvm compilation options? OS or compiler differences? 21:45
melezhik I can add diag info to test, but these are whatevetable: distros
I run on the same environment btw 21:46
the same docker container
MasterDuke yeah, it might just be some difference between how the whateverable builds are built and how your containers are built 21:50
melezhik I don't know, but why does this matter, I assumed that claimed performance increase should be invariant for a target environment? 21:52
btw anyone could spin up r3 and test it on their laptop/whatever , it's dead easy 21:53
anyway ... interesting )))
22:32 guifa joined
guifa Okay, so first time wanting to use roast to check to make sure my Dateish work doesn't mess anything up. I'm seeing several varieties of 'fudge'. Is that what I'll use to run all of the tests? 22:35
[Coke] Are you running the tests from a rakudo build? If so 'make spectest' works. 22:36
(that'll do all the magic to run the tests)
Or do you have a pre-installed rakudo that you want to run against a standalone roast?
guifa Wanting to run the tests from a local build of Rakudo 22:39
[Coke] try "make spectest" or "make stresstest" 22:41
that should checkout roast, update it, and run all the tests.
(stress runs the longer running tests also)
22:41 melezhik left
guifa Hrm. Dangit, error on building MoarVM. 22:45
[Coke]: Error while compiling, type X::Declaration::OurScopeInRole 22:56
declaration: constant
at line 58198, near ";\nconstant"
[Coke] O_o; 22:57
are you building moarvm by itself or as a result of "perl Configure.pl" in a rakudo checkout?
that string "X::Declaration::OurScopeInRole" isn't in the MoarVM source, I don't think. 22:58
I do see it in Rakudo source, though. 22:59
afk
guifa Part of the make after perl Configure.pl 23:01
Geth rakudo: codesections++ created pull request #4425:
Fix unimatch for non-base properties		 23:22
23:25 m6502 joined
Geth rakudo/master: 5 commits pushed by (Vadim Belman)++ 23:38
roast/master: 4 commits pushed by (Vadim Belman)++

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!