|
00:51
tokuhirom joined
01:48
ilbot3 joined
01:56
zakharyas joined
04:24
retup__ joined
05:32
mtj_ joined
05:35
domidumont joined
05:40
domidumont joined
05:45
tokuhirom joined
05:55
domidumont joined
06:27
japhb joined
06:28
nwc10_ joined,
khagan joined
06:29
sivoais joined
06:35
brrt joined
|
|||
| brrt | good * #moarvm | 07:18 | |
| nine | Good moarning | 07:36 | |
|
09:04
domidumont joined
|
|||
| hoelzro | moarning all | 12:27 | |
| jnthn: do you think you could cut the 2016.05 moar release sometime today? I intend on doing most of the release work tonight my time and I would hate to bug you then =) | 12:28 | ||
| jnthn | Yes, in a meeting now, will do it once I escape :-) | 12:30 | |
| hoelzro | excellent =) | ||
|
12:45
domidumont1 joined
12:47
domidumont2 joined
|
|||
| [Coke] | ++jnthn ++hoelzro | 13:34 | |
| jnthn | OK, will make a cuppa and then get on with the release :) | 13:36 | |
| hoelzro | thanks! | 13:37 | |
| dalek | arVM: 8f9a9eb | jnthn++ | docs/ChangeLog: Update ChangeLog. |
14:16 | |
| arVM: 1fa1e36 | jnthn++ | VERSION: Bump VERSION. |
|||
|
14:17
tokuhirom joined
|
|||
| jnthn | www.moarvm.org/releases/MoarVM-2016.05.tar.gz | 14:26 | |
| hoelzro: ^^ :) | |||
| [Coke] | jnthn++ | 14:33 | |
| hoelzro: note that, despite the ordering the manual, you could basically do the nqp release right now if you wanted. | 14:34 | ||
| ... wrong window, but close enough! | |||
| dalek | href="https://moarvm.org:">moarvm.org: f92b9ea | jnthn++ | / (2 files): Update for 2016.05 release. |
14:37 | |
| timotimo | hm. is the "speed up specialized frame allocation" part missing from the changelog? | 14:38 | |
| is it kosher to update the chaneglog after the release has been cut? | |||
| jnthn | It's in there, I just re-worded it | 14:39 | |
| "Speed up initialization of non-specialized frames" | |||
| [Coke] | timotimo: sure, why not | ||
| jnthn | Felt clearer that way :) | ||
| [Coke] | the changelog (and rakudo's release announcements) are just snapshots that might not reflect what was shipped at the time. | 14:40 | |
| timotimo | but but but | ||
| you also improved how *specialized* frames get allocated | |||
| or did that not get into master? | |||
| jnthn | No, that's in jnthn/opts :) | 14:41 | |
| Deliberately excluded from release for risk reduction :) | |||
| timotimo | oh! | 14:42 | |
| that makes sense, yes | |||
|
14:45
brrt joined
|
|||
| brrt needs more time in a day | 14:45 | ||
| geekosaur | don't we all | 14:46 | |
| timotimo | time to start the uberman sleep schedule | ||
| brrt | hmm, i thought that was your game timotimo :-) | ||
| timotimo | :\ | ||
| brrt | :-P | 14:47 | |
| i have a (cunning) plan to finally get started with the register allocator though | 14:48 | ||
| but a billion things i also have to do that prevent me | |||
| geekosaur | yaaaaaaaaaks :/ | 14:49 | |
|
14:49
lizmat joined
|
|||
| brrt | like dinner... | 14:51 | |
| timotimo | have a good nom in that case :) | 14:52 | |
| hoelzro | jnthn++ | 15:06 | |
| brrt | :-) | 15:17 | |
| ok, i'm going to nom now | 15:35 | ||
|
15:54
domidumont joined
15:57
mst joined
|
|||
| timotimo | should we just merge jnthn/opts into master now that the release has happened? | 16:52 | |
| mst | wossat | 17:00 | |
| timotimo | just some improvements that we didn't want to put into the release just yet | ||
| [Coke] | with timed releases, better to put anything potentially risky just after a release (the thought goes) so we get a full month of testing. | 17:01 | |
|
17:21
cognominal joined
|
|||
| mst | yep | 17:31 | |
|
19:53
tokuhirom joined
20:46
cognominal_ joined
20:47
cognominal joined
|
|||
| jnthn | delivery.acm.org/10.1145/2760000/27...ifford.pdf | 21:37 | |
| timotimo | An error occurred while processing your request. | 21:42 | |
| :( | |||
| imight need to be logged in or something? | |||
| jnthn | gah | ||
| research.google.com/pubs/pub43823.html | |||
| Try that one | |||
| timotimo | thanks :) | 21:43 | |
| jnthn | Pretty easy reading, as GC papers go :) | ||
| timotimo | the mementos they refer to are just bunches of slim records? | 21:45 | |
| maybe a bit like our current "log" data? | |||
| oh, it seems like they live directly next to the object in the nursery | 21:48 | ||
| jnthn | Yeah :) | 21:51 | |
| That's a cool trick | |||
| timotimo | if you know how to skip them, then yeah :) | 21:56 | |
| i suppose we could also use whatever little space we make for aligning objects for little pieces of feedback | 21:59 | ||
| jnthn | Just make the things that'd be in the flag bits be something identifiable :) | 22:00 | |
| TimToady | m: sub foo(+@a) { say @a; }; my @a = 1..Inf; foo(@a) | 22:05 | |
| jnthn | One use we could make of it is seeing with P6opaques always end up getting mixed into, and just making enough space for the extra state | ||
| TimToady | oops | ||
| jnthn | *which P6opaques | ||
| camelia | rakudo-moar c59e4d: OUTPUTĀ«(timeout)Ā» | 22:06 | |
| timotimo | oh, yeah, we've probably got 95% cases where an object either never gets mixed into, or it gets mixed into before it gets marked the first time | ||
| hm, so the memento has to remember for us where the object's allocation site was? | |||
| jnthn | Seems that's the idea, yeah | ||
| timotimo hasn't read that paper far enough yet, but that's what makes most sense to him | 22:07 | ||
| jnthn | I need to read it when I'm not this tired also :) | ||
| timotimo | we could put an evalbot in here, too. but since moarvm is half-way independent of the language, it should only accept copy-pasted .moarvm files :P | ||
| jnthn | m: say "I'm here!" | ||
| camelia | rakudo-moar c59e4d: OUTPUTĀ«I'm here!ā¤Ā» | ||
| timotimo | oh | ||
| well, that's fine, then | |||
| jnthn | It just took ages 'cus timeout :) | ||
| timotimo | also, we already have "compunit from buffer", so we actually *can* evaluate .moarvm files directly with camelia :D | 22:08 | |
| geekosaur | I think it's just travis that needs updating? | ||
| timotimo | but i don't think any useful .moarvm file would fit into an irc line including the nqp bits required to decorate it | ||
| jnthn | geekosaur: Travis updating? | 22:09 | |
| Oh wait, are you confusing here with the p6dev -> perl6-dev transition? :) | |||
| geekosaur | maybe | ||
| timotimo | now i have to find the spot in the paper that comes up with a good way to address the statistics accumulation point for a given allocation site | 22:12 | |
| because so much of our stuff can move | |||
| jnthn | Something for me to ponder when spesh gets its next overhaul anyways :) | 22:14 | |
| timotimo | mhm | ||
| jnthn | GC orchestration is ahead of it in the queue though :) | ||
| timotimo | can you quickly outline a design for measuring the size (and what kind of shape) the orchestration overhead has? maybe i could implement that before you get to it | 22:15 | |
| i remember reading about the "map" kind of thing they speak of (what v8 calls "hidden classes") by the pypy people | 22:16 | ||
| jnthn | Well, you could meausre time from enter_from_allocator up to the point we've sync'd things up | ||
| But performance isn't the main reason I'm going to give it a good going over. It's 'cus it can occasionally hang. | |||
| timotimo | python has this mechanism called __slots__ where if you put that as a member into a class, it'll get much optimized memory layout, but you can't dynamically add attributes | ||
| TimToady saw a talk at OSCON where a guy was doing 10Ghz processing in Lua by not calling anything that allocated to avoid the GC; would our stop-the-world GC clobber that, or do we have any way of exempting a thread from GC? | |||
| timotimo | wow, it can? | ||
| i didn't know about that | |||
| TimToady | that's how we originally specced native types, actualy | 22:17 | |
| *lly | |||
| you can derive and add methods, but not storage | |||
| timotimo | we can exempt a thread from gc by letting every single thing be allocated in the gen2 immediately | ||
| TimToady | okay, was just wonderin' | ||
| jnthn | TimToady: At the moment our stop-the-world will pause that thread too at a safe point | ||
| timotimo | but that currently won't force the GC to skip waiting for that | ||
| jnthn | TimToady: Was it a multi-threaded program or just Lua running on a single thread and never allocating? | 22:18 | |
| TimToady | my impression was single thread, but he didn't say explicitly | 22:19 | |
| timotimo | i'm not sure lua actually has a standard way to do multithreading | 22:20 | |
| jnthn | Yeah. I mean, *that* we can do in so far as if you never trigger GC then you'll never run GC | ||
| But the moment it's one thread of many and others allocate, then (at present) you're in bother | |||
| TimToady | but if we have other threads stressing GC, it'll break | ||
| right | |||
| anyway, just something to bear in mind | 22:21 | ||
| especially as our JIT approaches assembly speeds | |||
| jnthn | There *are* concurrent GC algos. They often involve read barriers. | ||
| timotimo | FWIW, you can get by that limitation by having multiple processes :P | ||
| diakopter | XD | 22:22 | |
| jnthn | If we're going to have one of those, much less of MoarVM is going to be written in C. :) | ||
| ('cus we have enough trouble getting the *write* barriers correct) | |||
| diakopter is/has a write barrier | 22:23 | ||
| timotimo | we don't have a way to get to "we know this list actually only ever stores int/num, so we specialize storage for that"? | 22:24 | |
| TimToady | a cheap hack might be to mark a thread as never allocating, and it just blows up if they do | ||
| TimToady quite understands this would not be terribly high on the priority list :) | 22:25 | ||
| just somewhere we might want to be someday | |||
| jnthn | TimToady: The trouble is that "never allocating" != "never talks about objects" | ||
| TimToady | sure, everything would need to be nativeish | 22:26 | |
| jnthn | TimToady: And if the GC moves an object it's looking at...boom. | ||
| But yeah, it's something I'd like us to cope with eventually :) | |||
| TimToady | certainly one would require a bit of explicit setup before entering that mode | ||
| jnthn | TimToady: Did your OSCON talk happen yet? :) | ||
| TimToady | yes, we're on the way home, sitting at John Wayne | ||
| jnthn | ...at? | ||
| TimToady | airport | ||
| Orange County, CA | 22:27 | ||
| diakopter | SNA | ||
| jnthn | Oh! | ||
| hah | |||
| TimToady | aka Santa Ana | ||
| jnthn | Also today's Friday so I shoulda guessed it was over :) | ||
| TimToady | hence SNA | ||
| it's one less day than it usedta be | 22:28 | ||
| timotimo | when we have natives, we'll usually end up having LexRef, AttrRef or PosRef | 22:31 | |
| that makes even native-ish code GC-y | |||
| It is sufficient to check a single word of | 22:41 | ||
| memory directly after the object to determine if the object | |||
| carries a memento.1 | |||
| ^- i wonder if they don't have a flags vector like we do | |||
| jnthn | Dunno :) | 22:43 | |
| Sleep time :) 'night o/ | |||
| timotimo | gnite jnthn | ||
|
23:54
tokuhirom joined
|
|||