Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-10-01

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:00 timotimo but still, starting, running and terminating the uv loop every time we want to read or write isn't terribly good
00:00 timotimo performance wise
00:02 leont It depends, really
00:02 timotimo in this case it's multiple short lines of text
00:02 timotimo and going via nativecall into puts gives much better performance than going through nqp::say
00:03 timotimo and there's quite some overhead to NativeCall.
00:04 leont But what if say would have blocked? (e.g. on a pipe or socket)
00:04 timotimo what about it?
00:05 timotimo we literally start the event loop, add a single thing to it - in this case stdout - and register a callback that immediately removes the thing from the event loop again, then we wait for the event loop to terminate
00:05 cognominal joined #moarvm
00:05 timotimo if it blocks, who cares, we block on the result anyway
00:53 tokuhiro_ joined #moarvm
02:54 tokuhiro_ joined #moarvm
03:13 tokuhiro_ joined #moarvm
06:09 FROGGS joined #moarvm
06:36 Ven joined #moarvm
07:29 Ven joined #moarvm
10:04 lizmat joined #moarvm
10:28 zakharyas joined #moarvm
11:14 Ven joined #moarvm
12:02 FROGGS[tab] joined #moarvm
12:47 zakharyas joined #moarvm
13:22 Ven joined #moarvm
14:12 FROGGS[tab]_ joined #moarvm
14:23 Ven joined #moarvm
14:52 Ven joined #moarvm
15:16 tokuhiro_ joined #moarvm
15:17 [Coke] where is the mvm sub 'endprofile' implemented?
15:18 [Coke] ah. it calls MVM_profile_end...
15:20 [Coke] and the question should have been "mvm op", not "mvm sub". my bad.
15:26 lizmat joined #moarvm
15:39 cognominal joined #moarvm
15:39 Ven joined #moarvm
15:59 Ven joined #moarvm
16:18 tokuhiro_ joined #moarvm
16:26 Ven timotimo: %rip is the current instruction pointer, right? I don't understand why there's a word&long version of this register.. for historical purpose?
16:26 Ven (asking timotimo++ because brrt++ isn't here :P)
16:26 Ven (erm, *next* instruction pointer)
16:40 jnthn .oO( It's called "rest in peace" 'cus that instruction will be retired soon... )
17:11 Ven joined #moarvm
17:33 Peter_R joined #moarvm
17:42 FROGGS joined #moarvm
18:19 tokuhiro_ joined #moarvm
18:54 leont joined #moarvm
19:06 vendethiel joined #moarvm
19:38 tokuhiro_ joined #moarvm
20:41 vendethiel joined #moarvm
20:46 colomon joined #moarvm
20:58 mtj_ joined #moarvm
21:12 leont timotimo: hmm, that does sound suboptimal (re: say)
21:13 jnthn The big problem we have with sync I/O things at the moment is that handles end up having thread affinity in libuv
21:14 jnthn For async I/O it's all async, so nothing is blocking on it, so it's fine we throw all the work in a queue and a single thread is dedicated to running the event loop
21:14 jnthn But for sync I/O that model would create fairly intolerable overhead.
21:14 jnthn I mean, if what we have now ain't tolerable, that ain't gonna be :)
21:16 jnthn (The Moar async I/O event loop thread never actually runs any userland code at all, it just takes work from an input queue and shoves callbacks to run in the scheduler queue you give it with the task)
21:17 jnthn In hindsight, shoving all of our sync I/O stuff also through libuv was probably not so wise.
21:17 jnthn It seemed like a good idea to outsource handling platform specific things
21:18 jnthn But given you can count the platforms we care to support in the near future on the fingers of one hand, and even then it's basically POSIX and Windows, that probably wasn't so big a win either.
21:18 jnthn And the cost is that people pass sync handles around between threads and get really weird behavior.
21:19 leont I'm still observing async IO issues with Proc::Async :-/
21:19 jnthn Such as?
21:20 leont It works fine as long as I have only one of them
21:20 leont If I have two, things blow up
21:20 jnthn :/
21:20 leont First is missing part of its data, second is hanging (and my signal handler isn't responding either)
21:20 leont (for sigint)
21:23 * jnthn did have a Proc::Async thing running really nicely a month or two back
21:23 jnthn Wonder what happened
21:23 leont I've never seen it work nice
21:23 leont At least not with multiple processes
21:23 jnthn The thing I had ran a bunch of 'em.
21:24 jnthn Heck, I used it to manage a load of concurrent scp processes about a year ago after I first added it, and it was pretty stable.
21:24 * jnthn should perhaps try things on more than one platform. :)
21:24 leont I don't know, maybe I'm doing something terribly wrong
21:25 jnthn Maybe, but it still sounds like something's wrong.
21:25 jnthn Is the thing you're trying to run anywhere I can try it out next week, once I'm back from teaching?
21:25 jnthn bah, was that sentence even English... :)
21:25 leont Just pushed a testing branch to tap-harness
21:26 jnthn OK
21:26 jnthn Found it
21:26 leont It's triggered by running bin/prove6 (against any p6.t)
21:27 jnthn OK, will give it a try next week (or maybe at weekend) and see what I can reproduce.
21:27 leont Thanks :-)
21:28 jnthn my $timer = $done.then({ now - $start-time });
21:28 jnthn cute!
21:29 leont I'm planning to try to convert t/harness to it, and see what happens. Not having parallelization is suboptimal, but not a blocker at this stage I suppose.
21:29 jnthn ah, but
21:29 jnthn my $done = $process.start();
21:30 jnthn Are you using that promise to determine when the process ends?
21:30 leont Yes, the harness class is awaiting all those promises
21:32 jnthn OK
21:33 jnthn I'll have a look into it
21:33 jnthn But, teaching tomorrow, so I'd better rest now :)
21:33 jnthn 'night
21:33 timotimo gnite jnthn!
21:33 leont Good night!
21:41 tokuhiro_ joined #moarvm
23:15 zakharyas joined #moarvm
23:42 tokuhiro_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary