github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:25 MasterDuke joined, MasterDuke left, MasterDuke joined
MasterDuke .tell timotimo i tried starting profiling, doing the timing, ending profiling (without dumping the data), then restarting profiling, but the resulting profile is still wrong. here's what my patch looks like now, any ideas? gist.github.com/MasterDuke17/2dac1...b58151f8b0 02:35
yoleaux MasterDuke: I'll pass your message to timotimo.
04:02 Kaypie left, Kaypie joined 04:35 chansen_ left 04:39 chansen_ joined 04:44 chansen_ left 04:52 chansen_ joined 05:35 squashable6 left 05:39 squashable6 joined 07:43 MasterDuke left 08:46 patrickb joined 09:24 sena_kun joined 10:30 patrickb left, robertle left
Geth MoarVM: patzim++ created pull request #1109:
Clean up CMP object files on Windows		 10:49
10:52 patrickb joined 10:54 lizmat left 11:02 lizmat joined
Geth MoarVM: 5b5e7f195c | (Patrick Böker)++ | build/setup.pm
Clean up CMP object files on Windows

On Windows the object files for CMP are named differently. Fix `realclean` to also clean up those.		 11:36
MoarVM: c63e7eb7a3 | (Jonathan Worthington)++ (committed using GitHub Web editor) | build/setup.pm
Merge pull request #1109 from patzim/win-cmp-clean

Clean up CMP object files on Windows
MoarVM: a515819b60 | (Jan-Olof Hendig)++ | 3rdparty/libuv
Update libuv to version 1.29.1
 11:39
MoarVM: 241fae182c | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3rdparty/libuv
Merge pull request #1106 from dogbert17/libuv-update

Update libuv to version 1.29.1
MoarVM/master: 4 commits pushed by (Nick Logan)++, (Jonathan Worthington)++ 11:44
jnthn A little Saturday PR merging :) 11:46
dogbert17 jnthn++ 11:47
12:36 domidumont joined 13:00 domidumont left 13:13 Kaypie left, Kaypie joined
patrickb Any reason not to merge #1108 ? (I have seen the windows build failure, but that's because of errors in NQP unrelated to the change in the PR.) 13:15
timotimo M#1108 13:42
yoleaux 02:35Z <MasterDuke> timotimo: i tried starting profiling, doing the timing, ending profiling (without dumping the data), then restarting profiling, but the resulting profile is still wrong. here's what my patch looks like now, any ideas? gist.github.com/MasterDuke17/2dac1...b58151f8b0
synopsebot M#1108 [open]: github.com/MoarVM/MoarVM/pull/1108 Default to doing a non-relocatable build
timotimo o/ 13:47
dogbert17 hello timotimo 13:56
timotimo ohai 13:59
Geth MoarVM: c20f896f14 | (Timo Paulssen)++ | lib/MAST/Nodes.nqp
skip numification in mast nodes code

