|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
06:12
domidumont joined
06:49
robertle joined
07:10
patrickb joined
08:19
zakharyas joined
09:56
domidumont left
11:21
Guest55475 left
11:34
zakharyas left
12:00
domidumont joined
12:39
lucasb joined
13:04
zakharyas joined
13:23
domidumont1 joined
13:25
domidumont left,
domidumont joined
13:28
domidumont1 left
14:03
domidumont1 joined
14:07
domidumont left
14:22
domidumont joined
14:26
domidumont1 left
15:02
domidumont1 joined
15:04
domidumont left
15:09
domidumont1 left
15:24
patrickb left
15:38
zakharyas left
15:42
robertle left
16:44
robertle joined
|
|||
| tbrowder | samcv: tbrowder on github is also tbrowder | 16:51 | |
| samcv | :) adding you now | 17:29 | |
| oh nice you have have team discussions on github | 17:30 | ||
|
17:32
domidumont joined,
patrickb joined
17:38
domidumont left,
domidumont joined
|
|||
| samcv | tbrowder, sent | 17:59 | |
|
18:04
domidumont1 joined
18:06
domidumont left
|
|||
| timotimo | nine: how does this moarvm bytecode look to you? 07 00 63 00 01 00 00 00 08 00 05 00 63 00 ef 01 05 00 | 18:09 | |
|
18:36
brrt joined
|
|||
| brrt | \o | 18:45 | |
|
18:49
sena_kun joined
|
|||
| timotimo | nine: i'm now also a consumer of your %MAST::Ops::generators :) | 18:56 | |
| nine | timotimo: it does look kinda incomplete ;) | 19:04 | |
| But nice to see that my work provides some value :) | |||
|
19:06
domidumont1 left
|
|||
| timotimo | yeah, it's for a much simplified language that also has its own simplified interpreter inside moarvm itself | 19:09 | |
| it bends a rule or two | |||
| much easier to read the bytecode when you write it as 16 bit integers, hex and decimal in two lines | 19:12 | ||
| nine | Between moar --dump and gist.github.com/niner/c24f4c2f8ae0...03669d6423 you hopefully don't need to read too much bytecode through hexdumps | 19:13 | |
| timotimo | i'm looking for one very particular hack right now ... i want an op that looks like bindattr_o, but takes the type as a string instead of a register :D | ||
| oh, yes! that thing! <3 | 19:14 | ||
| oh, the only thing i have at the moment is the bytecode, nothing in the way of headers | |||
| which is also why moar --dump don't work :) | |||
| sorry, did i say bindattr | 19:15 | ||
| i meant getattr_o | |||
| i'm vaguely considering doing a getattr_o on A Very Special Register that the verifier spots and converts | 19:16 | ||
| it'll turn the getattr_o into noops and makes the next getattr_o the right "variant" | |||
| actually, const_s into a A Very Special Register could be more than enough | |||
| nine | What's the goal of this thing? | ||
| timotimo | why, world domination of course! | 19:17 | |
| it'll allow throwing bytecode at spesh, the jit, and the profiler | |||
| nine | ooooh | ||
| timotimo | you'll be able to tell the profiler to "only start profiling starting on static frames named 'poodle'" | ||
| nothing specific figured out for spesh and jit yet, but you could totally turn on or off specific optimizations in spesh or prevent exprjit on just one BB inside of a specific frame | 19:18 | ||
| lizmat | ++timotimo | ||
| timotimo | and with proper care, it could allow a very simple subset of breakpoint conditions | 19:19 | |
| but i'm stealing getattr now for Very Special Crap, will have to see how that'll cooperate :) | |||
| the very first thing it'll do is let you log when the program runs. which is why at the moment it can compile programs `log = "hello"` and `log = ~(99)` | 19:20 | ||
| brrt | :-O timotimo++ | ||
| timotimo | a blog post will follow shortly, as my last progress report for my grant was at the end of march | 19:21 | |
| this is related to the grant, at least. | |||
| in the mean time, please throw potential use cases/scenarios at me :) | 19:22 | ||
| lizmat | being able to more closely profile the supervisor thread ? | 19:36 | |
| and only that? | |||
| timotimo | that'd be one example that'd work with the current design ideas already | 19:47 | |
| lizmat | cool | ||
|
20:13
brrt left
|
|||
| timotimo | pushed configurable-subsystems as a branch (so that even if my computer dies over night, the code is safe) | 20:16 | |
| MasterDuke | nine: around? | 21:25 | |
| timotimo: what woud be the effect right now of calling MVM_profile_log_enter() and MVM_profile_log_exit() repeatedly, say at either the beginning or end of the program? is there currently a way to ignore some calls? | 21:33 | ||
| timotimo | MasterDuke: i'm not sure if it cleans up the recorded data properly when doing proile_log_exit, or if the code just relies upon only being run once in total | 21:37 | |
| but you can call enter and exit whenever you like and use the return value of profile_exit; it can be read by the compiler backend's dump profile data method | 21:38 | ||
| MasterDuke | timotimo: hm, i'm just thinking of how to measure the overhead so it can be subtracted out in the report | 21:42 | |
| timotimo | ah | 21:43 | |
| we can "just"™ have a function measure_overhead that gets run a few hundred thousand times and does nothing | 21:44 | ||
| and check it by name in the profiler | |||
| "the simplest thing that can possibly work" and such | 21:45 | ||
| not that i'm good at doing that | |||
| looking at my solution to "only some functions should trigger profiling" | |||
| MasterDuke | well, *_(enter|exit) do actual work, we'd want to try to replicate that cost if possible | 21:48 | |
| timotimo | prof_exit doesn't include the time spent inside of it in the profile results | 21:50 | |
| oh | 21:51 | ||
| *oh* | |||
| sorry, my dumb brain was thinking of profile_start and profile_finish | |||
| okay, so, the effect of calling profile_log_enter and profile_log_exit over and over would probably allocate a profiler data node at the root of the call graph of the current thread and give that a bunch of entries and some time | 21:57 | ||
| if it's the very first thing that happens (i.e. other threads don't race us) it'd probably even get the node id 0 | 21:58 | ||
| MasterDuke | do it right when the command line option is handled? | 22:05 | |
| or would it be better to do it right before calling profile_finish? | 22:06 | ||
| timotimo | i'd probably say at the start is better | 22:08 | |
| are you thinking of putting it in moarvm as C code or nqp as nqp code? | |||
|
22:41
patrickb left
|
|||
| MasterDuke | i was thnking c | 23:13 | |
| but i don't have a completely reasoned out why | 23:14 | ||
| so at the end of MVM_profile_start, if we're doing instrumented profiling, do 1k calls to MVM_profile_log_enter() and MVM_profile_log_exit() ? | 23:18 | ||
|
23:25
sena_kun left
|
|||
| MasterDuke | timotimo: hm, not seeing anything in a profile | 23:30 | |
| timotimo | i'm not sure what you'd pass to the functions when calling it yourself | 23:39 | |
| MasterDuke | MVM_profile_log_enter(tc, tc->cur_frame->static_info, MVM_PROFILE_ENTER_NORMAL); | 23:43 | |
| cribbed from prof_enter in interp.c | 23:44 | ||
| timotimo | i'm not actually entirely sure that's kosher | 23:48 | |
| that's now the frame that started the profiler, which is not normally in the call graph | 23:49 | ||
| i don't know what effect it actually has | |||
| MasterDuke | hm, got a better idea? | ||
| timotimo | maybe instead of passing the data via the regular call graph, we should get the time before and after calling the function a lot and return that as part of the result dataset | 23:52 | |
| which might be what you wanted to do from the start? | |||
| i seem to be in dire need of a sleep :D | |||
| MasterDuke | sure, if there's a way to call it that doesn't create entries | ||
| timotimo | ENTER_FAKE :D | 23:54 | |
| that doesn't do the same amount of work of course :( | 23:55 | ||