| samcv | exciting. i think i'll have to rewrite a lot of this but should hopefully take what i learned. for the first time got moarvm pulling collation values from the new data set | 01:57 | |
| tested only single codeponits though. i need to see the best way to deal with the codepoint iterator and *peek* at the next codepoint without messing with the iterator or something | |||
| ack :9 | 02:08 | ||
| err :( | |||
| oh i think i just need to use a codepoint iterator not a grapheme iterator. not sure why i was doing this in the first place | 02:12 | ||
| Geth | MoarVM/collation-arrays: 25 commits pushed by (Timo Paulssen)++, (Jonathan Worthington)++, (Samantha McVey)++ review: github.com/MoarVM/MoarVM/compare/2...23b5d9ea98 |
04:14 | |
|
06:23
brrt joined
|
|||
| brrt | ohai, i can haz a new finding | 06:24 | |
| i now believe we're dealing with an overflow in dynamic labels | |||
| why? becuase the disastrous byte sequence is: 75 80, which is interprteed as jne -0x80, and the correct sequence is 75 67, whic is interpreted as jne +0x67 | 06:25 | ||
| which means that dynasm is failing to convert it to a wider label for $some-reason | 06:26 | ||
|
06:49
domidumont joined
06:51
brrt joined
06:54
domidumont joined
|
|||
| brrt | jnthn++ nice post | 07:31 | |
|
07:47
zakharyas joined,
domidumont joined
|
|||
| brrt | (the question is of course, what is the reason!) | 08:16 | |
| samcv | :( | 08:18 | |
| sounds frustrating | 08:19 | ||
| brrt | well, yes... | ||
| all in a days work :-) | |||
|
08:26
robertle joined
|
|||
| samcv | :-) | 08:35 | |
| \o/ yay. it's pushing it onto the stack in MVM :) feels good | 08:40 | ||
| getting closer | |||
| feels nice putting the code i've been working on and actually having it work inside mvm properly :) | |||
| jnthn | morning o/ | 08:41 | |
| brrt++ samcv++ :) | |||
| samcv | morning o/ | ||
| brrt | moarning jnthn, samcv | 08:48 | |
| nwc10 | good *, * | 08:54 | |
| brrt | ohai nwc10 | 08:55 | |
| samcv | ugh somewhere my array gets cleared. now gonna have to add in a whole ton of prints | 09:00 | |
| well gonna have to add a char * argument to all the functions so i can tell *which* stick is actually printing. otherwise it doesn't help me that much and is a bit confusing | 09:01 | ||
| jnthn | If something is getting cleared unexpectedly, you might find data breakpoints useful | 09:25 | |
|
10:55
brrt joined
|
|||
| timotimo | and rr so you can go forwards *and* backwards while data breakpoints are active | 11:01 | |
| one of the problems i was chasing was something was not getting set, so it kept the null value that was set at the beginnig of the frame and not updating it ... | 11:03 | ||
| jnthn | Funnily enough, I'm chasing down how a NULL gets passed as an arg at the moment | 11:04 | |
| timotimo | that's me! | 11:05 | |
| well, only while profiling | |||
| jnthn | This one is in t/qast/01-qast.nqp | ||
| I actually stumbled upon it by accident while doing spesh logging stuff | |||
| But figured I should try and work out what's going on, rather than just toss in a null check that shouldn't be needed | |||
| timotimo | yup | 11:06 | |
| github.com/timo/SDL2_raw-p6/blob/m...aw.pm#L427 - mine dies somewhere in here | |||
| trying to call .defined on a null | 11:07 | ||
|
11:09
zakharyas joined
|
|||
| jnthn | odd | 11:14 | |
| lunch, bbs | |||
|
11:37
MasterDuke joined
|
|||
| MasterDuke | timotimo: don't know if this helps, but here i have a backtrace and valgrind output for a segv when profiling: gist.github.com/MasterDuke17/d8872...54682092fd | 11:38 | |
| timotimo | MasterDuke: nothing unusual about the valgrind output | 11:39 | |
| MasterDuke | ah well, hopefully you'll figure it out | 11:43 | |
| timotimo | the segv is most probably because that program had threads and profiling just always explodes once another thread exists | 11:44 | |
| and the valgrind messages are from the mast compiler that allegedly writes uninitialized bytes to the file, and the FSA being torn down uncleanly at process termination with --full-cleanup | |||
| MasterDuke | that was profile-compiling DrForr's test file, didn't notice that it had threads | 11:46 | |
| timotimo | i think it precompiled some other modules and that uses Proc which now uses Proc:dAsync | ||
| MasterDuke | hm, so no way to profile precomp? | 11:48 | |
| timotimo | not until i finally fix whatever problem underlies the profiler blowing up in multithreaded situations | 11:49 | |
| MasterDuke | so we should be good to go by afternoon? ;) | 11:51 | |
| jnthn back | 11:52 | ||
| timotimo | huh. now i'm profiling some multithreaded snippets and they're not segfaulting | 11:56 | |
| jnthn | duh, found the NULL | 11:57 | |
| Geth | MoarVM/spesh-worker: 4bb2893d33 | (Jonathan Worthington)++ | 2 files For Scalar parameters record content type also. |
11:58 | |
| MoarVM/spesh-worker: 1e07e26921 | (Jonathan Worthington)++ | src/core/frame.c Never pass a real NULL as an object arg. Use VMNull instead. |
|||
| MasterDuke | jnthn: nice post. "Bool (form passed path)", and "case the the parameter" | 11:59 | |
| jnthn | MasterDuke: Thanks, fixed | 12:04 | |
| Geth | MoarVM/spesh-worker: f8c587d8f4 | (Jonathan Worthington)++ | src/spesh/log.c Missing rooting; do less work if not logging. |
12:05 | |
| MoarVM/spesh-worker: 5bbe95a747 | (Jonathan Worthington)++ | 2 files Remove "warm enough to log" concept. This would mean we never collected OSR points in the main body of a program, which would be a serious missed opportunity. |
12:13 | ||
| timotimo | i wonder if i take out the code that puts null ops into the beginning of frames i'd get better watchpoint information out of my code | ||
| Geth | MoarVM/spesh-worker: 24267c0d58 | (Jonathan Worthington)++ | src/6model/reprs/MVMSpeshLog.c Correct marking for decont param record. |
12:44 | |
| MoarVM/spesh-worker: 0484ba0cb5 | (Jonathan Worthington)++ | 7 files Start sketching out spesh stats data structure. This is where it will assemble per-static-frame summaries of what it disocvered from the logs. |
13:05 | ||
| MoarVM/spesh-worker: 092db5f614 | (Jonathan Worthington)++ | 6 files Implement MVM_SPESH_BLOCKING. Makes a thread that sends logs to the spesh worker thread wait until it has completed the specialization work. This will allow for easier debugging. |
13:37 | ||
| timotimo | i think the FSA explodes during teardown because our extra threads don't know when the vm tears down | 13:52 | |
| so they can't properly partake in teardown and so we use stuff that's already been freed or rather the main thread frees stuff that the other threads still want to use | |||
|
13:59
dogbert17 joined
|
|||
| MasterDuke | can they be notified? | 14:00 | |
| timotimo | in theory the mechanism that coordinates threads into doing gc could be taught about that | 14:04 | |
| MasterDuke | the same mechanism that could be adapted to handle multi-threaded profiling? | 14:05 | |
| timotimo | yep | 14:10 | |
| MasterDuke | is it currently very tied to coordinating gc? or is it more of a generic message-passing mechanism? | 14:27 | |
| timotimo | well, we don't want to give our threads other stuff to always be checking on top of GC coordination | 14:29 | |
| that makes it a natural choice, imo | |||
| jnthn | It's a mechanism that could be generalized somewhat | 14:31 | |
| Though with great care | |||
| timotimo | the rr irc channel is really quiet | 14:32 | |
| Geth | MoarVM/spesh-worker: eac57a4caf | (Jonathan Worthington)++ | 6 files Record total hit counts frames; dump them. |
15:11 | |
| timotimo | i wonder if this crash happens because fully_deserialized == 0 in the static frame, heh. | 15:12 | |
| (crash while trying to dump the bytecode, that is) | |||
|
15:13
brrt joined
|
|||
| jnthn | Possibly | 15:18 | |
| I mean, that means we didn't bother reading in a bunch of info | |||
| Info which dumping would likely need | |||
| Geth | MoarVM/spesh-worker: 4eb61cab0b | (Jonathan Worthington)++ | 2 files Aggregate hit counts by callsite. |
15:39 | |
| timotimo | anyway, putting a call to finish up deserialization makes things work better | 15:47 | |
|
15:47
TimToady joined
|
|||
| timotimo | oooooh this is some *bad* bytecode %) | 15:49 | |
| getexcategory + box_i + smrt_numify + coerce_ni | 15:50 | ||
| but i think this is pre-speshed | |||
| er, well, when i dump the data of the *staticframe*, i'm not gonna get speshed code %) | 15:51 | ||
| jnthn | Alright, figured out the next bit of the stats building but will leave that for tomorrow :) | 16:00 | |
| Plan is stats model, then refactor how we do guards, then make the planner (deciding what specializations to produce) | 16:01 | ||
| And then it'll be the big step of migrating to really having specializations done by the specialization worker | |||
| brrt | so…. what is more, at the time the code is 'linked', dynasm doesn't yet know that the block can still be increased | ||
| *block size | 16:02 | ||
| jnthn figures that's enough for now :) | 16:10 | ||
|
16:27
ilmari[m] joined
16:31
robertle joined
18:56
FROGGS joined
19:00
domidumont joined
|
|||
| Geth | MoarVM/even-moar-jit: 09f421cc78 | (Bart Wiegmans)++ | 3rdparty/dynasm Update dynasm to get OPTREX fix Some instructions only optionally need a REX byte. In this case, the size of the generated code varies with the selected register, which is known at link time. Previously we fixed that by increasing the size if we found a REX byte was necessary. However, this interacts badly with label offset calculation - specifically, we would allocate a single byte for a relative label, which would then overflow if the code grew due to addition of REX bytes. So instead, we now always assume that the space is required, and decrease the offset if it turns out that it isn't. |
20:49 | |
| MoarVM/even-moar-jit: e3c4fa9b00 | (Bart Wiegmans)++ | src/jit/core.expr Add sp_fastcreate expr template This one uncovered so many bugs: * in expr tree generation * in point-spilling * in spill-GC interaction * in dynamic register code generation Fixing them was worthwile. |
|||
|
21:13
TimToady joined
|
|||
| timotimo | did you contribute the optrex fix to upstream dynasm? | 21:23 | |
| or is that something only moar users get the benefits of? | 21:24 | ||
| .o( come to moarvm, we have the correctest dynasm implementation on the market today! ) | |||
| also: hell yeah! even moar jit \o/ | 21:26 | ||
|
21:46
geekosaur joined
|
|||
| samcv | jnthn++ on blog post | 21:55 | |
| lizmat | and another Perl 6 Weekly hits the net: p6weekly.wordpress.com/2017/07/03/...-on-speed/ | 22:09 | |
| jnthn | ah, nice, some bedtime reading :) | 22:16 | |
| timotimo | great! | 22:25 | |
| timotimo reads | |||
| jnthn | lizmat++ # another nice weekly :) | 22:31 | |
| timotimo | i made the mistake to click through to those reddit comments | 22:35 | |
| jnthn | The post was bad enough :P | 22:37 | |
| timotimo | could have been worse | 22:39 | |
| Zoffix | :) | ||
| timotimo | i only now understand that samcv is going to do the talk about unicode in amsterdam. is an intercontinental flight involved there? | ||
| samcv | yep | 22:40 | |
| timotimo | i do not envy you! | ||
| also, last time i looked, those were absurdly expensive :< | |||
| samcv | got a roundtrip for 840 dollars | ||
| most of those ones you had to have a overnight layover in iceland but found one without it | 22:41 | ||
| jnthn | Iceland is cool! | ||
| timotimo | that's a little less than i would have expected | ||
| jnthn | Not a cheap place for an overnight layover, though, I suspect | 22:42 | |
| samcv | i paid 1800 dollars roundtrip to manchester years ago. so this is much cheaper | ||
| though that was during chrismas time so more money prolly | |||
| jnthn | Yeah, season certainly affects it | ||
| Though airline pricing can be utterly bizzare. | 22:43 | ||
| The most annoying one being a ticket for place A to place C with a connection in place B being way cheaper than buying just the flight from B to C. o.O | 22:44 | ||
| Glad you found a good deal, anyway | |||
| timotimo | yay | ||
| jnthn | Time to rest, methinks. Want to get some more spesh stats progress in tomorrow. | 22:51 | |
|
22:54
AlexDani` joined
|
|||
| samcv | lldb is not a bad debugger | 23:10 | |
| timotimo | how's it scripting support? | 23:21 | |
| samcv | not sure | ||
| it prints out variables on the stack pretty great | 23:22 | ||
| timotimo | time-travelling debugger support? :) :) | ||
| samcv | timotimo, gist.github.com/samcv/ba9322985151...1440b87ad1 does gdb print out variables this nicely? | 23:23 | |
| like complicated ones? | 23:24 | ||
| timotimo | not by itself, but i have a gdb thingie installed that makes things a lot nicer | ||
| imgur.com/J5giaPi | 23:26 | ||