github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:12 Kaiepi left 00:28 Kaiepi joined 00:29 p6bannerbot sets mode: +v Kaiepi 00:46 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 01:15 fake_space_whale joined, p6bannerbot sets mode: +v fake_space_whale 01:32 Kaiepi left 01:33 Kaiepi joined 01:34 p6bannerbot sets mode: +v Kaiepi 03:01 Kaiepi left 03:02 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 03:19 Kaiepi left, Kaiepi joined 03:20 p6bannerbot sets mode: +v Kaiepi 03:54 fake_space_whale left 04:00 MasterDuke left 04:49 fake_space_whale joined, p6bannerbot sets mode: +v fake_space_whale 05:17 fake_space_whale left 05:39 Kaiepi left, Kaiepi joined 05:40 p6bannerbot sets mode: +v Kaiepi 06:25 robertle joined, p6bannerbot sets mode: +v robertle 06:33 domidumont joined, p6bannerbot sets mode: +v domidumont 07:42 zakharyas joined, p6bannerbot sets mode: +v zakharyas 07:48 zakharyas left
Geth MoarVM/nqp-mbc: dc39fc6e45 | (Stefan Seifert)++ | src/jit/graph.c
JIT compile unbox_u
 08:16
08:16 lizmat left 08:32 lizmat joined, p6bannerbot sets mode: +v lizmat 08:34 yoleaux left 08:36 zakharyas joined 08:37 p6bannerbot sets mode: +v zakharyas 08:39 AlexDaniel left 08:40 zakharyas left 09:50 zakharyas joined 09:51 p6bannerbot sets mode: +v zakharyas 10:30 yoleaux joined, p6bannerbot sets mode: +v yoleaux 10:35 Kaiepi left, Kaiepi joined 10:36 p6bannerbot sets mode: +v Kaiepi 11:05 Kaiepi left 11:08 Kaiepi joined 11:09 p6bannerbot sets mode: +v Kaiepi 11:15 Zoffix left 11:32 lizmat left 11:35 lizmat joined, p6bannerbot sets mode: +v lizmat 12:09 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
Geth MoarVM: f4eafe0de0 | (Zoffix Znet)++ | src/6model/parametric.c
Fix typo in comment
 12:32
