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|
|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|
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
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.|
|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|
|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.
|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.
|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.
|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.
|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|
|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.
|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|
|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)++
|jnthn||23 files changed, 182 insertions(+), 764 deletions(-)||13:14|
|jnthn||That's the kind of merge I like :)|
|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|
|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.
|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: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.
|[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
|buggable||???????????? It's time for the monthly Accidental /win Lottery ???????????? We have 14 ballots submitted by 10 users! DRUM ROLL PLEASE!...||23:59|