timotimo welp, i wrote a template for gethow but i got the jit to panic with "no inbound edge" 00:06
gist.github.com/timo/e7f7088cd82e2...fe59d10a84 - brrt can have a look at this to see what i messed up :) 00:08
oh, maybe there was a real reason to have ptr_sz as the return value for call ... :) 00:09
nope. that didn't actually fix it
i was able to build "iter" without a crash, but only as a super simple c function call 00:20
huh, i still get "cannot get template for iter" messages in the jit log though 00:23
i put the iter function up in that gist, too, for good measure 00:31
bedtime
MasterDuke i was thinking about trying some of those really simple *_i ones 00:32
yoleaux 18 May 2017 06:01Z <brrt> MasterDuke: yes; i think there's a parser bug somewhere in there which means you need to have an extra newline after the last template
MasterDuke timotimo: how do you get that log? 00:34
timotimo MVM_JIT_LOG 00:36
grep "tree out of" /tmp/coresettingjitlog.txt | sort | uniq -c | sort -n | less - gives you what chunks of mvm ops it turns into expression trees 00:37
grep "get template for" /tmp/coresettingjitlog.txt | sort | uniq -c | sort -n | less - gives you the mvm ops that terminate individual exprjit attempts
MasterDuke cool, thanks 00:38
timotimo gist.github.com/timo/2b25fca488f17...5863343d78 - the thing at the top gives you the scoreboard based on the "tree out of" lines 00:39
MasterDuke i don't know what expression trees are 00:40
timotimo well, the major leap forward that the exprjit (aka even-moar-jit, aka the new jit) has over the current jit is that it creates a close-to-assembly datastructure from multiple mvm ops in a row 00:42
the jit before that would immediately spit out a piece of machine code for every mvm op it finds and then it'll be done with it
that forced us to have a load for every argument and a store for the written registers around every op 00:43
the exprjit has a low-level representation of things that get created from mvm ops and then a register allocator runs through it; that's the most basic benefit we get from the exprjit 00:44
the next step is that REPRs can have their own implementations of their reprops written in expr templates
the effect of that is much like inlining function calls
MasterDuke ah, nice 00:45
timotimo the previous jit was able to emit a direct call to a specific repr's reprop if the type of object was known at jit time
but even then the call was still opaque and presented a barrier in terms of optimization
with the exprjit we could get common subexpression elimination across multiple calls to the same reprop, for example 00:46
MasterDuke immediately subsequent calls? 00:47
timotimo another thing is that the VMArray repr has a big switch/case in many of its reprops to do the right thing based on the type of slot that the type has
well, like nqp::push_o($a, 1); nqp::push_o($a, 2); nqp::push_o($a, 3)
the pieces of dump in the jitlog that start with "digraph {", you can feed to graphviz, for example by piping/pasting it into "dot -Tx11" 00:49
the tile list log is, if i understand correctly, closer to the metal, i.e. already linearized 00:50
MasterDuke the new jit could just do the right branch of those ops?
timotimo yup, but of course it requires these reprops to be implemented once in C and once in expr tree language
MasterDuke each branch as a separate c function? 00:51
timotimo no
the C portion would be kept as is
MasterDuke oh, nice 00:52
timotimo ok, i'm off
have a good one :)
MasterDuke likewise 00:53
timotimo don't forget to look into unsafe.expr where brrt collected some templates that cause some kind of breakage 00:55
MasterDuke i wondered what that was
Zoffix wonders if tools/contributors.p6 is buggy 01:38
timotimo: says you made just 2 commits this month. Does that sound right? I thought there were all the telemeh stuff 01:39
MasterDuke Zoffix: month == may or month == past 30 days? 01:47
01:49 ilbot3 joined
Zoffix MasterDuke: since last release.. tho the date it gives me is "Contributors to Rakudo since the release on 2017-04-23:" 01:49
Ah, that's the last point release date 01:50
Guess I should tweak it to last proper release 01:51
"Contributors to Rakudo since the release on 1970-01-18:" 01:52
I think I overtweaked
MasterDuke timotimo does only have 2 commit (in moarvm) for may, but a couple more in april after the 23rd 01:53
Zoffix k, shows 8 when I fix it to use date of last non-point release. 02:18
... and my new count suggests I've gone insane... 02:19
03:01 geekosaur joined 05:01 KDr2__ joined 05:25 domidumont joined 05:31 domidumont joined 06:01 brrt joined 06:09 domidumont1 joined
brrt i'm now stepping throuw the code to see wth is wrong 06:46
omg, i'm seeing it, but i still don't get it :-o 06:52
07:09 brrt joined
brrt i'm seeing it now 07:17
i'm preparing the proper arguments, but passing them in the wrong order
presumably due to the shuffling logic
so
the body is the STable 07:18
the root is the array body
and the st handle is the object including header 07:19
*thank god it is a bug like this*
nwc10 I'm glad that it's less horrible than you first feared 07:20
you fell off IRC too fast for me to suggest "go get coffee"
Geth MoarVM/even-moar-jit: 1f3c57544c | (Bart Wiegmans)++ | 4 files
Introduce new test-against-constant tiles

