|
00:24
ilmari[m] joined
01:50
unicodable6 joined
02:56
ilbot3 joined
03:23
colomon joined
04:03
evalable6 joined
05:36
quotable6 joined,
evalable6 joined,
nativecallable6 joined,
coverable6 joined,
committable6 joined,
bloatable6 joined,
greppable6 joined,
bisectable6 joined,
releasable6 joined,
unicodable6 joined,
benchable6 joined,
squashable6 joined,
statisfiable6 joined
06:42
brrt joined
|
|||
| brrt | good * #moarvm | 06:47 | |
| nwc10 | good *, brrt | 07:16 | |
| brrt | it was cold this morning | 07:18 | |
| nwc10 | but laptops with busy CPUs are warm and toasty? | 07:19 | |
| brrt | fortunately | ||
| that's why we're working on perl6 | 07:20 | ||
| actually... | |||
|
07:35
domidumont joined
07:54
domidumont joined
08:49
brrt joined
|
|||
| brrt | i may have the ADD CONST -> ADDR resolved | 08:52 | |
|
09:21
robertle joined
|
|||
| jnthn | morning o/ | 09:55 | |
| brrt | morning | 10:13 | |
| getarg_i and stuff, are those new ops | |||
| jnthn | Think so, I'm not sure what getarg_i is doing yet, though | 10:15 | |
| brrt | hehe | ||
| okay | |||
| well, i know to update then | 10:16 | ||
| nine | jnthn: arg_i puts something into the args buffer, getarg_i reads it from there | ||
| jnthn | huh? | ||
| That's what .param is for, no? | |||
| *param_*, I mean | |||
| nine | Yes, but param requires a new callframe which nativeinvoke* doesn't set up | ||
| jnthn | Why would it need to take something out of the args buffer, though? | 10:17 | |
| nine | IOW param_* is from perspective of the callee while getarg_* is from the caller | ||
| rw args | |||
| jnthn | But rw-ness is handled by containers? | ||
|
10:18
domidumont joined
|
|||
| nine | Well I never claimed to understand this stuff :) | 10:19 | |
| jnthn | :) | 10:20 | |
| nine | I did find out that rw args involve LexicalRefs, but failed to actually recognize the design behind them, i.e. the why. | ||
| jnthn | Well, native refs in general | ||
| Could be an attr ref too, or a positional ref | |||
| These are all managed references to a native value stored somewhere | |||
| That is, they keep alive both the container and allow the value to be retrieved inside of it | 10:21 | ||
| The point being that we can pass them around as first-class objects, just as we can with Scalar | 10:25 | ||
| And the reason for pushing this down to the VM level being so that we can later optimize them out over call boundaries when inlining happens | 10:26 | ||
| nine | So taking a step back: how is the process of getting a native rw argument's value into the VM and the new value out and back to the caller? | 10:30 | |
| jnthn | For an int, it'd most easily be done as a decont_i and an assign_i | 10:32 | |
| We can't really pass a pointer directly into the data structure holding the value itself, since if the code in question does a callback and we GC, the thing could move | 10:33 | ||
| I now see why you added getarg_i though: using the args buffer as a place the JITted nativecall can write a result back | 10:34 | ||
| nine | exactly | ||
| jnthn | I guess it'll work out OK | ||
| I just hope we'll not see use of it beyond the JIT :) | 10:35 | ||
| nine | I create a QAST::Var:scope<local>:decl<param>, a QAST::Var:scope<lexicalref>:decl<var>, bind the param to the var, decont it into a QAST::Var:scope<local>:decl<var> and pass that to nativeinvoke. Afterwards I assign_i the value I get from getarg_i to the lexicalref | 10:36 | |
| jnthn | OK, that'll work | ||
| nine | Just feels a bit roundabout with all those variables :) | 10:40 | |
| jnthn | True, though I'd assume the EXPR JIT will be able to eliminate some of the copying :) | 10:41 | |
| brrt | wow, uppercases :-) | ||
| yeagh | |||
| jnthn | haha | ||
| Too much EXPR from the Perl 6 grammar :P | 10:42 | ||
| brrt | making a version of the nativecall JIT that outputs an expr tree is somehwere on the radar | ||
| as are a billion other things | |||
|
10:46
domidumont joined
|
|||
| Geth | MoarVM/jit-expr-optimizer: 8 commits pushed by (Bart Wiegmans)++ | 11:23 | |
|
11:26
cog_ joined
11:31
zakharyas joined
|
|||
| Geth | MoarVM/jit-expr-optimizer: f1306806cc | (Bart Wiegmans)++ | src/jit/optimize.c Eliminate COPY of CONST COPY is opaque for tiling, so the COPY of CONST values disables tiles that operate on a const directly. This allows us to use the CONST value directly which should help us pick better tiles. |
11:32 | |
| brrt | we should have some way to measure the effects | 11:33 | |
| nine | /win 10 | 12:25 | |
| buggable | nine, Thank you for entering Accidental /win Lottery! The next draw will happen in 3 weeks, 2 days, 11 hours, 34 minutes, and 25 seconds | ||
| nwc10 | do we ever get to see the /winner ? | 12:26 | |
| nine | nwc10: irclog.perlgeek.de/moarvm/2017-11-01#i_15383996 | ||
| nwc10 | ooh, thanks, I wasn't aware that it really had a proper ceremony | 12:27 | |
| ilmari | «The next draw will happen in -1 weeks, 6 days, 23 hours, 27 minutes, and 22 seconds» - buggyble? | 12:28 | |
| nwc10 | yes, that | ||
| that was awesome | |||
| irclog.perlgeek.de/moarvm/2017-11-01#i_15384127 | |||
| had that ready to paste | |||
| it's almost enough to be worth staying up for, to see if it's been fixed | |||
| ilmari looks at the logs for 2017-10-01 and 09-01, and sees the logging bot has had at least two different character encoding bugs | 12:30 | ||
| lizmat | ilmari: from what I undertand, irclog runs on Perl 5 with a mod_perl / old MySQL backend | 12:33 | |
| and a database that goes back to the days when DBD::mysql's support for utf-8 was, eh... not optimal | 12:34 | ||
| ilmari | yeah, I guess it got altered to utf8mb4 sometime in the last month | 12:37 | |
| nwc10 | and when running something persisent on Rakudo would have leaked memory like the Jumblies preferred maritime transport | 12:39 | |
|
13:02
brrt joined
13:06
lizmat joined
|
|||
| lizmat | jnthn: if Thread.start fails for some reason, is it correct that it doesn't return ? | 13:58 | |
| jnthn | I'd expect an exception if it's a failure the VM can recover from | 13:59 | |
| lizmat | ah, it never reaches the code after the Thread.start because of the exception: duh! | 14:02 | |
| jnthn | Yeah, the thread that tried and failed to start another one is the one where we'd report it. | 14:03 | |
| lizmat | it would be nice if we could stop one short of actually using the last thread | 14:08 | |
| hmmm... unless... | |||
| signals, do they run on the general workers, jnthn? | |||
| jnthn | We can't know. | ||
| Yes. | |||
| lizmat | perhaps it's an idea to run them on affinity workers or timer workers ? | 14:09 | |
| jnthn | Why? | ||
| lizmat | so that *if* all threads are in use, we can still safely control-c out of it ? | ||
| and with the snapper, perhaps find out what was going on ? | 14:10 | ||
| jnthn | An affinity thread can be every bit as in use as a general one | ||
| Timer ones I guess we do advise people not to do long-running things on, but we can't prevent them from doing that | |||
| I guess we could view signals as kind of "urgent" though and scheduler them on the timer thread. | 14:11 | ||
| lizmat | perhaps we need a seperate thread for handling signals, apart from all of the other ones > | ||
| jnthn | *schedule | ||
| That just moves the problem :) | |||
| And means yet more kinds of worker | |||
| Which isn't really that ideal | |||
| If you only have 4 cores, and we have 4 types of worker, then the most you're going to then get without triggering the heuristic deadlock detection is one of each | 14:12 | ||
| lizmat | hmmm... maybe I should look a little deeper into how signals are actually hooked up again | ||
| jnthn | Doing them on the timer thread could be a decent compromise, though | ||
| I don't think it can make things worse, and for some cases it may make them better. | |||
| lizmat | I mean, yes, you want signals to be delivered in time, so, that in a way makes sense | ||
| jnthn: I'll make the change... | 14:13 | ||
| yeah, that improves things | 14:18 | ||
|
15:06
lizmat joined
15:31
brrt joined
15:41
brrt joined
16:28
brrt joined
16:47
lizmat joined
17:19
zakharyas joined
17:50
domidumont joined
20:04
domidumont joined
20:12
zakharyas joined
20:53
unicodable6 joined
21:07
zakharyas joined
21:22
MasterDuke joined
22:24
brrt joined
22:56
colomon joined
|
|||
| ugexe | libuv has exposed a uv_os_getppid in the last version bump... should we use it for a MVM_proc_getppid so child processes can tell when their parent process has exited? | 23:10 | |
| MasterDuke | oh, there's also something about ttys: `* unix, windows: map ENOTTY errno (Ben Noordhuis)` | 23:14 | |
| there's been a bunch of work recently related to detecting TTYs i think, maybe that'll help | 23:15 | ||
| timotimo | hm, that sounds more like getting the proper error message when some only-tty-action is used on a non-tty file descriptor? | 23:17 | |
| ugexe | one just exposes constant ENOTTY and the other is for win7 i believe. any other ones we should already have from the last version bump. | ||
|
23:50
lizmat joined
|
|||