Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-08-16

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:27 timotimo my brain isn't letting me sleep ... once again
02:27 timotimo this dumb idea is milling about in my head:
02:28 timotimo when we're doing a gen2 collection, we don't actually have to push pointers to pointers into the worklist - if we had two worklists, one of pointers that need updating (because they point to things that can move) and one of pointers that just need visiting (because they're in the gen2 and we're doing a full collection)
02:28 timotimo since a check for "is it in the nursery" can be very cheap, because that's just one memory region ... oh, here's where i'm wrong already :)
02:28 timotimo because multiple threads
02:29 timotimo but let me finish my thought anyway
02:30 timotimo if we decide early on whether something should go into the nursery or gen2 worklist, we could always check the last few pointers in there (align and size to fit cache lines) for duplicates, i.e. "did i recently consider visiting this object for the future?" and perhaps that could take a bunch of load off of the process_worklist sub
02:30 timotimo hopefully now that i've gotten this idea out of my system my brain will be satisfied and let me get some rest ~_~
05:28 brrt joined #moarvm
05:31 brrt good * #moarvm
07:08 zakharyas joined #moarvm
07:57 domidumont joined #moarvm
08:01 domidumont joined #moarvm
08:51 kjs_ joined #moarvm
09:50 kjs_ joined #moarvm
09:50 domidumont joined #moarvm
10:52 timotimo to clarify, i was expecting you'd see the same bunch of type objects and stables a bunch of times in a row, for example if you have a big and long-lived array, and having the little deduplicating cache could ease memory traffic
12:10 domidumont joined #moarvm
14:05 * [Coke] notes to timotimo that Coke works for an internet of things company!
14:06 [Coke] (of course, I'm no where near that code :)
14:06 jnthn Is it the one that makes the reminders toaster? :)
14:08 [Coke] jnthn: no, the jet engines.
14:09 jnthn That's more cool, but I'm not sure I want one of those in my apartment... :)
14:10 nine I'd totally want a jet engine :)
14:11 jnthn Don't you fly jets? :)
14:11 unmatched} An internet connected jet engine? ... and I thought the blue tooth pee stick was insane....
14:12 jnthn Modern planes are chock full of stuff that report ways they're currently breaking/failing back to maint, I thought?
14:12 nine jnthn: no. Though there are sail planes with jet engines :) http://www.wired.com/2010/08/sailplane-launches-itself-with-retractable-jet-engine/
14:14 jnthn Ah, sail planes :)
15:52 kjs_ joined #moarvm
15:59 [Coke] unmatched}: I can't speak to any of the details of $dayjob's IOT, but it's mainly "collect lots of data so you can profile equipment and discover information about it", like "if you do the maintenance at your next window, you'll save money instead of waiting until next thursday".
16:00 [Coke] I... work on the taxes; nothing exciting like IOT stuff.
16:02 nwc10 so you're on the only guaranunteed "product" line in the entire company? :-/
16:02 nwc10 (although the profit centres do need to keep existing to pay for the cost centres)
16:02 kjs_ joined #moarvm
16:03 [Coke] nwc10: it's… complicated.
16:03 [Coke] I will be happy to explain it over beers or equivalents
16:04 nwc10 OK. I was rather hoping that it wasn't complicated. Or at least, that it wasn't stressfully complicated.
16:04 nwc10 ie not "may you live in interesting times"
16:05 nwc10 will happy share beers if our paths cross in the right place
16:09 zakharyas joined #moarvm
16:13 brrt joined #moarvm
16:17 [Coke] Closest I get for a while is probably dublin/leeds next month.
16:18 brrt joined #moarvm
16:25 brrt one of the simpler things to do
16:25 timotimo oh?
16:25 nwc10 Guiness and curry
16:26 brrt is delay the insertion of stores
16:26 brrt until the end of the bb
16:26 brrt anyway, i guess that too
16:26 brrt decommute &
16:30 edehont joined #moarvm
16:33 timotimo it feels like there was some missing context to that explanation ...
16:48 edehont joined #moarvm
17:28 brrt joined #moarvm
17:28 brrt timotimo: yes, there was
17:29 brrt the issue at hand was that the expr jit inserts just as many stores to stack memory as the regular jit, 'cause it can't determine whether the value will be used at some later point
17:30 brrt so to be safe, it just insert a store-to-memory after everything that corresponds to a moarvm opcode
17:31 brrt i want to get rid of these stores as far as possible, but it is hard as long as we might jump out of the compiled code at any point
17:32 brrt (hence, we need deopt bridges so that the stores can be placed in there, hence, i need you to build them so i can build on them... you see :-))
17:39 brrt okay, i'm officially very, very, very tired
17:40 domidumont joined #moarvm
17:41 brrt but, i managed not to break the JIT just yet
17:41 brrt so i'm going to commit
17:43 dalek MoarVM/even-moar-jit: d7aa0d3 | brrt++ | src/core/dynar.h:
17:43 dalek MoarVM/even-moar-jit: Use DYNAR macro arguments only once if possible
17:43 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/d7aa0d3d28
17:43 dalek MoarVM/even-moar-jit: f9fe7ca | brrt++ | / (12 files):
17:43 dalek MoarVM/even-moar-jit: Bikeshedding - rename DYNAR to VECTOR
17:43 dalek MoarVM/even-moar-jit:
17:43 dalek MoarVM/even-moar-jit: Vector is probably more common terminology for a resizing array
17:43 dalek MoarVM/even-moar-jit: than 'DYNAR', and nearly as short.
17:43 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/f9fe7cac71
17:43 dalek MoarVM/even-moar-jit: c07a09f | brrt++ | / (5 files):
17:43 dalek MoarVM/even-moar-jit: Move tile list editing to tile.c
17:43 dalek MoarVM/even-moar-jit:
17:43 dalek MoarVM/even-moar-jit: A bit more sensible that way I hope
17:43 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c07a09fba2
18:16 timotimo oh crap, i didn't know anybody would ever depend on deopt bridges
18:25 timotimo but the deopt bridge stuff will only appear in places where deopting instructions are placed, i.e. where there are guards and deopt annotations
18:25 timotimo so everywhere else you can already "be safe", at least exactly as safe as you'll be when deopt bridges exist
19:17 kjs_ joined #moarvm
19:28 kjs_ joined #moarvm
20:03 vendethiel joined #moarvm
20:34 ggoebel joined #moarvm
20:34 brrt joined #moarvm
20:39 domidumont joined #moarvm
20:52 kjs_ joined #moarvm
21:03 Ven joined #moarvm
21:29 edehont joined #moarvm
21:56 Ven joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary