🦋 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 |