🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 reportable6 left, reportable6 joined 04:20 Xliff joined
Xliff Raku-GLib suite timing statistics for Raku 2023.02.17.g.95.e.0.a.1783 04:21
Total number of projects: 33 (502933 loc)
Total non-parallel compile times: 8706.870 (263.845 avg)
Total parallel compile times: 1393.242 (42.219 avg) 6.249x speedup
4th best parallel time recorded since March 2022! 04:23
06:00 reportable6 left 06:02 reportable6 joined 06:47 Xliff left 07:48 ab5tract left 08:42 sena_kun joined
Geth rakudo/main: 188beb5562 | (Elizabeth Mattijsen)++ | src/core.c/Range.pm6
Return correct Bool for infinite ranges

Better fix for github.com/rakudo/rakudo/issues/5222		 09:41
09:42 evalable6 left, linkable6 left 09:43 evalable6 joined 09:44 linkable6 joined
Nemokosch now that this is kind of a hot topic, let me throw this in github.com/rakudo/rakudo/issues/5143 09:47
another elems issue
Geth rakudo/main: 53135c8d37 | (Elizabeth Mattijsen)++ | src/core.c/Range.pm6
Properly fix (1..*).Bool

Initially thinking about using self.Seq.head !=:= Nil, than decided to use the more direct .iterator.pull-one instead. Means the value to check is IterationEnd, not Nil.
Should have written the tests first :-(		 09:53
roast: 040622c267 | (Elizabeth Mattijsen)++ | S02-types/range.t
Add Range.Bool tests

Related to github.com/rakudo/rakudo/issues/5222
rakudo/main: e9f438f5aa | (Elizabeth Mattijsen)++ | 6 files
RakuAST: add support for "our constant foo = 42"

  - introduce RakuAST::VarDeclaration::Constant class
  - remove specific stopper from grammar
  - adapt type_declarator:sym<constant> accordingly
  - add deparsing / raku logic
  - add basic tests		 10:32
lizmat sadly, didn't gain any additional tests 10:33
10:35 nine_ left, nine joined 10:50 epony left 10:51 epony joined 10:56 epony left, epony joined 12:00 reportable6 left 12:02 reportable6 joined 12:10 ab5tract joined 13:46 evalable6 left, linkable6 left 13:47 linkable6 joined 13:49 evalable6 joined 16:06 ab5tract left 16:27 lizmat_ joined 16:32 lizmat_ left 16:33 lizmat_ joined 16:36 committable6 left, quotable6 left, coverable6 left, shareable6 left, bisectable6 left, lizmat left, sjn left, rypervenche left 16:37 Xliff joined, committable6 joined, quotable6 joined, coverable6 joined, shareable6 joined, bisectable6 joined, sjn joined, rypervenche joined 16:46 lizmat_ left 16:47 lizmat joined 17:09 vrurg_ left 17:10 vrurg joined 18:00 reportable6 left 18:02 reportable6 joined 18:25 AlexDaniel joined, epony left 18:42 AlexDaniel left 18:56 AlexDaniel joined
AlexDaniel please feel free to file this performance ticket on my behalf: gist.github.com/AlexDaniel/d651dd9...25af11d30e 18:57
(cuz I can't file tickets in rakudo)
18:59 epony joined 19:21 MasterDuke joined 19:46 squashable6 left
Nemokosch how would you like it to be converted into an actionable issue? 19:46
19:48 squashable6 joined
Voldenet if you're looking for optimization chance, bigger perf issue is that `for ^1000 { .WHERE.say };` will display different address every time 20:09
and this can be optimized without dealing with `Int` vs `int` problem 20:10
tonyo i think he's looking to make the coerced types faster
alex mentions there's obvious optimizations 20:11
Voldenet probably there are some 20:13
but still I wish raku was able to reuse memory a bit more 20:14
MasterDuke isn't the int vs uint different (in addition to int vs Int) something to look into? that might be lower hanging fruit 20:22
tonyo that was the point of the gist, i think 20:23
[Coke] doesn't surprise that a subset is less effective than a native in general. 20:25
MasterDuke ah, but uint is a native. UInt is the subset
Nemokosch > bigger perf issue is that for ^1000 { .WHERE.say }; will display different address every time however, in that case, you might actually have a fully-blown, writeable container 20:26
while this is not an option with -> $i 20:27
[Coke] (subset) oops
Nemokosch yes, uint and int is strange the least to say... 20:28
[Coke] yes, .WHERE can change
(even if it was the same variable each time with $i, it could still change then, depending on GC) 20:29
Nemokosch when we talked about it a bit earlier, it really came as a surprise that we didn't get similar benchmarking results; then it turned out the big win only came with int
the big question is - can we even inspect if a variable is int or uint? 20:31
MasterDuke m: use nqp; say nqp::objprimspec(int); say nqp::objprimspec(uint) 20:33
camelia 1
10
MasterDuke fwiw, i believe the int v uint is something to do with iterating ranges 20:35
Nemokosch m: my uint $asd; use nqp; say say nqp::objprimspec($asd)
Raku eval 0 True
Nemokosch oops
anyway, it's not really informative 20:36
MasterDuke `my class IntRange does PredictiveIterator {` from src/core.c/Rakudo/Iterator.pm6:2115 might need looking into for a uint version
and then figuring out how/when to use the new uint one instead 20:39
21:05 Xliff_ joined 21:07 Xliff left
Voldenet >you might actually have a fully-blown, writeable container 21:11
I don't disagree, but this should be supported as a special case
21:11 Xliff_ left
Voldenet most loops just iterate over the collection 21:12
or other iterable, which could control how (and if) loops will allocate 21:13
21:16 shmup left
Nemokosch anyway, the situation is more fortunate when you predictably have a read-only variable 21:22
AlexDaniel actually, my point is that in all cases the performance should be the same. Feel free to split it into different tickets but yeah. 21:38
just because you have a bigint somewhere doesn't mean that the performance can be more than 10x slower 21:39
bigints are not 10x slower themselves… or are they?
Nemokosch well, I can very well imagine that with division they are... 21:42
AlexDaniel press x to doubt :)
and, more importantly, it seems that if you fix the loop variable performance, then you might as well beat python in most simple tasks 21:43
adding more native ints in that example does improve anything, it's just the loops
does not* 21:44
Nemokosch I mean it's sort of obvious that if you evaluate something many times, your mileage will vary more 21:56
AlexDaniel ?
Nemokosch "the loops" probably only serve as an amplifier 21:57
22:12 shmup joined 23:03 sena_kun left 23:30 NemokoschKiwi 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!