| timotimo | my brain isn't letting me sleep ... once again | 02:27 | |
| this dumb idea is milling about in my head: | |||
| 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 | ||
| 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 :) | |||
| because multiple threads | |||
| but let me finish my thought anyway | 02:29 | ||
| 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 | ||
| 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
|
|||
| brrt | good * #moarvm | 05:31 | |
|
07:08
zakharyas joined
07:57
domidumont joined
08:01
domidumont joined
08:51
kjs_ joined
09:50
kjs_ joined,
domidumont joined
|
|||
| 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 | 10:52 | |
|
12:10
domidumont joined
|
|||
| [Coke] notes to timotimo that Coke works for an internet of things company! | 14:05 | ||
| (of course, I'm no where near that code :) | 14:06 | ||
| jnthn | Is it the one that makes the reminders toaster? :) | ||
| [Coke] | jnthn: no, the jet engines. | 14:08 | |
| jnthn | That's more cool, but I'm not sure I want one of those in my apartment... :) | 14:09 | |
| nine | I'd totally want a jet engine :) | 14:10 | |
| jnthn | Don't you fly jets? :) | 14:11 | |
| unmatched} | An internet connected jet engine? ... and I thought the blue tooth pee stick was insane.... | ||
| 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 :) www.wired.com/2010/08/sailplane-lau...et-engine/ | ||
| jnthn | Ah, sail planes :) | 14:14 | |
|
15:52
kjs_ joined
|
|||
| [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". | 15:59 | |
| I... work on the taxes; nothing exciting like IOT stuff. | 16:00 | ||
| nwc10 | so you're on the only guaranunteed "product" line in the entire company? :-/ | 16:02 | |
| (although the profit centres do need to keep existing to pay for the cost centres) | |||
|
16:02
kjs_ joined
|
|||
| [Coke] | nwc10: it's… complicated. | 16:03 | |
| I will be happy to explain it over beers or equivalents | |||
| nwc10 | OK. I was rather hoping that it wasn't complicated. Or at least, that it wasn't stressfully complicated. | 16:04 | |
| ie not "may you live in interesting times" | |||
| will happy share beers if our paths cross in the right place | 16:05 | ||
|
16:09
zakharyas joined
16:13
brrt joined
|
|||
| [Coke] | Closest I get for a while is probably dublin/leeds next month. | 16:17 | |
|
16:18
brrt joined
|
|||
| brrt | one of the simpler things to do | 16:25 | |
| timotimo | oh? | ||
| nwc10 | Guiness and curry | ||
| brrt | is delay the insertion of stores | 16:26 | |
| until the end of the bb | |||
| anyway, i guess that too | |||
| decommute & | |||
|
16:30
edehont joined
|
|||
| timotimo | it feels like there was some missing context to that explanation ... | 16:33 | |
|
16:48
edehont joined
17:28
brrt joined
|
|||
| brrt | timotimo: yes, there was | 17:28 | |
| 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:29 | ||
| so to be safe, it just insert a store-to-memory after everything that corresponds to a moarvm opcode | 17:30 | ||
| 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:31 | ||
| (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:32 | ||
| okay, i'm officially very, very, very tired | 17:39 | ||
|
17:40
domidumont joined
|
|||
| brrt | but, i managed not to break the JIT just yet | 17:41 | |
| so i'm going to commit | |||
| dalek | arVM/even-moar-jit: d7aa0d3 | brrt++ | src/core/dynar.h: Use DYNAR macro arguments only once if possible |
17:43 | |
| arVM/even-moar-jit: f9fe7ca | brrt++ | / (12 files): Bikeshedding - rename DYNAR to VECTOR Vector is probably more common terminology for a resizing array than 'DYNAR', and nearly as short. |
|||
| arVM/even-moar-jit: c07a09f | brrt++ | / (5 files): Move tile list editing to tile.c A bit more sensible that way I hope |
|||
| timotimo | oh crap, i didn't know anybody would ever depend on deopt bridges | 18:16 | |
| 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 | ||
| 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
19:28
kjs_ joined
20:03
vendethiel joined
20:34
ggoebel joined,
brrt joined
20:39
domidumont joined
20:52
kjs_ joined
21:03
Ven joined
21:29
edehont joined
21:56
Ven joined
|
|||