12:35 brrt joined, brrt left 12:37 brrt joined, p6bannerbot sets mode: +v brrt
brrt \o 12:37
nwc10 o/ 12:38
brrt which one of us can comment here: www.reddit.com/r/perl6/comments/9q..._6_on_aix/
ohai nwc10 12:39
I'm not sure how I'll fix the UB you find
lizmat brrt: not me, my experience with AIX ended early 2000 with an AIX 3 box that I decommisioned 12:45
nine Looks like dyncall doesn't support AIX. But maybe libffi does? 12:46
brrt well, either of those are a good answer :-) I just don't have a reddit account even 12:48
nine me neither 12:49
12:54 MasterDuke joined 12:55 p6bannerbot sets mode: +v MasterDuke 13:07 MasterDuke_ joined, p6bannerbot sets mode: +v MasterDuke_ 13:08 MasterDuke_ left 13:09 MasterDuke_ joined 13:10 p6bannerbot sets mode: +v MasterDuke_, MasterDuke_ left, MasterDuke left
ugexe fwiw i looked more into using non-blocking uv_getaddrinfo in e.g. MVM_io_socket_connect_async and i'm not sure i'll have time to figure it out anytime soon. I was going to crib from julia github.com/JuliaLang/julia/blob/04...nfo.jl#L13 but I ran out of time before even getting to the code writing part 13:18
13:24 Kaiepi left 13:25 Kaiepi joined 13:26 p6bannerbot sets mode: +v Kaiepi
brrt ugexe: what's the use case 13:44
anyway, whatever julia is doing, might not work for us 13:46
ugexe is it not bad design to have a blocking (possibly indefinitely) call inside a function intended to be asynchronous? 13:55
14:06 zakharyas left, zakharyas joined 14:07 p6bannerbot sets mode: +v zakharyas
ugexe for a use case i would imagine dead-lock or starvation could occur with enough connections queued that require dns 14:07
brrt oh no, you're right 14:08
but
what I'm really asking is, how do you want to expose it to the user 14:09
I guess the true perlish thing to do, would be to have an async addrinfo opcode, and to have async socket opcodes that used the asynchronously obtained result 14:10
if that makes any sense
otherwise, you're going to have to do it via callbackland
(and internalize it)
ugexe i'm not worried about exposing the async getaddr info to the user, mainly for internal use (like .connect)
14:11 zakharyas left
ugexe but yeah the impression i got was i was going to have to create an opcode like you said 14:12
it'd be simple to just handle dns in the perl6 theadpool, but seems hacky 14:14
brrt why? 14:18
or, as in, make another thread? no, please don't :-)
ugexe right, in the possible but still theoretical future IO threadpool
timotimo i'm not seeing the problem yet with making getaddrinfo asynchronous via the libuv loop
we do have a thread that handles async IO stuff (though not running any user code or moarvm bytecode) 14:19
ugexe i mean a threadpool that async filesystem IO would be used for
timotimo not sure how you mean that 14:20
ugexe if async filesystem IO were to be added to perl 6 it would likely be done via a theradpool in perl6-land instead of using libuv's "async" filesystem IO ( which is also a threadpool doing sync operations ) 14:22
timotimo ah, i didn't know that
libuv threads are still more lightweight than perl6 threads
remember that a perl6 thread comes with a nursery that gets set up as 1 megabyte if i'm not mistaken and grows to 4 megabytes * 2 (because semispace copying garbage collection) 14:23
so you're looking at between 2 megs and 8 megs per thread
ugexe libuv isn't thread safe, i don't want to imagine trying to imagine trying to manage libuv's threadpool inside moarvm. we also have libuv loop per thread, so each thread has its own libuv threadpool? 14:24
timotimo perhaps not necessary
if we have one dedicated MVM thread that handles the libuv thread pool
i'd assume that all these threads libuv uses to do sync io in an async fashion are transparent to us
i.e. we'll never touch individual threads in that pool ourselves 14:25
brrt ugexe: we have an IO thread 14:40
and we may have a thread pool in some future point, but we don't have that yet
nobody ever had that much IO needs yet 14:41
timotimo so i've come up with a simple way to improve nativeref + boolification stuff
brrt timotimo: tell us more
ugexe: also, we no longer have an uv loop per thread. We have a single IO loop thread, and it is started on demand. See src/io/eventloop.c 14:42
timotimo so, the code i'm looking at at the moment is nativeattrref_i, then decont, then bool_I
brrt and async file IO is a lie anyway, on linux at least :-) 14:43
timotimo decont on the nativeattrref_i will get_int on the nativeref and box it into an Int object
brrt uhuh
timotimo if i split that apart into explicit moar bytecode ops, then it should be possible to have an if_i instead of the bool_I + if_o
brrt yes
timotimo and then the later stage can probably throw out the box + unbox already
brrt yes
go for it 14:44
timotimo the next improvement step would of course be to turn the get_int on the native ref into a getattr_i
brrt uhuh
(and to make that into a sp_get_i)
timotimo yup
brrt anyway, I agree that having synchronous getaddrinfo in an async function is not-so-optimal design 14:46
what I'm not so sure about is hiding the async call versus making it explicit, and I'm usually in favor of explicit but that might upset clients that use the current interface 14:47
timotimo i don't see a reason why our clients would even see the difference
so long as we only change getaddrinfo that is inside a function that is already async itself 14:48
brrt they wouldn't, we can hide it, but an async getaddrinfo exported to users would in fact be very nice 14:51
so currently we have sync getaddrinfo within 'async' connect, right? 14:52
timotimo that's how i understand it; but also inside udp send message?
brrt I think so, yes 14:53
so that's not strictly a correct factorization of the synchronous/asynchronous bits
correct would be: getaddrinfo(...).and-then($addr -> async-connect($addr)).and-then(...); 14:54
same for async-send-message
but that means an interface change
timotimo huh, that's funny. the code will be an unbox_i followed immediately by a box_i 14:59
15:00 fake_space_whale joined 15:01 p6bannerbot sets mode: +v fake_space_whale 15:04 brrt left
timotimo oh, unbox_i isn't the right op, it seems like 15:12
probably decont_[ins] instead 15:13
i'll go afk for a bit, but i'm closing in on the target. just gotta get the define/usage right 15:19
15:19 samebchase left 15:20 samebchase joined, p6bannerbot sets mode: +v samebchase 15:22 Kaiepi left 15:25 Kaiepi joined 15:26 p6bannerbot sets mode: +v Kaiepi
timotimo well, it splits it now, but it doesn't yet eliminate the box/unbox pair. gotta check into that later. 15:26
15:27 domidumont left
Geth MoarVM/nativeref_decont_split: e50162dd19 | (Timo Paulssen)++ | src/spesh/optimize.c
fix precedence issue
 15:27
MoarVM/nativeref_decont_split: 05c476140f | (Timo Paulssen)++ | src/spesh/optimize.c
decont on nativeref shall become decont_* + box_*

this way we should later be able to use the deconted value directly without boxing it first, and then more easily get rid of a native ref taking instruction.
timotimo feel free to tell me that "precedence issue" isn't actually an issue 15:28
i do think bitwise ops bind looser than boolean ops
15:39 robertle left 16:03 fake_space_whale left 16:07 brrt joined
timotimo yay, setting KNOWN_TYPE for the spesh slot gets us to fastbox_bi_ic 16:07
16:08 p6bannerbot sets mode: +v brrt
Geth MoarVM/nativeref_decont_split: 8d72f86e29 | (Timo Paulssen)++ | src/spesh/optimize.c
set flags & known type on spesh slot

unblocks optimizing the box_* into a fastbox, in the case of box_i it will even go through the int cache.		 16:08
timotimo oh ... oh no ...
infix:<+> used to be getarg, decont, add_i 16:10
now it's getarg, decont_i, box_i, add_I
sorry, it was add_I before, too
brrt oh, that's not necessarily bad 16:11
timotimo no, that's very bad
this breaks with ints bigger than 64bit stored in the Int object
oh 16:13
it only does that because we know it's a nativeref that's passed in
even then we don't want this to happen for the general case of infix:<+> as opposed to the case where we inline it
so maybe i make it depend on a getattrref (or similar) op existing in the current graph 16:14
then it'll still happen post-inline, but not when we are completely unable to get rid of the get*ref op
actually, it can be more efficient to split it, since now it can double-devirt in the jit and then fastbox with int cache before the add_I 16:31
16:32 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix timotimo: they bind tigher: en.cppreference.com/w/c/language/o...precedence web.cse.ohio-state.edu/~babic.1/COp...eTable.pdf 16:33
timotimo oh, hmm. 16:42
ISTR i got misbehaviour when i did it without parens
i wonder what i'm mixing up there
Zoffix Anyone got any ideas for R#2400 ? Some info appeared since last night: github.com/rakudo/rakudo/issues/24...-432170805 16:43
synopsebot R#2400 [open]: github.com/rakudo/rakudo/issues/2400 [fudged tests committed][regression][āš  blocker āš ] Module Crane is failing tests on HEAD
Zoffix Like what's the difference between Array[Mu] and Positional[Mu]? The former got a bug but latter ain't 16:46
*crickets* :) 17:00
17:02 Zoffix left 17:17 robertle joined 17:18 p6bannerbot sets mode: +v robertle 17:21 lizmat left
nine Zoffix: Array[Mu] is a class with a mixin while Positional[Mu] is a role? 17:23
17:25 zakharyas joined 17:26 p6bannerbot sets mode: +v zakharyas 17:37 Zoffix joined, p6bannerbot sets mode: +v Zoffix
Zoffix nine: hehe, well yeah, I know that, but what makes one case buggy but not the other :) 17:38
Geth MoarVM: 8b4d58c7ab | (Zoffix Znet)++ (committed using GitHub Web editor) | src/6model/serialization.c
Fix typo in comment
 17:45
17:51 brrt left 17:52 domidumont joined 17:53 p6bannerbot sets mode: +v domidumont
nine I'm equally stumped on another issue: I noticed comparing nqp-mbc's profile data to master's that on nqp-mbc there are a lot more calls to fresh_register and release_register and more confusing: to QAST::Op.new and QAST::SVal.new, but not to other QAST::Node types. 18:03
6639 addition calls to QAST::Op.new and 9230 more for QAST::SVal.new 18:04
timotimo can you turn off the optimizer? that one builds loads of ops, too 18:05
nine But my branch changes the QAST -> mbc path. The QAST should be untouched.
timotimo maybe it changed the result of nqp's compiler
nine And I've looked at the whole diff to master and don't see any place with a possibility of introducing additional QAST nodes
timotimo that'd be kind of weird
nine Why QAST::Op and QAST::SVal but not Stmt, Stmts, IVal or anything else? 18:06
Zoffix Found one difference between the two cases: in the working one, when `resolve_param_interns` is called the reader->root.num_param_interns is 1, but in broken one it's 0
timotimo do they perhaps use a parent node's constructor?
nine Zoffix: that sounds very odd as both have parameters, don't they?
Zoffix Yeah 18:07
timotimo nine: what would you look for in a "callers" list for the routine overview?
18:07 zakharyas left
nine timotimo: doesn't look like. I went through all calls to .new in gen/moar/stage2/QASTNode.nqp in the profiler's list 18:07
timotimo: just a flat list would be an extraordinary addition already! 18:08
timotimo what columns would you expect? "times called via" for sure, for example
nine If I had that, I could just compare the callers to QAST::Op.new on both branches and probably immediately see the answer
timotimo it'll take me but a minute. however, the profiler format the server currently expects differs a little bit from what's there in master 18:09
nine Callers and counts is all I need right now
These minutes could potentially save me hours :) 18:10
Ooooooooh, I think I've got it! 18:13
timotimo oh? 18:14
nine There's an optimization that pmurias++ did back in 2015: github.com/perl6/nqp/commit/9772e4587d 18:16
Notice how the if nqp::islist($sh) in line 663 won't trigger because we return nqp::null() in 652? 18:17
I changed that nqp::null() back to $sh, because I need to serialize that string heap, thereby removing the optimization
timotimo ooh 18:19
18:23 Kaiepi left
nine But when I fix that I get a chars requires a concrete string, but got null 18:23
at <unknown>:1 (gen/moar/stage2/nqpmo.moarvm:<dependencies+deserialize>)
18:23 Kaiepi joined 18:24 p6bannerbot sets mode: +v Kaiepi
timotimo nine: imgur.com/pj6KZc8 18:38
18:39 domidumont left
nine timotimo: very cool! 18:39
timotimo i'm not yet sure how i want it to look when you expand a list that's already expanded from an outer list %) 18:40
like, you should be able to get to the list of sites the routine is called from, though it'd be good if that list were structured like the call graph in reverse
nine: i pushed the changes to moarperf on github 18:51
you'll need the profiler-additions and profiling-additions branches of moarvm and nqp
nine ok
timotimo LMK if something borks 18:52
a new blog post is overdue, and i think i've accumulated some show-off-able things 18:53
also, i can quote you being happy about the tool existing :D
nine Oh, very much so :) 18:59
19:19 Zoffix left 19:20 brrt joined 19:21 p6bannerbot sets mode: +v brrt 19:34 Zoffix joined, p6bannerbot sets mode: +v Zoffix 19:47 AlexDaniel left 19:48 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel 20:02 shareable6 left, shareable6 joined 20:03 p6bannerbot sets mode: +v shareable6, Kaiepi left 20:05 Kaiepi joined 20:06 p6bannerbot sets mode: +v Kaiepi 20:12 ggoebel joined 20:13 p6bannerbot sets mode: +v ggoebel
timotimo glad to not hear any problems from your end :D 20:19
nine Well I got kinda sucked into debuggin this "chars requires a concrete string, but got null" thing. 20:25
It happens because we read "47" as SC handle unless the string heap from nqp::serialize is assembled again in dependencies+deserialize. The funny part is that that one doesn't even contain an SC handle 20:26
The real SC handle "3F0798663524CC53A3ED22C3BCBD30968E7A7301stage2-0" is actually in the right place in the CU's string heap. Looks like the index we're reading is just wrong. But why would that be influenced by the presence of the other string heap? 20:29
20:35 ggoebel left
nine Oh and even more confusing: the bytecode seems to be quite correct. moar --dump prints the dependency SC's handles just fine 20:35
brrt o.O
Are you still compiling mbc in nqp? that's still fairly cool I think :-)
I probably need a rakudo commit bit if I want to really do a cleanup of nativeinvoke....
In fact, what I'd love to have is for nativecall to just do 'invoke' and have the REPR mechanism figure it all out 20:36
nine brrt: yes. Spent the last 2 weeks trying to improve performance to the same level as MoarVM's mbc compiler. And I think the current riddle will be the last necessary step
brrt nine++ 20:37
nine Of course, the last one may be the hardest. None of the parts make any sense.
brrt it may well be that our stuff is broken 20:38
timotimo nine: i wonder if you'd have to change some string object's sc owner to the new one? 20:42
nine timotimo: I can't find the old compiler doing anything like that 20:47
20:48 robertle left
timotimo nowhere in the C either, huh? 20:49
perhaps it hits a serialization write barrier while pushing to the string array
nine none that i can find
timotimo i.e. VMArray's push_o function has a write barrier 20:50
or maybe you have to disable the scwb
20:50 ggoebel joined 20:51 p6bannerbot sets mode: +v ggoebel
nine Ouch. I've got a lead 20:52
20:52 ZofBot left
nine I think MoarVM expects the strings collected during serialization to be at the start of the string heap. 20:53
timotimo that sounds like a thing that could be true
20:57 shareable6 left, reportable6 left, committable6 left, releasable6 left, bisectable6 left, committable6 joined, reportable6 joined, shareable6 joined, releasable6 joined, greppable6 left, bisectable6 joined, notable6 left, greppable6 joined, notable6 joined 20:58 p6bannerbot sets mode: +v committable6, p6bannerbot sets mode: +v reportable6, p6bannerbot sets mode: +v shareable6, p6bannerbot sets mode: +v releasable6, p6bannerbot sets mode: +v bisectable6, p6bannerbot sets mode: +v greppable6, p6bannerbot sets mode: +v notable6
nine And there's already 387 strings in there at the point where I'm adding....darn 21:00
This is gonna be hard :/ The whole endeavour depends on the ability to write out bytecode as we go. That includes adding strings to the heap and getting it's index. This cannot work when there's a block of strings that we only discover during compilation and that we need to write first 21:06
brrt do you want to do a single pass traversal? 21:22
nine absolutely
Anything else would kill performance completely 21:23
brrt and.. is there a way for an earlier pass to collect strings for you?
nine But I wonder if it'd be possible to reverse direction here. Instead of seeding the mbc file's string heap with the serialization's, seed the serialization's with the existing string heap
brrt not sure if I understand the difference 21:24
nine After all, they both work the same and all that counts is that the indexes find the right string
Originally we have 2 pieces of code that collect strings: the data serializer and the MAST compiler. Both end up in the mbc file's string heap. In master, the string heap created by data serialization is used as the starting point for the MAST compiler. 21:26
I think it should work the other way as well: have the data serializer start with an existing string heap
brrt hmm 21:29
nine Well, I'll find out tomorrow. Good night! 21:33
brrt good night 21:36
brrt is going afk as well
21:36 brrt left 22:48 fake_space_whale joined 22:49 p6bannerbot sets mode: +v fake_space_whale 23:46 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke 23:47 MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!