|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:26
Enrico_Menotti9 joined,
Enrico_Menotti9 left
00:37
Armadillo joined,
Armadillo left
01:07
julius16 joined,
julius16 left
01:37
zakharyas joined
01:38
p6bannerbot sets mode: +v zakharyas
02:14
G-virt12 joined,
G-virt12 left
03:02
mattp__29 joined,
mattp__29 left
03:37
MasterDuke left
03:58
btyler left
03:59
btyler joined
04:00
p6bannerbot sets mode: +v btyler
04:04
lizmat left
05:53
AlexDaniel left
05:59
domidumont joined
06:00
p6bannerbot sets mode: +v domidumont
06:09
domidumont left
06:51
domidumont joined
06:52
p6bannerbot sets mode: +v domidumont,
Danielss890 joined,
Danielss890 left
07:14
robertle joined
07:15
p6bannerbot sets mode: +v robertle
07:38
SirHellsing29 joined,
SirHellsing29 left
08:00
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
|
|||
| AlexDaniel | samcv: any news? :) | 08:02 | |
|
08:15
brrt joined
08:16
p6bannerbot sets mode: +v brrt
08:25
CaOsKid23 joined,
CaOsKid23 left
|
|||
| brrt | \o | 08:37 | |
|
08:49
Fabricio205 joined,
Fabricio205 left,
dev1990_ joined,
dev1990_ left
09:16
brrt left
09:48
leont joined
09:49
p6bannerbot sets mode: +v leont
10:11
zakharyas left
10:33
Telsin27 joined,
Telsin27 left
10:41
Ven`` joined
10:42
p6bannerbot sets mode: +v Ven``
10:49
Ven`` left
11:00
AlexDaniel left
11:29
zakharyas joined
11:30
p6bannerbot sets mode: +v zakharyas
11:35
Redfoxmoon left
11:59
lizmat joined
|
|||
| nine | Now that I've ported base64_decode to NQP to get by with minimal changes to the nqp::serialize op, I realized that there's also the serialized_string_heap to deal with. And that can really not be accessed in any way. So it looks like I need to add an op anyway and this op can then return both the data and strings. | 12:11 | |
|
12:19
aLK-[i] joined,
aLK-[i] left
12:23
Teckla16 joined,
Teckla16 left
12:35
zakharyas left
12:39
cjh`15 joined
12:40
cjh`15 left
12:43
ggoebel_ left
12:55
ggoebel left
|
|||
| nine | Oh but there is! The string heap (an nqp::list) is passed to the nqp::serialize op and therefore perfectly accessible :) | 13:34 | |
|
13:59
vlatombe6 joined,
vlatombe6 left,
jesopo0 joined,
jesopo0 left
|
|||
| nine | Aaaand it works :) NQP builds with MoarVM's MAST compiler completely replaced by MoarVM::BytecodeWriter and so does rakudo :) But boy is it slow | 14:01 | |
| timotimo | oh my :) | ||
| nine | Stage mbc : 141.596 | ||
| timotimo | i'm not sure how well --profile-stage works | ||
| whoops :) | |||
| nine | Of course I really took "first make it work, then make it fast" to heart. | 14:02 | |
| timotimo | of course | 14:03 | |
|
14:03
p6bannerbot left
14:04
p6bannerbot joined,
ChanServ sets mode: +o p6bannerbot
|
|||
| Geth | MoarVM/jit-perf-map: 4b0263ec21 | (Bart Wiegmans)++ | 6 files [JIT] Implement a perf map file on linux So that we may profile (on linux) and have insight on the time spent on JIT-compiled frames. Not sure if it will give good results, because we don't always compile with -fno-omit-frame-pointer. |
14:34 | |
|
14:35
patrickb joined
14:36
p6bannerbot sets mode: +v patrickb,
brrt joined
14:37
p6bannerbot sets mode: +v brrt
|
|||
| brrt | nine++ | 14:38 | |
| many amaze | |||
| timotimo | jit perf map!! | 14:43 | |
| brrt: any intent to delete the file? | 14:45 | ||
| when moar shuts down, i mean | |||
| brrt | no, why | ||
| that's what /tmp is for | |||
| timotimo | i guess | ||
| brrt | hmm | 14:46 | |
| maybe you're right though | |||
| I don't really have time for it | |||
| :-) | |||
| timotimo | that's fair | ||
| brrt | well, right now. Feel free to unlink it though | ||
| nine | Only a BEGIN time EVAL issue left. Those are always the most fun | 14:47 | |
| brrt | good luck | 14:49 | |
|
14:49
brrt left
15:11
domidumont left
15:15
buggable left,
buggable joined
15:16
p6bannerbot sets mode: +v buggable
15:18
robertle left
15:25
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
15:37
domidumont joined,
p6bannerbot sets mode: +v domidumont
15:46
patrickb left
16:05
AlexDaniel left
16:09
lpsmith- joined
16:10
lpsmith- left
|
|||
| nine | LOL....if what I see is right, the fix for the BEGIN time EVAL issue also improved performance...dramatically: | 16:15 | |
| Stage mbc : 11.565 | |||
| (was 141.596 before) | |||
|
16:16
patrickb joined
16:17
p6bannerbot sets mode: +v patrickb
|
|||
| diakopter | hunh | 16:20 | |
|
16:20
lizmat left
|
|||
| diakopter | can't wait to see the patch on that | 16:20 | |
| nine | Fix is just taking a MAST::Frame's $!frame_idx if available instead of looking for it in the frame list. Now it finds the frame and also doesn't have to iterate in most cases | 16:22 | |
| Geth | MoarVM/nqp-mbc: 2fd9da1665 | (Stefan Seifert)++ | lib/MAST/Nodes.nqp Store serialized data and strings in MAST::CompUnit |
16:30 | |
| MoarVM/nqp-mbc: 0863feafee | (Stefan Seifert)++ | src/6model/serialization.c Have nqp::serialize always return the serialized data |
|||
|
17:00
izibi9 joined,
izibi9 left
|
|||
| japhb | nine: Wow, that was either a really slow iteration, or it was done a LOT, sheesh | 17:13 | |
| nine: In github.com/MoarVM/MoarVM/commit/0863feafee , you seem to now have an MVM_free(output) on one path and not the other. Also, since you're not returning off either path now, and you're doing the base64_encode on both paths, why have two separate paths? | 17:18 | ||
| nine | japhb: didn't want to duplicate the if condition. Also I still consider this thing to be a POC more than anything else. Especially the changes to MoarVM | 17:28 | |
| japhb | nine: One of my comments was dependent on the other. If the MVM_free was only on one path *intentionally*, then having two paths makes some sense. If the intent was that both paths end with the exact same two lines (base64_encode() followed by MVM_free(output)), then it makes sense to leave them outside the if block as they were originally. In other words, it's not clear why the only diff in that CL is | 17:33 | |
| anything more than removing 'return NULL;' on line 912. | |||
|
17:44
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
17:47
seyeongkim6 joined,
seyeongkim6 left
17:48
sxe20 joined,
sxe20 left
|
|||
| nine | Well in the case where output is assigned to tc->serialized, free()ing it would be counter productive | 17:52 | |
|
17:58
lizmat joined,
p6bannerbot sets mode: +v lizmat
18:04
patrickb left,
patrickz joined
18:05
p6bannerbot sets mode: +v patrickz
18:09
patrickz is now known as patrickb
18:19
patrickb left
18:25
patrickb joined
18:26
p6bannerbot sets mode: +v patrickb
|
|||
| japhb | nine: Fair enough, but that leads me to a new question: Why are you stashing the pre-encoded form in tc->serialized and returning the encoded form from the routine? | 18:30 | |
|
18:30
AlexDaniel left
|
|||
| japhb | Meaning, why do you need both forms? | 18:31 | |
| nine | I don't. tc->serialized is for MoarVM's own MAST compiler while the base64 encoded return value is AFAICT for tests. Neither really suits me. | 18:38 | |
| japhb | Ah! OK, I understand now. Thank you! | 18:47 | |
|
18:48
dantoml joined,
dantoml left
18:57
domidumont left
|
|||
| nine | Looks like there's just no way I can get a profile of that mbc code :/ | 18:57 | |
|
18:59
tarzeau__ joined,
tarzeau__ left
|
|||
| timotimo | nine: even when using nqp::startprofile and nqp::endprofile manually? | 19:17 | |
| and, i suppose, feeding the result into the compiler's method that post-processes the data | 19:18 | ||
|
19:22
plate19 joined,
plate19 left
19:52
ggoebel joined
19:53
p6bannerbot sets mode: +v ggoebel
20:04
matthewwilkes24 joined,
matthewwilkes24 left
|
|||
| nine | Still segfaulting in a broken stack ending in MVM_fixed_size_free called from JIT code | 20:04 | |
| bin ends up 0 in MVMuint32 bin = bin_for(bytes); | 20:06 | ||
|
20:06
kismetg1716 joined,
kismetg1716 left
|
|||
| nine | bytes is 7626968 | 20:06 | |
|
20:29
Ven`` joined,
p6bannerbot sets mode: +v Ven``
20:33
Ven`` left
20:39
dnusbaum16 joined,
dnusbaum16 left
|
|||
| nine | Ok, can't get rid of the segfault but it only happens after the profile got dumped. So it's good enough for me now | 20:40 | |
| Preliminary investigation shows that we spend a lot of time in the methods that write to the byte code array. Which is good. Because those are the ones the new write* ops are supposed to help with :) And bad...because those methods all push which is not good for performance and changing that means changing a lot | 20:41 | ||
|
20:46
ggoebel left
|
|||
| timotimo | tbh i would have assumed that push is a tiny bit faster than bind_pos, as we manage the position in C and as an attribute, rather than in nqp as a register | 20:59 | |
|
21:18
Tsesarevich6 joined,
Tsesarevich6 left
21:22
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke
21:23
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
|
|||
| lizmat | timotimo nine I can concur about push being faster than bindops | 21:40 | |
| *bindpos | |||
|
21:42
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
22:07
avar left
22:08
avar joined,
avar left,
avar joined,
p6bannerbot sets mode: +v avar
22:31
patrickb left
23:06
AlexDaniel left
23:07
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
23:37
avar left
23:38
avar joined,
avar left,
avar joined,
p6bannerbot sets mode: +v avar
23:39
p6bannerbot sets mode: +v avar
|
|||