|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:40
THE_GFR|H joined
00:41
THE_GFR|H left
01:08
asdfman1 joined,
asdfman1 left
01:27
leont left
02:33
lizmat left
03:25
dcastellani7 joined,
dcastellani7 left
05:10
tjbp8 joined,
tjbp8 left
05:15
clarkk joined,
clarkk left
06:15
domidumont joined,
p6bannerbot sets mode: +v domidumont
06:21
d10n11 joined,
d10n11 left
06:43
fake_space_whale left
07:00
lizmat joined,
p6bannerbot sets mode: +v lizmat
07:12
qlaro5 joined,
qlaro5 left
07:36
jurov8 joined,
jurov8 left
07:48
kaizen2_ joined,
kaizen2_ left
08:15
Ven`` joined
08:16
p6bannerbot sets mode: +v Ven``
08:56
larma16 joined,
larma16 left
09:03
lizmat left
|
|||
| nine | To get allocations really down and maybe reap the first speedup, I'll have to get rid of the MAST nodes for operands, not just ops. Now that's gonna be interesting. | 09:13 | |
| What makes this whole thing difficult is really the inversion of control flow. When building the MAST, we start at the leaf nodes and build our way up. To get rid of those objects and assemble bytecode directly, I'll have to start assembling on the way down and end when I hit a leaf. | 09:14 | ||
|
09:19
domidumont left
09:23
lizmat joined,
p6bannerbot sets mode: +v lizmat
|
|||
| nine | Now that I'm reading the code, I'm not sure why we wrap those values in MAST::XVal nodes in the first place. | 09:33 | |
| You might say "ah, that's because e.g. a MAST::IVal also contains information about its size and signedness" and that's true. But we don't use this information anywhere. | |||
| And indeed it was rather easy to get rid of them. It also didn't change anything in terms of performance. But I guess there's just not _that_ many literals in the code. | 09:56 | ||
|
10:00
Kinroy29 joined,
Kinroy29 left
11:13
Guest63579 joined,
Guest63579 left
11:19
leont joined
11:20
p6bannerbot sets mode: +v leont
|
|||
| nine | Wow....this was a whole new level of confusing error message. | 11:30 | |
| I got a "MAST::Local of wrong type specified" error when trying to get rid of the MAST::Local objects in the MAST. the error came after a change to a line just 5 lines above the place where the error was thrown. | 11:31 | ||
| Now you'd probably think like me that when doing something related to MAST::Locals, such an error indicates that there's some side effect of the change and the resulting MAST is just invalid. | 11:32 | ||
| Turns out: the error message has absolutely nothing to do with my changes to MAST::Local handling and were really just a type issue in the line I modified: my uint16 $index := $arg; | 11:33 | ||
| timotimo | ouch | ||
| nine | What's the chance of that? | ||
| timotimo | yeah | ||
| when the compiler is involved in compiling itself, that kind of fun can happen | 11:34 | ||
| nine | I've struggled with int types during the whole process of writing the bytecode writer and this is the first time I've got that exact error | ||
| Btw. getting rid of MAST::Local is not as easy as with the literal types since they are specifically checked for ins some places, e.g. to release the register. | 11:52 | ||
| Also I wonder how much this would really save. It's an object with a single int attribute. That's exactly what boxing will do with those ints anyway | 11:53 | ||
| timotimo | so its main "purpose" is to have its identity? | 11:54 | |
| nine | yes | ||
| timotimo | if you want you can "is box_target" the attribute and it'll be exactly a box :) | ||
| not sure if that helps at all | 11:55 | ||
| or is more comfortable | |||
| is it feasible to actually re-use the MAST::Local objects? like from a pool? | 11:57 | ||
| nine | I don't see why not | 11:59 | |
| timotimo | that hopefully cuts down on allocations drastically and make this point moot? | 12:00 | |
| alternatively, have a single array (per frame?) that stores the register types for all registers | |||
| that'll cut memory usage by like 5x for that exact piece of data | |||
| nine | Actually that's already done | 12:01 | |
| timotimo | oh, OK | ||
| nine | The re-use of MAST::Locals | ||
| Btw. I'm back to not being able to profile. Or rather I can get a profile of the mast stage. But it's useless, since in 28s runtime it records just 5 call frames totalling about 0.01s | 12:03 | ||
| timotimo | interesting. is this with the html/json output or the sql output? | 12:04 | |
| nine | html | 12:05 | |
| timotimo | does it use more than one thread? | ||
| nine | No. Code is: gist.github.com/niner/938c307ba831...83dedb4ce3 | ||
| timotimo | correction: is any other thread active at the time, including the async i/o thread? | 12:06 | |
| nine | How can I find out? | ||
| timotimo | hm. run it under gdb and see if it prints something about threads being started? | 12:07 | |
| alternatively | |||
| get an sql profiler output and count the number of INSERTs into the "profiles" table | |||
| if you got the sql output, why not directly put it into the new profiler tool :) | 12:09 | ||
| nine | Where can I get that? | 12:12 | |
|
12:14
Ven`` left
|
|||
| timotimo | github.com/timo/moarperf | 12:15 | |
| i'll look into more one-click distribution methods, too. like docker images or appimages or whatever | 12:16 | ||
| nine | Same lack of data | 12:19 | |
|
12:21
Ven`` joined
12:22
p6bannerbot sets mode: +v Ven``
12:27
Ven`` left
|
|||
| timotimo | OK, that's definitely curious | 12:33 | |
| can you help me get that repro'd? | 12:34 | ||
| it's actually possible that you have to have the sub that does mvmstartprofile and mvmendprofile call your actual code | |||
| rather than having them in there | |||
|
12:35
Ven`` joined,
p6bannerbot sets mode: +v Ven``
|
|||
| nine | Nah, moving out the code in between didn't change anything | 12:54 | |
| timotimo | dang. | 12:55 | |
| nine | timotimo: niner.name/files/rakudo.tar.xz to repro the issue extract that as /home/nine/rakudo and then run PROFILEMBC=1 gdb --args /home/nine/rakudo/install/bin/moar --libpath="blib" --libpath="/home/nine/rakudo/install/share/nqp/lib" --libpath="/home/nine/rakudo/install/share/nqp/lib" perl6.moarvm --nqp-lib=blib --setting=NULL --ll-exception --optimize=3 --target=mbc --stagestats | 13:09 | |
| --output=CORE.setting.moarvm gen/moar/CORE.setting | |||
| in ~ 5 minutes, when the upload is actually complete | |||
|
13:12
abbe21 joined,
abbe21 left
|
|||
| nine | now | 13:14 | |
| mst | heh | 13:24 | |
|
13:32
atluxity21 joined,
atluxity21 left
13:36
Ven`` left
13:46
K0HAX27 joined,
K0HAX27 left
13:50
domidumont joined,
p6bannerbot sets mode: +v domidumont
13:57
aimileus joined,
aimileus left
14:08
Ven`` joined
14:09
p6bannerbot sets mode: +v Ven``
|
|||
| timotimo | i was having an eat | 14:19 | |
| nine too | 14:30 | ||
| timotimo | looks like the HLL Backend currently calls a sub that does startprofile | 14:35 | |
| so maybe the profiler relies on "starting the profile" only after a return has happened | 14:36 | ||
| at least the call graph portion of it | |||
| i'm testing it wtih a corresponding change now | |||
| that didn't help, hum. | 14:41 | ||
| i was looking forward to using DDD to more comfortably browse through structs and such | 15:10 | ||
| ... i can't write "break", it only comes out as "brk" | |||
| geekosaur | someone's trapped in the seventies? | 15:17 | |
| timotimo | what other programs can gdb and let me graphically or at least interactively (not by typing ever-longer print commands) navigate structs and memory? :\ | 15:19 | |
| geekosaur | sourceware.org/gdb/wiki/GDB%20Front%20Ends notably github.com/cs01/gdbgui | 15:21 | |
| but I didn't so much mean ddd as "brk" there | 15:22 | ||
| (ancient unix's lowest level process memory management, from a simpler time) | |||
| timotimo | ah | 15:24 | |
| i tried gdbgui before | |||
| it was hard to use together with rr | |||
| too many ways to make it freeze up | 15:25 | ||
|
15:35
rawles29 joined,
rawles29 left
15:47
vodkaInf1rno7 joined,
vodkaInf1rno7 left
16:03
fake_space_whale joined,
p6bannerbot sets mode: +v fake_space_whale
16:17
Ven`` left
16:22
Ven`` joined
16:23
p6bannerbot sets mode: +v Ven``
16:40
robertle joined
16:41
p6bannerbot sets mode: +v robertle
16:43
Ven`` left
17:13
rsroka17 joined
17:14
rsroka17 left
17:19
fake_space_whale left
17:26
MasterDuke joined,
p6bannerbot sets mode: +v MasterDuke,
MasterDuke left,
MasterDuke joined,
herbert.freenode.net sets mode: +v MasterDuke,
p6bannerbot sets mode: +v MasterDuke
17:31
fake_space_whale joined
17:32
p6bannerbot sets mode: +v fake_space_whale
17:38
Guest24755 joined,
Guest24755 left
|
|||
| MasterDuke | hm, github.com/MoarVM/MoarVM/pull/949 has gotten a little confused with the merging/branching that's gone on | 17:45 | |
|
18:06
AlexDaniel left
18:07
AlexDaniel joined,
p6bannerbot sets mode: +v AlexDaniel
19:07
domidumont left
19:10
ovf0 joined,
ovf0 left
19:20
MasterDuke left
19:52
robertle left
20:19
bga5720 joined,
bga5720 left
20:40
releasable6 left,
reportable6 left,
releasable6 joined,
reportable6 joined
20:41
p6bannerbot sets mode: +v releasable6,
p6bannerbot sets mode: +v reportable6
20:42
fake_space_whale left
20:43
fake_space_whale joined,
p6bannerbot sets mode: +v fake_space_whale
21:27
avar left,
avar joined,
avar left,
avar joined,
p6bannerbot sets mode: +v avar
21:28
p6bannerbot sets mode: +v avar
22:48
graywh18 joined,
graywh18 left
23:10
blabber0 joined,
blabber0 left
|
|||