|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:17
leont left
00:23
RJ7225 joined,
RJ7225 left
00:51
yybel10 joined,
yybel10 left
02:00
AlexDaniel left
04:09
lizmat left
04:29
MasterDuke left,
lizmat joined,
p6bannerbot sets mode: +v lizmat
04:33
lizmat left
|
|||
| Geth | MoarVM: 40786774c7 | (Samantha McVey)++ | tools/update-changelog.p6 Save in separate file for ecah release for update-changelog.p6 - Also make the view options a bit more object oriented. - Fix a few assorted bugs - Add the ability to save at the end, instead of magically quitting without saving - Fixed it so commit info is actually configurable in the interface |
05:28 | |
| MoarVM: 009ccba3b1 | (Samantha McVey)++ | docs/ChangeLog Update ChangeLog for release |
05:49 | ||
|
06:35
Ven`` joined
06:36
p6bannerbot sets mode: +v Ven``
06:39
Ven`` left
06:48
Ven`` joined
06:49
p6bannerbot sets mode: +v Ven``
06:56
Ven`` left,
Ven`` joined
|
|||
| Geth | MoarVM/refs/tags/2018.09: e6d509d422 | (Samantha McVey)++ | VERSION Update VERSION for release 2018.09 |
06:56 | |
| MoarVM: e6d509d422 | (Samantha McVey)++ | VERSION Update VERSION for release 2018.09 |
|||
|
06:57
p6bannerbot sets mode: +v Ven``
07:05
Ven`` left
07:19
gpocentek9 joined,
gpocentek9 left
07:24
Ven`` joined
07:25
p6bannerbot sets mode: +v Ven``
07:28
Ven`` left
07:29
domidumont joined
07:30
p6bannerbot sets mode: +v domidumont
07:33
Ven`` joined
07:34
p6bannerbot sets mode: +v Ven``
07:59
domidumont left
08:01
Ven`` left
08:11
domidumont joined
08:12
p6bannerbot sets mode: +v domidumont
08:18
lizmat joined,
p6bannerbot sets mode: +v lizmat
08:22
Ven`` joined,
p6bannerbot sets mode: +v Ven``
08:24
lizmat left
08:26
lizmat joined,
p6bannerbot sets mode: +v lizmat
08:34
domidumont left
|
|||
| nine | timotimo: but pushing byte by byte will also cause a lot of reallocations, won't it? | 08:44 | |
|
08:45
tabularasa19 joined,
tabularasa19 left
|
|||
| timotimo | a) you can setelems n + setelems 0 up front, b) our buffers grow by 2x increments up to a very large number, so the cost of realloc is amortized | 08:47 | |
| i'd honestly be more worried that the allocated buffer could be too big after you pushed to it without giving an exact size | 08:52 | ||
| nine | Ah, so setelems 0 will reset the position but keep the allocation? That's certainly good to know | ||
| Too big for what? | |||
| timotimo | well, i mean if the buffer was just 1 byte too small, it'll be resized to double its size to write that one byte | 08:53 | |
| though i guess a defensive copy would be a good idea anyway | 09:05 | ||
| oh and our buffers have a start position that's not a valid pointer for free() anyway | 09:07 | ||
| well, potentially | 09:08 | ||
| it's not like you unshift bytes to the buffer anyway | |||
|
09:19
undersightable6 joined,
p6bannerbot sets mode: +v undersightable6
09:28
domidumont joined
09:29
p6bannerbot sets mode: +v domidumont
09:30
domidumont left
|
|||
| nine | Btw. 26316183 calls to $buf.push when compiling the setting :) | 09:37 | |
| lizmat | wow | 09:38 | |
| I assume that's NQP, right, so no use doing nqp::push ? | |||
| nine | The whole thing is: 'push', method (uint8 $value) { nqp::push_i(self, $value) } | 09:39 | |
| lizmat | yeah, so that should have been inlined already | 09:41 | |
| nine | nqp::setelems does not seem to speed up write_buf in any way | 09:48 | |
| lizmat | I'm not sure what the initial alloc of a buffer does internally | 09:49 | |
| perhaps that's already big enough for most cases ? | |||
|
09:50
leont joined
09:51
p6bannerbot sets mode: +v leont
|
|||
| nine | Minimum allocation is 8 elems. That gets doubled for each reallocation up to 8 KiB. After that we extend by 4 KiB. | 09:54 | |
| So while the setelems will in fact safe quite a few reallocs, it's mostly tiny ones (like 4 + 12). | 09:55 | ||
| timotimo | ah, i thought you had mostly one gigantic buffer | 09:57 | |
| lizmat | does min allocation of 8 elems make sense on current hardware ? | 09:58 | |
| I assume that 64 bits ? | |||
| yeah, uint8 ones | |||
| nine | No. At least not yet. And maybe not ever. Could be simply more performant e.g. to assemble a buffer for each frame and stitch them together than to iterate over the tree first to get the size then to actually assemble. | ||
| timotimo | that's fair | 09:59 | |
| nine | Wow....simply inlining that nqp::push_i from self.push in write_buf takes mbc time down from 11.3s to 8.4 | ||
| lizmat | aha! | ||
| nine | Now I really wonder how much further it goes when I use nqp::splice instead ;) | 10:00 | |
| lizmat | perhaps the new nqp::slice could also be of use ? | ||
| timotimo | i'd imagine you'll mostly be copying full buffer contents rather than pieces | 10:01 | |
| lizmat | just mentioning in case nine missed its arrival: github.com/perl6/nqp/blob/master/d...down#slice | ||
| timotimo | right | 10:02 | |
| nine | I missed that indeed | 10:03 | |
| How can I get an "MVMArray: bindpos expected int register" in this line? nqp::splice(self, @buf, nqp::elems(self), 0); | 10:11 | ||
| timotimo | oh, do we just not implement splice for arrays other than _o? | 10:12 | |
| should be an easy-ish fix | |||
| nine | I don't see anything _o specific in VMArray's asplice | 10:13 | |
|
10:13
zandy3 joined,
zandy3 left
|
|||
| timotimo | copy_elements uses a kind value to select the right type | 10:14 | |
| lizmat | yeah, I thought nqp::splice was DWIM ? | ||
| *nqp::slice | 10:15 | ||
| nine | copy_elements should use memcpy for arrays with the same slot type. Which they should be in this case | 10:16 | |
| timotimo | have you set a breakpoint for that exception? | 10:17 | |
| surely it's just some simple mistake | |||
| nine | Except of course when write_buf is called from get_callsite_id :) | 10:18 | |
| timotimo , not knowing the code itself, doesn't know why that is a thing | 10:19 | ||
| nine | That's the one place where I don't have a uint8 buffer but some @flags list | ||
| Trivial fix | 10:21 | ||
| There goes another second. Down to 7.3s | 10:24 | ||
| Don't you love the first steps in optimizing anything? 50 % off with just a couple trivial changes | |||
| timotimo | oh yeah | 10:25 | |
| i enjoyed it very much when i was able to get that cellular automaton to an exact 1_000_000 cells/second | |||
|
10:34
Ven`` left
11:04
ZofBot left
11:05
ZofBot joined,
p6bannerbot sets mode: +v ZofBot
11:11
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke
11:12
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
11:49
Ven`` joined
11:50
p6bannerbot sets mode: +v Ven``
|
|||
| nine | 6.895 will all write_* methods converted to using write* ops. And that's with those ops not getting JITed and their implementation being quite primitive (loops over calls to bind_pos) | 11:58 | |
|
12:13
Carefully joined,
Carefully left
|
|||
| nine | The much harder part will now be to get rid of (most of) the MAST stage. | 12:36 | |
|
13:40
hsmiths1 joined,
hsmiths1 left
|
|||
| diakopter | nine: yep that's the one with tons of higher-order functions :) | 13:42 | |
| nine: written that way for extreme convenience at the time, but.... yeah | |||
| for the life of me I really don't know another way to do the virtual registerizing | 13:43 | ||
| I'm guessing contextuals eat a lot of time though | 13:44 | ||
| nine | 0.4 seconds saved by merging MoarVM::Frame into MAST::Frame :) | 13:57 | |
| lizmat | nine: so is it already faster than the "normal" mbc stage ? | 14:29 | |
| nine | No, no, no, that takes just 0.3 seconds total :) | 14:31 | |
| I can't see this become that fast. But this has the potential of making the mast stage faster. So total compilation time may go down | 14:32 | ||
| lizmat | ah, ok, well, lower total compilation time would be welcome :-) | 14:41 | |
|
15:24
fundies joined,
fundies left
15:53
MasterDuke left
15:58
jnphilipp joined,
jnphilipp left
|
|||
| nine | Getting rid of MAST::Op and instead creating the piece of bytecode directly was surprisingly easy! | 16:01 | |
| timotimo | cool | ||
| lizmat | nine++ | 16:02 | |
| nine | Doesn't help performance right now because instead of a MAST::Op object I still have to create a new bytecode buffer. But once I've done the same with all instruction types, I should be able to write to the frame's bytecode buffer directly instead. | ||
|
16:39
Ven`` left
|
|||
| timotimo | btw, nqp::list_i will already codegen a setelems $n + setelems 0 for you | 16:44 | |
| lizmat | timotimo: how does it know how many elements? | 16:47 | |
| or do you mean: nqp::list_i(4,5,6) ? | |||
| timotimo | that's what i mean | 16:48 | |
| lizmat | ah, ok | ||
| timotimo | but of course nine will not be using list_i | ||
| lizmat | only list_i, not list ? | ||
| timotimo | because the bytecode buffers need to have 8bit entries, not 64bit | ||
| i think all of 'em do | |||
|
16:56
Ven`` joined,
p6bannerbot sets mode: +v Ven``
|
|||
| lizmat | but an nqp::list_i is 64bit, no ? | 16:57 | |
|
17:00
Ven`` left
|
|||
| timotimo | yes | 17:03 | |
| that's why nine won't be using list_i | |||
|
17:26
domidumont joined
17:27
p6bannerbot sets mode: +v domidumont
18:17
Amt13 joined,
Amt13 left
18:25
fake_space_whale joined
18:26
p6bannerbot sets mode: +v fake_space_whale,
dzan5 joined,
dzan5 left
18:41
domidumont left
19:14
Redfoxmoon joined,
Redfoxmoon left,
Redfoxmoon joined,
p6bannerbot sets mode: +v Redfoxmoon
20:16
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
20:55
niron11 joined,
niron11 left
21:10
undersightable6 left,
undersightable6 joined,
coverable6 joined
21:11
p6bannerbot sets mode: +v undersightable6,
p6bannerbot sets mode: +v coverable6
21:24
pbek2 joined,
pbek2 left
22:00
fake_space_whale left
22:13
fake_space_whale joined
22:14
p6bannerbot sets mode: +v fake_space_whale
23:03
pakettiale25 joined,
pakettiale25 left
23:13
catfat11 joined,
catfat11 left
23:24
Ven`` joined,
p6bannerbot sets mode: +v Ven``
23:29
Ven`` left
|
|||