For quick flag checking. Reading the sequence of load memory, load const, binary and, and test zero was getting annoying. Uncovers new problems with elems (probably due to register shuffling?) so disabled that for the time being.		 07:21
nwc10 is now AFK for "go get wheelbarrow" 07:22
07:26 zakharyas joined
brrt i'd gotten coffee even before i entered my commute 07:28
i have one of those horrible/convenient coffee machines that just has you pop in some cups
so making coffee in the morning is a managable endeavour 07:29
08:15 domidumont joined
jnthn So is still on tea, though his guts are probably recovered enough from this week's gremlins to drink coffee again already... 08:43
yoleaux 18 May 2017 23:08Z <Zoffix> jnthn: should Blob.Stringy be dying (as it does right now)? We don't have any cases of .Numeric dying. .Stringy on `utf*` types coerces them to Str, which also feels wrongish. If we follow the Stringy for stringy is like Numeric for numerics, then .Stringy on all Blobs should just return `self`
08:49 zakharyas joined 08:51 robertle joined
nwc10 brrt: make s the coffee easy, but the compost hard? 08:57
brrt true 08:58
it does
Geth MoarVM: 863e9205ae | (Jonathan Worthington)++ | 10 files
Remove asyncwritestr op and supporting code.

Deprecated and not used by Rakudo for a while.		 10:05
MoarVM: 9d3ede0009 | (Jonathan Worthington)++ | 9 files
Remove asyncwritestrto op and supporting code.
 10:14
MoarVM: 5f23324971 | (Jonathan Worthington)++ | 10 files
Remove asyncreadchars op and supporting code.

Deprecated and unused by Rakudo for a while.		 10:28
jnthn That does a bit of housekeeping.
samcv nice 10:38
Geth MoarVM/sync-socket-no-uv: ca7de1752a | (Jonathan Worthington)++ | src/io/syncsocket.c
Remove encodable support from sync socket.

This is a first step towards removing string I/O support from sync sockets, which in turn will simplify re-implementing them without the use of libuv. (Note that no work in this branch will be merged until the corresponding Rakudo branch is merged, which will not be until after the 2017.05 release.)
MoarVM/sync-socket-no-uv: 71e8122bd0 | (Jonathan Worthington)++ | src/io/syncsocket.c
Remove seekable from sync sockets also.

Only the tell part of it was implemented and even then it was not used, and since it relies on DecodeStream then it would complicate upcoming refactors.		 10:43
MoarVM/sync-socket-no-uv: 43cdeb4fef | (Jonathan Worthington)++ | src/io/syncsocket.c
Have string I/O ops on sync sockets throw.

