🦋 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] Rakudo v2024.06-16-ge0afa0a8c (v6.d) on MoarVM 2024.06-11-ged50e2c73
csv-ip5xs0.265 - 0.269
csv-ip5xs-201.191 - 1.199
csv-parser1.562 - 1.596
csv-test-xs-200.141 - 0.145
test2.003 - 2.022
test-t0.429 - 0.440
test-t --race0.284 - 0.290
test-t-205.446 - 5.803
test-t-20 --race1.323 - 1.338
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
Rakudo v2024.06-16-ge0afa0a8c (v6.d) on MoarVM 2024.06-11-ged50e2c73
csv-ip5xs0.262 - 0.265
csv-ip5xs-201.118 - 1.149
csv-parser1.474 - 1.537
csv-test-xs-200.141 - 0.142
test1.902 - 1.910
test-t0.407 - 0.407
test-t --race0.266 - 0.279
test-t-204.828 - 5.039
test-t-20 --race1.235 - 1.278
(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: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
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
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
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