unbox_i will go directly to int, whereas the code previously generated went via smrt_numify and a coerce.		 14:00
timotimo ^- just a tiny code-gen improvement that i had lying around for a little while 14:02
dogbert17 cool 14:03
timotimo well, not "code-gen" really
just improving some code that ran into poor code-gen
it'll barely be noticeable, of course
dogbert17 perhaps you have some more snippets lying around? 14:04
14:10 patrickb left
timotimo snippets of what kind? 14:10
dogbert17 Moar speed snippets :) 14:13
timotimo ah 14:14
not presently :)
14:35 patrickb joined
dogbert17 timotimo: did you figure anything out wrt the problem of profiling the parse stage? 14:44
timotimo nah, i haven't been on the laptop much the last few days 14:46
it's GPN after all 14:47
dogbert17 GPN?
timotimo: found a oneliner which has the same problem, dunno if it makes things easier though? 14:54
timotimo could be 14:58
dogbert17 m: my @alts = ^256; say "127.0.0.1" ~~ /^ @alts ** 4 % . $/ # here it is 14:59
camelia ｢127.0.0.1｣
dogbert17 stolen from one of lizmat's RT's 15:00
timotimo i wonder if regex has something to do with it, then 15:02
does that crash reliably for you? does it have to be --profile or --profile-compile? 15:05
dogbert17 --profile, and it doesn't 'crash' unless MVM_GC_DEBUG=1
15:06 Kaypie left
timotimo oh of course 15:06
dogbert17 btw, is your headache gone now? 15:10
timotimo yeah :)
dogbert17 yay 15:13
timotimo gotta recompile rakudo 15:14
with gc debug turned to 1
and --optimize=0
oof oof :)
dogbert17 :)
timotimo good i reproduced the crash 15:20
just in time to get up, grab a waffle, and go away
dogbert17 see you later
15:30 squashable6 left 15:32 squashable6 joined 15:50 zakharyas joined
timotimo -> Assertion `t->regs().syscall_result_signed() == -syscall_state.expect_errno' failed to hold. Expected ENOSYS for '<unknown-syscall-332>' but got result 0 (errno SUCCESS); execution of syscall unsupported by rr 16:25
?!?
updating rr fixed it, phe.w 16:31
ugexe so there isnt a way to do sizeof in a macro is there? 16:38
timotimo how do you mean?
ugexe "OK, then we need to #ifdef on that, and re-instate the old thing if it's not 8" re: github.com/MoarVM/MoarVM/commit/2f...07ddab9e62 16:39
timotimo i think it'd be totally possible to literally just put sizeof into an #if
ugexe on a type? 16:40
16:41 squashable6 left
ugexe preprocessor doesn't type names 16:43
parse type names
16:43 squashable6 joined
timotimo d'oh 16:43
oh
doesn't that mean you can use a C-level if? 16:44
and it'll be constant-folded?
ugexe can you explain in the for of a pr? :P 16:46
s/for/form/
my keyboard must have a spec of dust in it
timotimo ha 16:47
is that a commit that fixes the problem? 16:49
or was the problem still present?
ugexe that commit regressed on 32bit and windows
timotimo OK
ugexe thats why there are no green builds of rakudo for the last week or two
16:55 domidumont joined
timotimo so what are the sizeof values we're looking for? 4 and 8? 16:56
17:00 AlexDaniel left 17:02 AlexDaniel joined
Geth MoarVM/multiplatform_mp_set_int: 4aa256ba56 | (Timo Paulssen)++ | src/math/bigintops.c
attempt to have fast mp_set and not broken windows
 17:04
timotimo ugexe: i'm imagining this could perhaps work
i need to make a PR so that CI tries to build it?
Geth MoarVM: timo++ created pull request #1110:
attempt to have fast mp_set and not broken windows		 17:05
ugexe the test failure is in rakudo test, so you wont be able to see that way
timotimo :( 17:06
ugexe i'm building a rakudo on windows to see if it works there
timotimo but then why is the build not green? :P 17:07
ugexe because make test fails for rakudo on appveyor
timotimo oh
oh!
because i made a change in moarvm, not rakudo 17:08
ugexe right
github.com/rakudo/rakudo/pull/2913/files -- this is how you can ad-hoc test a specific moar commit on appveyor (with a rakudo pr) 17:09
timotimo we should have an irc bot for that :) :) 17:10
ugexe turn the old p6c server into a windows server 17:11
timotimo the hardware is already broken, so we won't notice a difference
i'm at the edge of my seat 17:13
which is really saying something, because i'm sitting on the floor
ugexe well its building on a dual core laptop inside a windows vm so dont hold your breath 17:14
hmmm, rakudo is failing the build process on appveyor now 17:21
although it build ok for me using rakudobrew v1 locally
ah nope 17:23
rakudo build is broken on windows 17:24
so i cant test
>perl6 -e "say 1" 17:25
rakudobrew: perl6: command not found
'-e' is not recognized as an internal or external command,
operable program or batch file.
timotimo ouch 17:27
i don't have an opportunity to try otner things very soon, ut perhaps you can revert the individual pieces and just apply the moar patch in isolation 17:50
BBL
18:08 lizmat left 18:12 lizmat joined
ugexe ive tried a couple ways, all trip up on a different build system commit 18:17
the build goes red for 1 commit and suddenly every commit after breaks windows :P 18:19
18:22 patrickb left 18:47 sena_kun left 19:05 domidumont left
timotimo damn :( 20:09
20:20 MasterDuke joined, MasterDuke left, MasterDuke joined
MasterDuke timotimo: did you happen to take a look at my gist? i'm not sure why the first profile isn't being discarded 20:30
timotimo i forgot to ask, but in what way is the profile broken? 20:33
MasterDuke only one entry in routines `<anon> <unknown>:<unknown>1` 20:36
instead of anything about the actual perl6 code i was running 20:37
20:40 zakharyas left
MasterDuke oh, maybe i just needed to add a `tc->prof_data = NULL;` 20:41
timotimo probably 20:45
also, instrumentation_level is not supposed to go down i don't think
but changing the instrumentation isn't a good idea after the first profiler run
MasterDuke that's why i preserve what it was before 20:46
timotimo since it only ever goes up, resetting it to a value it had before would either move it down or stay at the same value 20:48
MasterDuke oh, you mean i shouldn't touch it at all?
timotimo yeah 20:49
for $reasons we currently don't have a "remove instrumentation" thing
MasterDuke or should i increment it like MVM_profile_instrumented_end does? 20:50
timotimo just leave it be for now
there can only be tears and sadness
MasterDuke ha 20:51
what's it for?
timotimo the thing is, whenever a routine gets invoked, there is a "instrumentation level barrier" 20:52
if the instrumentation level of the routine is the same as the one in the interpreter, nothing happens
if it's lower in the routine, it will go through instrumentation
the issue is with multithreading 20:53
if the instrumentation level changes in the interpreter, every routine that gets entered will go through an instrumentation again 20:54
however
some routines may already have been entered in another thread
so the other thread is happily executing the code, while a different thread enters the same routine
the different thread changes the bytecode via instrumentation 20:55
MasterDuke ah, sounds like something i don't want to have to worry about
timotimo and suddenly the other thread has an instruction pointer tha tpoints who-knows-where; often in the middle of an instruction
yes :)
thing is, changing the size of the bytecode means that the instruction pointers in all other threads would have to be properly moved to the right spot
which is a form of on-stack replacement, i suppose 20:56
luckily for us, the profiler instrumentation isn't harmful when it's still in place when profiling isn't running 20:58
though i think i only recently put checks in for whether the profiling is actually active before doing data gathering and such 20:59
which was an odd thing to forget to put in
MasterDuke whoops 21:01
do you think the overheard of MVM_profile_log_enter with MVM_PROFILE_ENTER_NORMAL would be about the same as with the other options? 21:02
timotimo i think so 21:03
MasterDuke ok, so i calculated the overhead and stuck it in a new field in tc->intance. now, what's the best thing to do with it? 21:05
ugexe it looks like windows build might be fixed but the PRs in rakudo/nqp/moar have to be merged together 21:06
MasterDuke subtract it when measuring? subtract it when dumping? include it in the the info returned by nqp::mvmendprofile so downstream can decide what to do with it? 21:07
timotimo subtract when dumping i'd say
if you subtract while measuring, you'll also be measuring the time it takes to subtract, how ever little it may be
21:09 squashable6 left
MasterDuke hm, MVM_gc_enter_from_allocator actually dumps the data? wouldn't have expected that 21:13
21:14 squashable6 joined
timotimo it's a slightly hacky way to get thread synchronization "for free" 21:23
including "when another thread wakes up during that time, it won't just start running"
MasterDuke ugh, working through the fog of a cold, can't figure out what/where to change 21:36
21:51 squashable6 left 21:54 squashable6 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!