These functions will go away from the I/O tables in the future, once other forms of sync I/O are all done in binary mode only at VM level. For now, it helps with disentangling sockets from syncstream.		 10:59
timotimo brrt: any obvious problems with my two templates i posted? 11:05
brrt timotimo: i'm bad at backlogging these days 11:06
timotimo ah, hehe
gist.github.com/timo/e7f7088cd82e2...fe59d10a84
as the gist says, one gives me a moarvm panic for "no inbound edges" 11:07
the other just doesn't seem to end up used at all
brrt actually timotimo, those look pretty much alright
gethow gives you a no inboud edge error? okay 11:08
i need to check that
timotimo cool :) 11:09
i was searching for "iter" in the jit subfolder and found registers typo'd as regsiters 11:20
brrt lol 11:24
you can change that
timotimo should i wait for you to figure out gethow and iter? :) 11:25
11:29 AlexDaniel joined
timotimo with bated breath 11:29
brrt well, you can try to debug it yourself, as well 11:33
but frankly i'm still trying to figure out the elems breakager
(i do have a reasonable theory wrt that, though) 11:34
12:33 KDr2_ joined
Geth MoarVM/mutex_parameterization_add: 4cf22677a1 | (Timo Paulssen)++ | 3 files
protect the parameterization lookup list with a mutex

addresses #554		 12:41
MoarVM: timo++ created pull request #599:
protect the parameterization lookup list with a mutex		 12:42
MoarVM/mutex_parameterization_add: 3399df06c7 | (Timo Paulssen)++ | 3 files
protect the parameterization lookup list with a mutex

addresses #554		 12:43
timotimo (comment fix forcepush)
Geth MoarVM/sync-socket-no-uv: 9c3bdfe6f1 | (Jonathan Worthington)++ | src/io/syncsocket.c
Duplicate syncstream functions into syncsocket.

This is the first step towards pulling the two apart, in preparation for syncsocket ceasing to use libuv.		 13:42
MoarVM/sync-socket-no-uv: 3b1ac1c13c | (Jonathan Worthington)++ | src/io/syncsocket.c
Put sync stream struct members into socket struct.

Completing the breakout of syncsocket from syncstream.		 13:49
MoarVM/sync-socket-no-uv: 3cec878c9c | (Jonathan Worthington)++ | src/io/syncsocket.c
Toss various unused struct members.

