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