🦋 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:15
MasterDuke joined
00:18
finanalyst left
07:22
ilogger2 left,
ilogger2 joined
|
|||||||||||||||||||||||||||||||||||||||
[Tux] |
|
07:42 | |||||||||||||||||||||||||||||||||||||
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log | |||||||||||||||||||||||||||||||||||||||
🐧 env MVM_JIT_EXPR_DISABLE=1 ./time-twice.pl | 07:47 | ||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||
(on request from lizmat) | |||||||||||||||||||||||||||||||||||||||
07:55
sena_kun joined
|
|||||||||||||||||||||||||||||||||||||||
patrickb | [Tux]: Is the first or the last the one without the exprjit? I'm confused, as the second numbers are lower across the board. | 08:11 | |||||||||||||||||||||||||||||||||||||
lizmat | yes, this is revealing: the first numbers are in line with what we've seen in the past months | 08:12 | |||||||||||||||||||||||||||||||||||||
the second set is with the exprjit disabled | |||||||||||||||||||||||||||||||||||||||
so at least for test-t, the exprjit is *not* a net gain | 08:13 | ||||||||||||||||||||||||||||||||||||||
patrickb | This is unexpected. We should have a few more measurements on different setups before taking a conclusion I guess. | ||||||||||||||||||||||||||||||||||||||
08:13
finanalyst joined
|
|||||||||||||||||||||||||||||||||||||||
[Tux] | Linux 5.14.21-150500.55.68-default [openSUSE Leap 15.5] HP Z2TowerG9WorkstationDesktopPC 13th Gen Core(TM) i7-13700K 3400MHz(24 cores) x86_64 64000 Mb | 08:14 | |||||||||||||||||||||||||||||||||||||
^^ these tests are run on that box | |||||||||||||||||||||||||||||||||||||||
patrickb | But we have at least a single datapoint where no exprjit is at least not tremendously slower. | ||||||||||||||||||||||||||||||||||||||
Tux: Thanks! | |||||||||||||||||||||||||||||||||||||||
[Tux] | yw | 08:15 | |||||||||||||||||||||||||||||||||||||
lizmat | additionally I was just thinking: that might be an additional reason why rakudo is faster on an M1 | ||||||||||||||||||||||||||||||||||||||
apart from the faster CPU | |||||||||||||||||||||||||||||||||||||||
patrickb | lizmat Can you run that code you used to compare M1 and Intel on the Intel machine with and without exprjit? | 08:20 | |||||||||||||||||||||||||||||||||||||
In addition interesting would be the timings without jit altogether. So MVM_JIT_DISABLE=1 | 08:21 | ||||||||||||||||||||||||||||||||||||||
lizmat | you mean the test-t code ? | ||||||||||||||||||||||||||||||||||||||
patrickb | Yes. I've just seen your GH message, so you already did! | 08:26 | |||||||||||||||||||||||||||||||||||||
[Tux] | 🐧 env MVM_JIT_DISABLE=1 ./time-twice.plRakudo v2024.06-16-ge0afa0a8c (v6.d) on MoarVM 2024.06-11-ged50e2c73 | 08:28 | |||||||||||||||||||||||||||||||||||||
csv-test-xs-20 0.143 - 0.144 | |||||||||||||||||||||||||||||||||||||||
csv-ip5xs 0.290 - 0.293 | |||||||||||||||||||||||||||||||||||||||
test-t --race 0.320 - 0.321 | |||||||||||||||||||||||||||||||||||||||
test-t 0.771 - 0.771 | |||||||||||||||||||||||||||||||||||||||
csv-ip5xs-20 1.581 - 1.591 | |||||||||||||||||||||||||||||||||||||||
csv-parser 1.840 - 1.898 | |||||||||||||||||||||||||||||||||||||||
test-t-20 --race 1.896 - 2.000 | |||||||||||||||||||||||||||||||||||||||
test 2.437 - 2.475 | |||||||||||||||||||||||||||||||||||||||
test-t-20 12.210 - 12.292 | |||||||||||||||||||||||||||||||||||||||
lizmat | ok, that's clear... JIT is a good thing | 08:29 | |||||||||||||||||||||||||||||||||||||
patrickb | It's nice that the timings align with our tentative plans. 😊 | 08:32 | |||||||||||||||||||||||||||||||||||||
lizmat | fwiw, rebooting the IRC logs server with MVM_JIT_EXPR_DISABLE=1 to get an idea of its long running behaviour | ||||||||||||||||||||||||||||||||||||||
typically, I only restart that process once a month or so, so by definition a long running process, that :-) | 08:33 | ||||||||||||||||||||||||||||||||||||||
nine | lizmat: I'd bet that the Apple chip's advantage wrt Rakudo is just the low latency high bandwidth memory access. I wouldn't be surprised if a CPU with large caches (think server CPUs) would show similar advantages. | 09:08 | |||||||||||||||||||||||||||||||||||||
lizmat | possibly... but the irc logs server is a 2015 iMac.. so more consumer oriented :-) | 09:09 | |||||||||||||||||||||||||||||||||||||
10:31
MasterDuke left
10:49
finanalyst left
11:39
rypervenche left
11:42
finanalyst joined
|
|||||||||||||||||||||||||||||||||||||||
nine | How on earth have we not noticed for years that the expr jit makes so many things slower rather than faster? | 11:49 | |||||||||||||||||||||||||||||||||||||
patrickb | I believe it didn't originally. We just don't have automated / regular perf tests with the different components en/disabled. Thus it's easy for changes to slip in that improve perf on an absolute measure, but decrease the effectiveness of the Jit. | 11:59 | |||||||||||||||||||||||||||||||||||||
lizmat | also, EXPR JIT predates new-disp, does it not? | 12:00 | |||||||||||||||||||||||||||||||||||||
patrickb | it does | ||||||||||||||||||||||||||||||||||||||
Also I believe exprjit is not inherently bad. We just managed to break it's perf win in some way. I totally believe we could in principle reclaim that perf win exprjit originally gave us. | 12:01 | ||||||||||||||||||||||||||||||||||||||
lizmat | so maybe new-disp provided many performance enhancements that drowned out anything EXPR JIT had to offer? | 12:02 | |||||||||||||||||||||||||||||||||||||
nine | I think the lego JIT has an advantage over the expr JIT by way of being able to de-virtualize. This may explain why the expr JIT generates slower code in many cases. | 12:03 | |||||||||||||||||||||||||||||||||||||
The other part of the explanation may be that while the lego JIT creates an abysmal amount of MOVs, those may not actually hurt as much as we thought as the cost of reading memory you just wrote may be offset almost completely by L1 caches in the CPU | 12:04 | ||||||||||||||||||||||||||||||||||||||
patrickb | Maybe it doesn't really matter. Should we actually plan to remove it, it's current performance plays into our hands. | 12:05 | |||||||||||||||||||||||||||||||||||||
nine | We could just flip the default for now | 12:08 | |||||||||||||||||||||||||||||||||||||
involved in the project. They will be our representative, a second pair of | 12:23 | ||||||||||||||||||||||||||||||||||||||
eyes that verifies your work. You would be required to report your | |||||||||||||||||||||||||||||||||||||||
activities to your manager on a monthly basis, which may be posted on our | |||||||||||||||||||||||||||||||||||||||
mis-paste, feel free to ignore | 12:24 | ||||||||||||||||||||||||||||||||||||||
patrickb | nine: I proposed an action plan over on github.com/MoarVM/MoarVM/issues/1817 | 12:28 | |||||||||||||||||||||||||||||||||||||
nine | looks quite sensible | 12:29 | |||||||||||||||||||||||||||||||||||||
Geth | rakudo/main: a7b41f730e | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod RakuAST: also disable "use" in syntax highlighting When it is for loading a module: pragmas *are* allowed. Also use a proper error class for error reporting. Passing the :unsafe flag *will* allow module loading in syntax highlighting |
13:00 | |||||||||||||||||||||||||||||||||||||
13:03
djinni` left
13:04
djinni` joined,
finanalyst left
13:05
patrickb left,
patrickb joined
|
|||||||||||||||||||||||||||||||||||||||
Geth | rakudo/main: 31336240d7 | (Elizabeth Mattijsen)++ | lib/RakuAST/Deparse/Highlight.rakumod RakuAST: also handle empty lines in syntax highlighting By treating them as a whole line comment |
13:29 | |||||||||||||||||||||||||||||||||||||
lizmat | m: sub a(Int) { dd }; a 1 | 2 # Junctions, yeah! | 16:56 | |||||||||||||||||||||||||||||||||||||
camelia | sub a(Int) sub a(Int) |
||||||||||||||||||||||||||||||||||||||
lizmat | m: sub a(int) { dd }; a 1 | 2 # I guess this is NYI, or is this intentional | 16:57 | |||||||||||||||||||||||||||||||||||||
camelia | This type cannot unbox to a native integer: P6opaque, Junction in sub a at <tmp> line 1 in block <unit> at <tmp> line 1 |
||||||||||||||||||||||||||||||||||||||
lizmat | m: use nqp; dd nqp::istype(int,Any) # yet int appears to be an Any | 16:59 | |||||||||||||||||||||||||||||||||||||
camelia | 1 | ||||||||||||||||||||||||||||||||||||||
[Coke] | is int really an Any or is it just automatically coerced to Int before the Any check? | ||||||||||||||||||||||||||||||||||||||
lizmat | that's why I used nqp::istype | 17:00 | |||||||||||||||||||||||||||||||||||||
the QAST doesn't show any upgrading: | |||||||||||||||||||||||||||||||||||||||
│ │ - QAST::Op(istype) :statement_id<2> nqp::istype(int,Any) | |||||||||||||||||||||||||||||||||||||||
│ │ - QAST::WVal(int) int | |||||||||||||||||||||||||||||||||||||||
│ │ - QAST::WVal(Any) Any | |||||||||||||||||||||||||||||||||||||||
[Coke] | my int $a = 1; my int $b = 2; sub a(int) {dd}; a $a|$b # also fails | 17:07 | |||||||||||||||||||||||||||||||||||||
m: my int $a = 1; my int $b = 2; sub a(int) {dd}; a $a|$b # also fails | |||||||||||||||||||||||||||||||||||||||
camelia | This type cannot unbox to a native integer: P6opaque, Junction in sub a at <tmp> line 1 in block <unit> at <tmp> line 1 |
||||||||||||||||||||||||||||||||||||||
[Coke] | (was hoping the vars might work where the literals failed) | 17:10 | |||||||||||||||||||||||||||||||||||||
18:16
finanalyst joined
18:24
lizmat_ left,
lizmat joined
18:37
nativecallable6 left
18:38
nativecallable6 joined,
djinni` left
18:41
sourceable6 left,
sourceable6 joined
18:44
linkable6 left,
linkable6 joined
|
|||||||||||||||||||||||||||||||||||||||
ab5tract | But junctions aren’t Any? | 18:45 | |||||||||||||||||||||||||||||||||||||
m: use nqp; nqp::istype(1|2,Any) ==> say(); nqp::istype(1|2,Mu) ==> say() | |||||||||||||||||||||||||||||||||||||||
camelia | 0 1 |
||||||||||||||||||||||||||||||||||||||
ab5tract | Maybe I’m missing the point entirely though… junctions are well outside my wheelhouse | ||||||||||||||||||||||||||||||||||||||
lizmat | Junctions are a sibling of Mu as it where | 18:46 | |||||||||||||||||||||||||||||||||||||
that is why we have Mu and Any | |||||||||||||||||||||||||||||||||||||||
when a sig cannot bind the junction to an argument, then in the error handling if the offending type is a Junction, and then do the right thing | 18:47 | ||||||||||||||||||||||||||||||||||||||
18:47
greppable6 left,
greppable6 joined
|
|||||||||||||||||||||||||||||||||||||||
lizmat | so that the check for junction doesn't interfere with normal dispatch | 18:47 | |||||||||||||||||||||||||||||||||||||
*check if | |||||||||||||||||||||||||||||||||||||||
18:49
djinni` joined
18:50
notable6 left,
notable6 joined
|
|||||||||||||||||||||||||||||||||||||||
Geth | rakudo/main: c7af1953ce | (Elizabeth Mattijsen)++ | 2 files RakuAST: several highlighting related fixes - added some missinh highlighting logic - joined cap-named and cap-positional into a single capture-xxx group |
18:51 | |||||||||||||||||||||||||||||||||||||
20:08
samebchase left
20:09
samebchase joined
|
|||||||||||||||||||||||||||||||||||||||
[Coke] | anyone remember the github ticket for getting rakudoc viewer support? | 21:28 | |||||||||||||||||||||||||||||||||||||
ab5tract | lizmat: then I guess I’m just confused as to what the relevance of int being istype of Any has to do with junctions not working there | 22:01 | |||||||||||||||||||||||||||||||||||||
I | 22:02 | ||||||||||||||||||||||||||||||||||||||
I guess iint being Any implies that it should go through the existing bind failure junction resolution mechanism you described? | 22:05 | ||||||||||||||||||||||||||||||||||||||
lizmat | yes, that would be my expectation... but I guess it being a native type probably precludes that | 22:11 | |||||||||||||||||||||||||||||||||||||
23:04
sena_kun left
|