|
00:57
brrt joined
05:49
mojca joined,
mojca left
|
|||
| nwc10 | "we have unknown Moar users?" "well, we're about to find out" | 05:53 | |
|
05:53
domidumont joined
05:59
domidumont joined,
brrt joined
|
|||
| brrt | good * #moarvm | 06:00 | |
| so, the other side of the equation is, why not do copy uppropagation | 06:14 | ||
| eh | |||
| const | |||
| the tl;dr is: rather than have the register allocator do the work to ensure we never spill a const | |||
| why not replicate all const nodes | 06:15 | ||
| (actually, i know part of the answer, which is that if we do that, we make common subexpression elimination that much more complex) | |||
| but still, the idea that a const node always has just one referent, and that is not a copy, that seems like a legit optimizaton | |||
| makes for better tiling, too | 06:16 | ||
|
06:46
brrt joined
06:51
AlexDaniel joined
|
|||
| brrt | so i'm going to put it on the optimizations queue | 07:38 | |
| idea | 07:57 | ||
|
07:58
zakharyas joined
|
|||
| brrt | what if i add some functionality to insert a breakpoint in the JIT compiler at a specific point, and, what if i hide these things behind a debug compile flag | 07:58 | |
|
08:56
avarab joined
|
|||
| jnthn | morning o/ | 08:59 | |
|
09:00
Voldenet_ joined
|
|||
| jnthn | brrt: At some point we'll need to handle users inserting breakpoints into optimized code and how we'll cope with that :) | 09:04 | |
| brrt | thats actually a decent question | ||
| jnthn | The const copy thing is the classic phase order issue. I guess "do CSE first" might be a way out of it. | ||
| brrt | uhuh | ||
| jnthn | But there's no general "best order" for optimizations. | ||
| If you know they all converge you can iterate to a fixed point | |||
| brrt | part of the answer is 'make sure you have a 'user level breakpoint' | ||
| nwc10 | I thought that Knuth's "best order" was don't :-) | ||
| or, more "don't. don't. oh, go on then, if you really have to" | |||
| brrt | well, some opts make some others impossible | ||
| so yeah | |||
| jnthn | nwc10: Life's a bit different for us, since we're trying to make the user's code run fast enough that *they* can follow the Knuth advice :) | ||
| nwc10 | you and your sensible answers :-) | 09:05 | |
|
09:05
Voldenet joined
|
|||
| jnthn is surprised he can answer at all after sleeping pretty awfully :S | 09:06 | ||
| Ah, time to kill off write_str form the I/O vtable thingy | 09:07 | ||
| Geth | MoarVM/remove-sync-char-io: 21de1c453f | (Jonathan Worthington)++ | 2 files Remove now-unused string constants. |
09:15 | |
| MoarVM/remove-sync-char-io: e993fe5294 | (Jonathan Worthington)++ | 5 files Re-implement print/say debug output ops. They now encode and then write the bytes to the handle, in preparation for the string-based output API being removed. |
09:31 | ||
| jnthn | Righty, *now* I can kill it off :) | 09:32 | |
| Geth | MoarVM/remove-sync-char-io: bfca6545e8 | (Jonathan Worthington)++ | 7 files Remove string output from I/O layer. This completes the removal of char-level I/O. |
09:37 | |
| jnthn | Well, sort of | ||
|
09:55
AlexDaniel joined
09:58
committable6 joined
|
|||
| Geth | MoarVM/remove-sync-char-io: c1805fc76a | (Jonathan Worthington)++ | src/io/syncfile.c Remove use of decode stream in syncfile. |
10:56 | |
| Zoffix | \o | ||
| I mean \o/ | |||
| nwc10 | stupid question, I think - what is it about that commit that is particularly \o/ ? | 10:58 | |
| jnthn | I'm not sure :P | 10:59 | |
| Except the next step for syncfile will be eliminating libuv there | |||
| Zoffix | Won't this work make stuff like `await start get` not crash? | ||
| jnthn | Zoffix: Not that step alone, no, but that's what I'm working towards, yes :) | 11:00 | |
| Zoffix | Well, the \o/ was about the general thing :D | ||
| jnthn | Lunch time; bbl | 11:13 | |
|
11:20
domidumont joined
|
|||
| [Coke] | trac.macports.org/ticket/54259 , btw. one person reporting a build error on an old version of OS X. | 12:41 | |
| jnthn | Heh, so I get back to my keyboard and the first thing I see is a tweet saying github have major service outrages... | 12:42 | |
| *outages | |||
| lizmat | yeah, my last push took about 30 seconds before it got through | ||
| jnthn | timotimo: ^^ trac thing is telemetry related | 12:43 | |
| Geth | MoarVM/remove-sync-char-io: dff6a4198f | (Jonathan Worthington)++ | 3 files Eliminate decodestream for syncstream. And also, as part of that, syncpipe. |
13:08 | |
| jnthn | Alrighty, I think I'm going to merge this remove-sync-char-io branch 'cus, well, the char I/O is removed | 13:09 | |
| And then will make a separate branch for giving syncfile its libuv-sectamy | |||
| syncstream is harder | |||
| Because of syncpipe still using it | |||
| Which is tied to libuv because of process stuff | 13:10 | ||
| Meaning sorting it out depends on the rewrite of Proc in terms of Proc::Async | |||
| That in turn depends on making Proc::Async on JVM | 13:11 | ||
| nwc10 | I was about to type "that tower only has 4 yaks", and then a fifth appeared | ||
| jnthn | As well as making Proc::Async do the things that Proc does but Proc::Async does not | ||
| nwc10 | six | ||
| jnthn | Yeah, indeed | ||
| This will in turn let us stop maintaining two sets of proc code | 13:12 | ||
| Which will be nice | |||
| Geth | MoarVM/master: 12 commits pushed by (Jonathan Worthington)++ review: github.com/MoarVM/MoarVM/compare/f...dff6a4198f |
13:13 | |
| jnthn | 23 files changed, 182 insertions(+), 764 deletions(-) | 13:14 | |
| lizmat | whee | ||
| jnthn | That's the kind of merge I like :) | ||
| brrt | :-o wow | 13:16 | |
| jnthn++ | |||
| anyway, re: breakpoint insertion | 13:27 | ||
| i'm not sure if we do that at all at this point, and if it needs VM-level support | 13:28 | ||
| jnthn | We don't yet. It will. | 14:34 | |
| Remote debug API is somewhere on my list of things to design :) | 14:35 | ||
| brrt | okay, well | 14:37 | |
| we can, if we're JITting, signal ourselves a breakpoint interrupt | |||
| that's pretty easy | |||
| not sure if it is the right thing to do, though | |||
| i'm wondering if there isn't some data flow analyzer for assembly code | 14:40 | ||
| jnthn digs his slightly frazzled brain back into syncfile | 14:41 | ||
|
15:10
brrt joined
15:14
KDr2 joined
|
|||
| Geth | MoarVM/sync-file-no-uv: 3734a1dcf8 | (Jonathan Worthington)++ | src/io/syncfile.c Eliminate libuv in the heart of syncfile. Still a handful of uses left, still be be eliminated. |
15:15 | |
| jnthn | Happily, that doesn't regress spectest. | 15:17 | |
| Geth | MoarVM/sync-file-no-uv: e5ada450a2 | (Jonathan Worthington)++ | src/io/syncfile.c Implement truncate without libuv. |
15:25 | |
|
15:29
AlexDaniel joined
|
|||
| Geth | MoarVM/sync-file-no-uv: fef4f2e9b4 | (Jonathan Worthington)++ | 3 files Re-implement flush without using libuv. The Windows part is so far untested, so may have issues. |
15:37 | |
| [Coke] | jnthn: is the goal to completely remove libuv? | 15:38 | |
| jnthn | [Coke]: Only from sync I/O | 15:39 | |
| For async, threading abstractions, etc. it's staying | |||
| Basically, it's going away for the places where we've been having trouble with the handle sharing issues | 15:40 | ||
| Where you couldn't accept a sync socket on one thread and then hand it off to another to work with (fixed already), or do stuff like prompt on a thread (what I'm sorting out now) | 15:41 | ||
| In those cases the APIs are relatively portable anyway | 15:42 | ||
| Enough for now...a bit tired. | 15:48 | ||
| brrt | okay, breakpointing env var is on its way | 15:53 | |
| breakpointing env var works | 15:56 | ||
|
16:21
domidumont joined
16:37
robertle joined
17:21
buggable joined
19:36
AlexDaniel joined
20:59
geekosaur joined
22:07
dogbert17 joined
22:54
sivoais joined
|
|||
| samcv | good ???? | 23:08 | |
| buggable | ???????????? It's time for the monthly Accidental /win Lottery ???????????? We have 14 ballots submitted by 10 users! DRUM ROLL PLEASE!... | 23:59 | |