🦋 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.
elcaro Ack, I was bitten by Issue 4757 again today. Can someone review my suggested fix. I can submit a PR if it's ok, but maybe there's a smarter way to fix. 00:31
The issue might better be decribed as `METAOP_REVERSE strips assoc` 00:32
01:45 epony joined
releasable6 Next release in ≈1 day and ≈15 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
MasterDuke elcaro: does the problem still exist with rakuast? 03:51
elcaro oh, I didn't check that. 04:00
1 sec
No such method 'reducer-name' for invocant of type 'RakuAST::MetaInfix::Reverse' 04:02
08:43 [Tux] left 08:48 [Tux] joined
ab5tract intriguing 09:07
R#4757 09:08
linkable6 R#4757 [open]: github.com/rakudo/rakudo/issues/4757 List.reduce doesn't take right-associativity of reverse operators into account
10:01 sena_kun joined 10:05 MasterDuke left
lizmat ok, this is weird (I think): 11:57
m: say (^Inf).grep(*.is-prime).skip(999999).head
camelia 15485863
lizmat so, on my M1 this takes 5.38 wallclock *and* 5.39 CPU 11:58
m: say (^Inf).hyper(batch => 4096).grep(*.is-prime).skip(999999).head
camelia 15485863
lizmat so this takes 1.22 wallclock and 2.79 CPU 11:59
I get the faster wallclock
what I do *not* get, is why the hypered version takes *LESS* CPU 12:00
on an Intel, I see similar numbers (relatively speaking)
possible reason: the "time" command is not calculating all CPU correctly? 12:01
if I run with a snapper, I see similar values, so if that's the reason, there's something amiss at a deeper level 12:02
hmmm it gets weirder 12:15
m: say (^Inf).grep(*.is-prime).skip(999999).head; say now - ENTER now 12:16
camelia 15485863
4.536529415
lizmat m: say (^Inf).hyper(batch => 4096, degree => 1).grep(*.is-prime).skip(999999).head; say now - ENTER now
camelia 15485863
2.22983166
lizmat so: hypering on a single CPU is 2x as fast as not hypering ??? 12:17
this doesn't make sense to me? Unless we have some massive overhead in the non-hypering code path ? 12:18
12:54 epony left
ab5tract okay that's wild 12:59
lizmat could you verify these numbers ? 13:01
ab5tract sure, let me build latest first 14:00
ugexe Hyperthreading is a thing 14:49
lizmat ugexe: elaborate ? 14:54
ugexe It is not unexpected that a single cpu can run more threads than the cores it provides to achieve max efficiency 15:24
hyperthreading has been around forever and is one example of why one shouldn’t expect 1 cpu to do best with just 1 thread
en.m.wikipedia.org/wiki/Hyper-threading 15:26
Pretty much any intel cpu will advertise itself as I.e. 2 cores 4 threads
lizmat hmmmm 15:33
we're already running with 2 threads already: the spesh thread and the main thread 15:35
so why don't we see any improvement normally ?
m: start { (^10).race.map(&die) }; sleep 3 # anyone has an explanation why this doesn't die ? 15:59
camelia ( no output )
lizmat m: (^10).race.map(&die) 16:00
camelia ===SORRY!===
0
jdv vrurg: github.com/rakudo/rakudo/issues/5502 16:17
ugexe Maybe it doesn’t get sunk with start 16:18
m: start { $ = (^10).race.map(&die) }; sleep 3 16:20
camelia ( no output )
ugexe m: start { (^10).race.map(&die).sink }; sleep 3
camelia Unhandled exception in code scheduled on thread 6
A worker in a parallel iteration (hyper or race) initiated here:
in block at <tmp> line 1

Died at:
0
lizmat ah, yeah, duh :-) 16:21
19:57 notna joined
jdv lizmat: if vrurg cant get the blin issues reslved today you think we do the release or not? 20:03
20:06 melezhik joined 20:12 melezhik left 21:06 notna left 21:39 epony joined 22:07 epony left 22:15 |Tux| left 22:18 |Tux| joined 22:21 epony joined
releasable6 Next release in ≈19 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
vrurg jdv: busy day today, still hoping for tonight to have a look at these. 23:24
23:30 sena_kun left
lizmat jdv: I would be leaning towards a release 23:46