| timotimo | wow, tc being 0 inside an MVM_interp_run | 00:21 | |
| that's novel | |||
| with --optimize=0 tc stays non-0, but here i have an unbox_i that blows because the object is low-level-null | 00:25 | ||
| all of this while i'm trying to profile a thing | 00:27 | ||
| looks like it's trying to throw an exception of type X::Multi::NoMatch | 00:29 | ||
| without the profiler it - unsurprisingly - works | 00:30 | ||
| the explosion with the unbox_i happens inside a piece of regex code used by the message method via a few layers of indirection | 00:31 | ||
|
01:48
ilbot3 joined
|
|||
| samcv | wow | 01:58 | |
|
03:08
geekosaur joined
07:12
brrt joined
07:41
domidumont joined
07:47
domidumont joined
07:59
zakharyas joined
08:41
robertle joined
09:23
AlexDaniel joined
09:41
geekosaur joined
09:51
geekosaur joined
|
|||
| brrt | good hi #moarvm | 09:52 | |
| Geth | MoarVM/even-moar-jit: ae9607697a | (Bart Wiegmans)++ | src/jit/linear_scan.c Factor comparison out of live range heap I want to maintain two different orders for the live range heap, i.e. on the first_ref ascending order, and on last_ref ascending order, for the values that are supposed to become active and for the values that have been spilled respectively. So I've factored the comparison function out of the live range heap. A 'generic' binary heap in C would either require dynamic allocation (to maintain space for the temporary when swapping) or be written with macros. I don't find either solution very appealing. |
||
| MoarVM/even-moar-jit: b06409d258 | (Bart Wiegmans)++ | 5 files Register type of allocated spill memory Use a bucketed free list to manage spill locations, and construct the new local types array during JIT assembly. The GC still needs to be convinced to look at it. |
|||
| brrt | the binary heap thing finally got me to see some of the benefits of c++ | 10:01 | |
|
10:54
brrt joined
12:48
brrt joined
|
|||
| Geth | MoarVM: 78bed96569 | (Jonathan Worthington)++ | 16 files Stub in setbuffersizefh and IO vtable entry for it Will be used to enable output buffering and to pick the size of the output buffer. |
13:30 | |
| MoarVM: 67f718a6e5 | (Jonathan Worthington)++ | 6 files Follow op naming conventions consistently. |
13:35 | ||
|
14:13
AlexDaniel joined
|
|||
| Geth | MoarVM: 7405dfa9e0 | (Jonathan Worthington)++ | 2 files Implement output buffering for sync file handles. Which can give a big performance improvement when writing lots of small pieces (like a line at a time) to a file. |
14:17 | |
| nine | So each output handle will now have a malloced buffer. Does that mean the GC has to be made aware of that to correctly estimate memory consumption? | 14:21 | |
| jnthn | We've only typically applied pressure where it's liable to be an issue | 14:23 | |
|
14:23
colomon joined
|
|||
| jnthn | Also going to add in logic to free the buffer at .close | 14:23 | |
| (And GC if last gasp) | |||
| timotimo | if you make gigantic buffers per file, it could even cause a problem, but if we delete the buffer when you close the fh, it's no problem, because you got the file descriptor limit anyway | ||
| jnthn | But since you run out of handles anyway if you don't .close, and the buffer is not typically large, you'd run out of handles first | 14:24 | |
| nwc10 | you get into this interesting thing here that doesn't seem to be a mandated "feature" of stdio libraries, but all the "sane" ones I've found seem to do it | 14:25 | |
| which is to flush the output buffer of STDOUT when attempting a read from STDIN | |||
| jnthn | We | ||
| d'oh | |||
| We'll have to see if we really need that I guess | |||
| nwc10 | or, more nuanced, seems to be "flush the output buffer of anything outputing to tty when about to block on the read from a tty" | ||
| jnthn | If we do then it would be implemented at Perl 6 level | ||
| Oh | 14:26 | ||
| nwc10 | you need it to make interactive programs behave the was the user expects | ||
|
14:26
domidumont joined
|
|||
| jnthn | I thought stdio didn't buffer *at all* when it's a tty? | 14:26 | |
| nwc10 | you might be right, but I thought that it tended to be "line buffering" | ||
| jnthn | Ah, right | ||
| nwc10 | but the trick described is needed to make "line buffering" work when they did (pseudcode): | ||
| jnthn | Any feeling is, for now, we'll just not buffer to tty at all | ||
| nwc10 | print "Tell me your number:"; | ||
| $number = <>; | 14:27 | ||
| where there's no newline on the prompt string, but the programmer sort of magically assumed that somehow it will appear on the screen before the user starts to type stuff in | |||
| jnthn | The other thing we need to arrange for is to .flush $*OUT and $*ERR at exit, which I guess we can do with an END block | ||
| nwc10 | anyway, I should stop being PEBKAC for this keyboard and chair, and go get a train to a different keyboard and chair | 14:28 | |
| jnthn | Ah, and that's why the write-on-read would help | ||
| So much output to stdout/stderr is lines already though | |||
| So if you are only ever buffering until a line break...I'm wondering when that's even a win | 14:29 | ||
| I figure we'll introduce it slowly, anyways | 14:42 | ||
| For now, so slowly that you need to say :buffer or :4096buffer or so | |||
| After that we can switch it on by default for anything you open that isn't a TTY | |||
| And then with time for standard handles if they're not bound to a TTY | 14:43 | ||
|
14:44
travis-ci joined
|
|||
| travis-ci | MoarVM build failed. Jonathan Worthington 'Follow op naming conventions consistently.' | 14:44 | |
| travis-ci.org/MoarVM/MoarVM/builds/245373104 github.com/MoarVM/MoarVM/compare/7...f718a6e586 | |||
|
14:44
travis-ci left
|
|||
| jnthn | ah, was a MOAR_REVISION bump race | 14:45 | |
| nine | I wonder if nowadays buffering is even important on ttys. Well maybe for ssh sessions over crappy mobile connections. | 14:47 | |
| timotimo | let mosh handle that problem :) | 14:48 | |
| jnthn | nine: iiuc, line buffering means you can only buffer one line at a time | ||
| timotimo | did you see that thing where you can figure out the password someone's typing based on timing from the ssh packets? | ||
| jnthn | But 99% of the output people will do with TTYs in Perl 6 is with `say`, I reckon | 14:49 | |
| timotimo | and for the situation "print half a line the nask for input" we have "prmpt" anyway | 14:50 | |
| which could do the flush for you | |||
| jnthn | It already does | ||
| timotimo | splendid | ||
| jnthn | But I'm saying we won't buffer TTYs *at all* anyway :) | ||
| We'll just take the path we do today | |||
| So no change | |||
| brrt hasn't yet switched to mosh in spite of its obvious benefits | 14:57 | ||
| Geth | MoarVM: 888b33d199 | (Jonathan Worthington)++ | src/io/syncfile.c Clean up output buffer on close and GC free. |
||
|
15:14
domidumont joined
16:09
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Jonathan Worthington 'Clean up output buffer on close and GC free.' | 16:09 | |
| travis-ci.org/MoarVM/MoarVM/builds/245405485 github.com/MoarVM/MoarVM/compare/7...8b33d199ce | |||
|
16:09
travis-ci left
16:56
colomon_ joined
17:17
TimToady joined
17:25
AlexDaniel joined
17:37
brrt joined
20:39
AlexDaniel joined
21:04
AlexDaniel joined
|
|||