Along the way starting to wean us off using the decode stream.		 13:57
japhb OOC, why are you removing libuv from sync sockets? 14:32
jnthn japhb: Primarily because it's the cause of the "can't share them between threads" issue 14:34
(Because a libuv event loop lives on a single thread, and you can't move handles between loops) 14:35
Zoffix baits with rt.perl.org/Ticket/Display.html?id...et-history
Such a fun ticket to fix!
m: sub rotr(uint32 $n, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
camelia 27071659120799
229376
Zoffix ^ supposed to give same values for both
japhb jnthn: Ah, gotcha.
jnthn Will fix it for all the sync handles, which will in turn deal with the not being about to read from $*IN from anything other than the main thread 14:36
But sockets were the easiest starting point 14:37
japhb Fair enough. 14:38
jnthn And also the one people trying to do multi-threaded web servers the non-IO::Socket::Async way tend to run into.
14:38 brrt joined
japhb Is Uni input (from $*IN at least) on your current short list, or is that farther out? 14:39
yeah, gotcha
jnthn Farther out
japhb OK, roger that.
jnthn Likely made easier by these refactors, however. 14:41
14:45 committable6 joined
Geth MoarVM/sync-socket-no-uv: 87f2c02e52 | (Jonathan Worthington)++ | src/io/syncsocket.c
Eliminate the use of the decode stream.

In doing so, introduce a simple 1-packet buffer in its place. In the best case, programs will hit the no-memcpy path and the buffer we get from the network will be handed straight on back to userspace after being wrapped in an MVMArray. The buffer helps in cases where folks do stuff like .read(1) on the socket to pull a byte off at a time.		 14:55
jnthn I think that gets all the preparatory refactors I can do to make the big step easier out of the way. 14:59
brrt we're doing the order of cycle breakage all wrong! 15:04
i'm doing it wrong, at least
timotimo oh! 15:05
15:05 AlexDaniel joined 15:07 committable6 joined
timotimo all wrong, eh? time to use that "delete repository" button 15:08
brrt lol 15:13
stuff isn't that bad just yet
ah, i see it 15:17
i build the stack in reverse order
so say we have:
a -> b -> c -> a
well, what i have is that from a, c is inbound 15:18
from c, b is inbound
what i do is iterate backwards, from a to c, c to b, and i stop when c i s a 15:19
no, hang on
i stop when i see that the next thing is a 15:20
anyway
i end with a stack looking like: c, b, a (if a is even on there)
now supposing i move a out of the way to t, i need to move c -> a, b to c, a to b 15:21
actually, t to b
so i need to iterate the stack 'upwards', rather than downwards
timotimo if it's that easy ... :) 15:50
just quite tricky to find i imagine
17:45 domidumont joined 19:02 AlexDaniel joined 19:06 Ven joined 19:19 Ven_ joined 19:51 zakharyas joined 20:19 Ven joined 20:31 Ven_ joined
MasterDuke timotimo: any idea why adding `(template: gt_i (gt $1 $2))` to src/jit/core.expr would cause the NQP build to segfault (it doesn't segfault with that commented out)? 20:38
timotimo i haven't the slightest :) 20:40
MasterDuke valgrind if you're curious gist.github.com/MasterDuke17/001bd...6f688da448 20:41
timotimo i know basically nothing about the code the exprjit is made out of 20:42
20:43 Ven_ joined
Geth MoarVM: 3bcd19ee91 | (Jonathan Worthington)++ | docs/ChangeLog
ChangeLog for 2017.05.
 20:44
MoarVM: cc390f5b29 | (Jonathan Worthington)++ | VERSION
Bump VERSION.
jnthn Checking of that welcome 20:45
timotimo: Especially from you; if you want more/differnet notes on telemeh in there tweak awa
*away
timotimo we could point out that the line number info in spesh is mostly good for the line coverage 20:51
jnthn Yeah, I was looking at the patch and it seemed exception reports don't bonefit yet? 20:52
*benefit
timotimo oh, i don't think so 20:53
i didn't realize we'd have trouble with that at all
jnthn Yeah, we do :) 20:54
And you've done a chunk of the work to fix it, it turns out ;)
timotimo that's nice, i can look into the rest of that soon 20:55
Geth MoarVM: 9c1762636c | (Jonathan Worthington)++ | docs/ChangeLog
Mention spesh position info is used for coverage.
jnthn Cool :)
timotimo++
Anything else, or shall I go for release? 20:56
timotimo we could already merge the mutex for parameterization 20:57
so we can at least not get the segv in that spec test
Zoffix If the bug disappears with MVM_SPESH_DISABLE does it mean it's somewhere in src/spesh/ code?
timotimo not necessarily
Zoffix ok
timotimo it could also be a bug in the jit
because when you disable spesh, it'll turn off the jit, too
Zoffix MVM_JIT_DISABLE doesn't remove the bug tho 20:58
m: sub rotr(uint32 $n, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
camelia 27071659120799
229376
Zoffix ^ that bug
timotimo it might have something to do with inline or osr
Zoffix hm
timotimo so you can check those separately, too
Zoffix yeah, OSR = still bug; INLINE = no bug 20:59
timotimo cool.
also: oh no
jnthn That gets it down to inlining then :S
timotimo we're not handling stuff like unsignedness across inlines? 21:00
we should just be memcpy-ing flags around, though
jnthn Yeah, not sure it'd need special handling
I wonder if it's the inlining of rotr itself, of the inlining of things inside of rotr 21:01
m: sub rotr(uint32 $n, uint32 $b) { my $ignore = nqp::ctx(); $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x 21:02
camelia ===SORRY!=== Error while compiling <tmp>
Could not find nqp::ctx, did you forget 'use nqp;' ?
at <tmp>:1
------> $n, uint32 $b) { my $ignore = nqp::ctx()ā; $n +> $b +| $n +< (32 - $b) }; say rot
jnthn m: use nqp; sub rotr(uint32 $n, uint32 $b) { my $ignore = nqp::ctx(); $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
camelia 27071659120799
229376
Zoffix m: my $x; for ^1000 { my uint32 $n = 1652322944; my uint32 $b = 18; $x = $n +> $b +| $n +< (32 - $b) }; say $x
camelia 27071659120799
jnthn Looks like the inlining of +> or +| or +< itself
m: use nqp; sub rotr(uint32 $n is rw, uint32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x 21:03
camelia Expected a modifiable native int argument for '$n'
in sub rotr at <tmp> line 1
in block <unit> at <tmp> line 1
jnthn ah, right
MasterDuke m: my $x; my uint32 $n = 1652322944; my uint32 $b = 18; for ^1000 { $x = $n +> $b +| $n +< (32 - $b) }; say $x 21:06
camelia 27071659120799
Zoffix m: sub rotr(int $n, int $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x 21:07
camelia 27071659120799
27071659120799
Zoffix m: sub rotr(int32 $n, int32 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
camelia 27071659120799
229376
Zoffix m: sub rotr(int64 $n, int64 $b) { $n +> $b +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
camelia 27071659120799
27071659120799
Zoffix Something with the 32 size?
jnthn Certainly the program relies on promotion from 32-bit to get the correct result 21:08
Though we're meant to do computation in 64-bit wide and then nothing should be narrowing it again in this code 21:09
m: sub rotr(int32 $n, int32 $b) { $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x 21:10
camelia 27071659114496
27071659114496
jnthn m: sub rotr(int32 $n, int32 $b) { $n +| $n +< (32 - $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
camelia 27073309340288
27073309340288
jnthn m: sub rotr(int32 $n, int32 $b) { ($n +> $b) +| $n }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x
camelia 1652325023
1652325023
jnthn m: sub rotr(int32 $n, int32 $b) { ($n +> $b) }; say rotr 1652322944, 18; my $x; for ^1000 { $x = rotr 1652322944, 18 }; say $x 21:11
camelia 6303
6303
jnthn Doesn't seem keen to be golfed further...
Zoffix: Is this a release blocker at all? I'm not sure I've the energy to investigate/fix it tonight. Tomorrow maybe. 21:15
Zoffix m: sub rotr(int32 $n = 10, int32 $b = 33000000000000) { $n +< $b }; my $y = rotr; my $x; for ^1000 { $x = rotr }; say $x == $y
camelia False
Zoffix jnthn: not really, I have a workaround for it by undoing a bug fix 21:16
Basically putting back this bug: rt.perl.org/Ticket/Display.html?id=126942 21:17
(which we already had in last releease)
Oh wait, I mean this one: rt.perl.org/Ticket/Display.html?id=131278
m: my $i = -0x8000000000000000; say ($i div 2**23) == ($i +> 23) ?? 'good' !! 'bad';
camelia good
Zoffix m: my $i = -0x8000000000000000; say ($i div 2**33) == ($i +> 33) ?? 'good' !! 'bad';
camelia good
Zoffix m: my $i = -0x8000000000000000; say ($i div 2**43) == ($i +> 43) ?? 'good' !! 'bad';
camelia good
Zoffix Oh right. Well, the undoing will make the last two say bad 21:18
jnthn Zoffix: Would you prefer to wait and see if I can fix it tomorrow, or should I go ahead with the release? 21:40
Zoffix jnthn: up to you. I'm leaning towards release now. 21:41
jnthn OK. I don't think this is a MoarVM regression, rather than something streamlined code in Rakudo has exposed. 21:42
Totally agree it wants fixing.
But it's probably better to put in a carefully considered fix for an inlining related bug than try and rush one in. 21:43
That code is...complex.
21:43 MasterDuke joined
Zoffix Yeah 21:43
jnthn Alright, I'll tag and upload
Zoffix \o/
jnthn I can't believe bash tab completion works for SCP remote paths 21:47
<3 to whoever did the work to make that happen
japhb jnthn: Yeah I seriously <3 that feature
jnthn I discoverd it totally by accident
Yet another reason to do keys not passwords :) 21:48
www.moarvm.org/releases/MoarVM-2017.05.tar.gz
Zoffix w00t
jnthn Tag pushed also 21:49
21:56 Ven joined 22:43 Ven joined
jnthn I'll do the website tomorrow; sleep time now o/ 22:44
Zoffix night 22:45
23:06 Ven_ joined 23:24 Ven_ joined 23:40 Ven joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!