github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:26 reportable6 left, releasable6 left, shareable6 left, squashable6 left, bloatable6 joined
timotimo it would be cool if we could somehow vectorize the validator at least a little bit 00:26
00:26 reportable6 joined 00:27 squashable6 joined, benchable6 joined, quotable6 joined
timotimo the bytecode validator 00:27
00:27 evalable6 joined, notable6 joined 00:28 releasable6 joined, unicodable6 joined 00:29 greppable6 joined 00:30 shareable6 joined, committable6 joined, coverable6 joined, nativecallable6 joined, statisfiable6 joined 00:31 tellable6 joined
timotimo seems to be just a little faster to go through the input string once to decide whether to do 32bit or 8bit writing up front in the latin1 decoder 00:42
at least in terms of startup time for the "say 0.1+0.2-0.3" test case
my naive assumption is that fetching the entire input string once up front and doing a cheap calculation on it is entirely blocked on getting the data 00:44
except i break off early if i find a single outside-of-ascii character
00:44 ggoebel joined
timotimo i somehow totally broke it, though 01:01
01:04 hoelzro left 01:20 lucasb left 04:16 ZzZombo_ joined 04:20 ZzZombo left, ZzZombo_ is now known as ZzZombo 04:35 ZzZombo_ joined 04:38 ZzZombo left, ZzZombo_ is now known as ZzZombo 06:28 domidumont joined 07:26 brrt joined
brrt \o 07:26
lizmat: rurban cannot, in fact, elaborate on why the expression JIT is horrible
(I should rather say, has never been able to elaborate) 07:27
nwc10 o/
brrt ohai nwc10
08:19 brrt left 08:24 sena_kun joined 09:01 brrt joined
jnthn brrt: I would ignore him; by this point I tend to take his disagreeing with something I'm doing as a sign that I'm doing it right. :) 09:58
nwc10 That reminds me, but I'm not sure if I should name the other person who has said pretty much exactly that. 10:00
brrt :-) 10:01
nwc10 It wasn't djb: twitter.com/hashbreaker/status/795...5490603009 10:02
brrt hmm, who here renembers what test case was failing when we added the sp_bind_o expr JIT 10:12
nwc10 does not, but assuming that it was reverted, surely git should remember for us
ahd if the commit doesn't say, then it's LTA 10:13
brrt 'twas reverted yes 10:17
10:18 patrickb joined
brrt I see the revert but the commit msg doesn't specify the test case 10:19
oh well
nwc10 naughty human!
(whoever it was)
and I"m purposefully not looking
brrt hehe 10:21
Guest13443 brrt: colabti.org/irclogger/irclogger_lo...2019-09-15 10:31
more specifically: colabti.org/irclogger/irclogger_lo...09-15#l416 10:34
brrt | nine: can you replicate the/an issue with t/spec/S32-temporal/DateTime.t ? 10:35
10:37 sena_kun left
brrt thank you 10:37
10:38 sena_kun joined
brrt hmm, 10:38
that doesn't fail now :-(
timotimo hilarious 10:51
Guest13443 brrt: perhaps you need a smaller nursery 10:53
brrt oh, yeah, that 11:04
ok, let's try
all tests succesful :-( 11:05
timotimo hey brrt 11:06
brrt hey timotimo 11:07
the thing I like least about MoarVM work is the heisenbugs
timotimo: it is in fact, the sp_p6oget_bi that breaks the test
timotimo MVM_jit_tile_state_lookup is relatively high up on the list when sorted by "self", is there anything obviously optimizable about it? or is it perhaps going to be made replaced at some point?
brrt let me see about that 11:08
nwc10 brrt: I don't get "it is in fact, the sp_p6oget_bi that breaks the test" - does this mean that sp_p6oget_bi is buggy, but one doesn't get to hit *that* bug unless sp_bind_o can be JITted? 11:09
timotimo out of the 830.9mil cycles estimated, 120mil are inclusive in MVM_jit_compile_graph, 113.9mil inclusive in MVM_jit_compile_expr_tree
this is for "perl6 -e 'say 0.1+0.2-0.3'
brrt it means that sp_p6oget_bi needs to be in the set, before there's an error
timotimo "
brrt oh, that's actually quite a bit
timotimo it's not so bad, since it's on a separate thread 11:10
brrt a oneliner is kind of a worst-case scenario
for the JIT
but
still
timotimo yeah
brrt I hadn't excpected
timotimo with spesh disabled it's just below 500mil cycles
are you interested in a screenshot of the "all callees" of MVM_jit_compile_graph as kcachegrind shows it? 11:11
or maybe just the callgrind output file
though the line numbers in the source code view won't resolve i don't think
brrt interested, yes 11:13
I'm not sure I can do something actionable, but sure, interested
so, MVM_jit_tile_state_lookup is a binary search
we could change that into a hash lookup
we could even change that into a perfect hash lookup, since we know the full set of legal keys
discord6 <timotimo> cdn.discordapp.com/attachments/557...nknown.png
timotimo that'll have to become a whole lot faster if it's to make a big difference 11:14
brrt actually, 15 million cycles, whereas tree traversal takes 60 million cycles? 11:15
inclusive
timotimo right
brrt oh, we're interested in the self
timotimo i just thought "state lookup sounds cheaper than how much it costs hear"
i don't actually know what each function does 11:16
brrt yeah, it should be cheap, that's the thing
timotimo so in the source code view i can see which it takes most often
but it's probably not that interesting 11:17
it's the second-to-last else-if, fwiw
4.4mil hits on mid = (top + bottom) / 2, 1.7mil hits on "mid = (top + bottom / 2)" in the last else-if
of course since i don't know how exactly all this is compiled, it might not actually say much :) 11:18
surely factoring out the mid = top + bottom / 2 out of the if/else-if won't make a difference when we're already compiling with optimizations 11:19
brrt I'd think not 11:21
so, perfect hash function, is what I'm thinking
now I need to study and figure out how these work :-D
timotimo yesterday i was looking if there's any perfect hash function thingie i can just run in the browser
brrt maybe there's a CPAN module 11:22
timotimo y u no perfect hashing irc bot 11:23
if you figure out perfect hashing, maybe you can also use it for MVM_op_get_mark 11:28
i made that a bunch faster by turning it into a two layers deep nested if 11:29
it's still got 4.7mil in that test case 11:30
(all from the bytecode validator)
brrt bug found in the expr jit precompiler 11:47
the tl;dr - macros can't return flags according to the type checker, that's no good
in other news, I'm sort-of seriously considering using raku for a new project 11:49
nwc10 on the JVM where no-one will notice? 11:50
until it's too late :-)
timotimo so the flag value probably got lost when including the template result in the tree? 11:51
brrt i think that's why you chose to have the ^bigint_is_smallint macro return a flagval, rather than just the 'eq' 11:57
and it may be the case that `flagval` returns a 1 byte value, that has to be explicitly upcast 11:58
timotimo in any case there's a fix coming :) 11:59
or at least that's my interpretation of the issue 12:01
brrt stuff is a hypothesis at this stage 12:02
12:04 sena_kun left
brrt wikipedia has articles 12:05
but I already see mod... and if there's any thing I know, it's that div is sloooow
timotimo oh, you're talking about perfect hashing? 12:06
brrt as well.... i'm not very focussed 12:09
I'm waiting for a big compile job at $work
12:10 sena_kun joined, ggoebel left
brrt ok, so, wanna know the problem 12:13
(the subproblem, I don't claim to have solved the greater test-failure problem yet)
timotimo ha 12:14
brrt - we must link declarations ('let:') syntax before applying macros, because otherwise macros could introduce naming conflicts
- in order to link declarations, we need to transform the 'let:' node into either a 'do' or 'dov' node 12:15
- in order to choose between those, we need to find out the type of the last expression
- in order to do that, we walk the tree, but we don't know what the macro's resolve to, so we assume they are registers 12:16
- that means that 'if' sees a register when it expects a flag
maybe there is a simple dumb fix that will make progress...
timotimo mhhh 12:17
brrt this could be resovled if we differentiate syntactically between 'let-yielding-value' and 'let-void' 12:18
which looks increasingly like the right way to go.... 12:20
12:33 lucasb joined
brrt ok, that makes it compile again, at least 12:34
Geth MoarVM: 76cd034ae3 | (Bart Wiegmans)++ | 2 files
[JIT] Syntactically distinguish let keyword variants

The 'let' keyword expands to a 'do' or 'dov' list of declarations, depending on whether the last statement returns a value or not. However, we need to expand declaration references before applying macros, because macro application could theoretically introduce name conflicts otherwise. Hence, type-checking the 'let' expression during declaration linking isn't actually possible, because we don't know the types of macro expressions. Instead, introduce the syntactic variant
  'letv' that makes the result type explicit.		 12:41
MoarVM: 27dcb378ef | (Bart Wiegmans)++ | src/jit/core_templates.expr
Revert "The exprjit of sp_bind_o caused wrongness"

This reverts commit 72befa1647f732705998ae4d9d2dfdc796b34f21.
MoarVM: 91d53ae7f4 | (Bart Wiegmans)++ | 2 files
Revert "Revert "exprjit sp_p6oget_bi""

This reverts commit 986e05beab2845ec5e29672aadb739170a645e17.
brrt hang on, didn't mean to push those :-o
gimme a sec
I can't force-push the commits away because master is protected 12:44
timotimo: can you force-push or revert the last two commits?
Guest13443 brrt: did you just fix the sp_bind bug ? 13:01
never mind, the bug in t/spec/S32-temporal/DateTime.t is still present 13:09
brrt no, did ot 13:13
did not fix it
but both those templates look very correct
Guest13443 brrt: removing the sp_p6oget_bi template from src/jit/core_templates.expr 'fixes' the problem 13:22
brrt yes, I know
but what I don't know, yet, is why
Guest13443 a genuine mystery then 13:25
brrt we'll figure it out 13:27
Guest13443 anything I can do to help except cheering you on? 13:32
brrt if you have a theory on why jit-bisect gives such wildly wrong answers...
Guest13443 Can a golf help out here? 13:40
or do you have one already?
./perl6-m -e 'say DateTime.new("2016-12-31T23:59:60Z") <=> DateTime.new("2017-01-01T00:59:60+01:00") for ^100' 13:41
13:41 sena_kun left 13:42 patrickb left 13:44 patrickb joined
brrt Guest13443: what's wrong with that? 13:46
a golf would help, yes
is that broken?
hoooh, that's very broken 13:47
Guest13443 might possibly help
brrt it's a lead
thanks
Guest13443 np
is jnthn lurking around by any chance? 13:55
brrt negative offset for dynamic label, oh no 13:58
Guest13443 oh, you found something 13:59
brrt yeah, negative offsets like that should *never* happen
14:01 domidumont left
Guest13443 and now you have to figure out why it happens anyway 14:01
14:02 domidumont joined 14:27 ggoebel joined
brrt indeed 14:34
14:44 sena_kun joined 15:39 domidumont left 15:51 brrt left
AlexDaniel squashable6: status 16:12
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in ≈11 hours (2019-10-19 UTC-12⌁UTC+20). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
Geth MoarVM: dogbert17++ created pull request #1197:
Update to libuv version 1.33.0		 16:42
17:24 vrurg joined, moon_child left
vrurg Can somebody help me with terminology in moar? MVM_frame_capturelex is said to set code object outer to current scope. Then the scope is build with MVM_frame_force_to_heap which iterates over callers – i.e. over dynamic, not lexical scope. Where I'm wrong? 17:27
timotimo force_to_heap is important for an optimization to not F things up 17:28
in order to not allocate and free as much stuff for entering and exiting frames we have a set of big-ish memory areas that behave like a regular stack would
but sometimes, like with closures, we have to move stack frames away so there's space for regular stack frames again 17:29
that's why the frame is forced to the heap, if it lived on the "stack" before
17:29 moon_child joined
timotimo and the stack is made up of callers, that's why that's what force_to_heap iterates over, i guess 17:29
17:31 sena_kun left 17:33 sena_kun joined 17:35 sena_kun left 17:36 sena_kun joined
vrurg timotimo: thanks! 17:42
then it means I was heading wrong direction. 17:43
17:44 sena_kun left 18:07 lizmat joined 18:59 patrickb left 19:11 MasterDuke joined 19:36 lizmat left 20:08 vrurg left 20:15 vrurg joined 22:07 releasable6 left 22:08 lizmat joined, squashable6 left 22:12 releasable6 joined, squashable6 joined
Geth MoarVM: 0f05efbb7b | (Jan-Olof Hendig)++ | 3rdparty/libuv
Update to libuv version 1.33.0

Clean spectest on Linux. According to tests by vrurg++ it also fixes M#1178 a Mac specific problem wrt file change notifications.		 22:16
MoarVM: eebe39b513 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3rdparty/libuv
Merge pull request #1197 from dogbert17/libuv-v-133

Update to libuv version 1.33.0
synopsebot M#1178 [open]: github.com/MoarVM/MoarVM/issues/1178 libuv 1.26 update caused file change notification to be broken on macOS
MoarVM: 36c35db159 | (Patrick Böker)++ | src/io/fileops.c
Make MVM_file_is_rwx honor root and groups
 22:18
MoarVM: 990a2b6830 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/io/fileops.c
Merge pull request #1193 from patzim/perm-check-fix

Make MVM_file_is_rwx honor root and groups
lizmat .tell brrt looks like the bind_o errors are back: t/spec/S32-temporal/DateTime.t t/spec/S32-list/combinations.t fail 22:49
tellable6 lizmat, I'll pass your message to brrt
lizmat sleep&
timotimo i think nobody reverted the stuff brrt asked to have reverted 23:27
Geth MoarVM: 6edb176a32 | (Timo Paulssen)++ | 2 files
Revert "Revert "Revert "exprjit sp_p6oget_bi"""

This reverts commit 91d53ae7f4980d09a07f80d2a2d8cd21e3a66dde.
Accidentally pushed at the wrong time.		 23:29
MoarVM: 0aa43a9832 | (Timo Paulssen)++ | 2 files
Revert "[JIT] Syntactically distinguish let keyword variants"

This reverts commit 76cd034ae3fbba919d25f2ef75951d430f97f576.
Accidentally pushed at the wrong time
vrurg timotimo: one more moar/nqp bump is needed, I guess? 23:39
timotimo did we have a bump recently? 23:44
oh dang we did 23:45
vrurg AlexDaniel made one ~1.5hr ago
timotimo i didn't notice anything >_>
vrurg No wonder. Everybody has crazy days lately.
AlexDaniel need another one?
timotimo yeah, there were commits in moar that were pushed on accident 23:46
and only now reverted
AlexDaniel k
done
timotimo tanks
23:52 lucasb left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!