00:46 cognominal joined 00:52 woosley joined 01:10 FROGGS_ joined 03:13 btyler joined 06:43 FROGGS joined 06:48 zakharyas joined
jnthn So, while my class hack out staged event driven architecture code, I'm pondering the "we waste so much time on SC lookups" issue 08:10
Of note, in CORE.setting compilation
At the moment we point to an SC
nwc10 how much profiling info do you have currently?
jnthn It occurs to me we could keep an array of active SCs somewhere, and then usem the current pointer slot to point to an SC offset into it and the index in the SC. 08:11
It's an extra level of indirection, but not on a hot path
nwc10 what is "the current pointer slot"? 08:12
jnthn nwc10: A C-level profile should this as basically the most expensive thing that wasn't being in the interp runloop or GC.
*showed
nwc10 I don't know if I'm useful here asking questions, but I vaguely remember the basic structure of the Object header
OK. "ouch" 08:13
jnthn As in, most costly thing in CORE.setting compilation once you discount the interp and GC.
Thing is, it goes O(n**2) on setting size
And recent not-huge additions have had a big cost :(
nwc10 oh. that would be bad.
jnthn So I think this is a likely culprit.
I'm referring to the sc pointer in the object header. 08:14
nwc10 ah
so this would as a side effect eliminate the SC pointer?
oh, which is in the union, so "nevermind" 08:15
moritz where does the O(n^2) come from? 08:16
nwc10 the pointer dereference of sc_forward_u.sc is the pain?
jnthn moritz: Serializing. 08:18
We need to turn object references into indexes.
And we currently do it by linear search.
So if you have n objects in an SC to serialie, with an average of m references to other things in the SC, then it's O(mnn) 08:19
nwc10 oh, right
he said "linear search". snigger
jnthn nwc10: Well, we can either just change the entry in the union to be either a pair of some SC number (index into another array) and an offset in that 08:20
Or we can look at having a totally separate lookup table
So that we just have a flag bit "in an SC"
make every object smaller
nwc10 will it? For a 64 bit platform, I'd assume that we're talking pointers of 64 bits, and 2 indexes of 32 bit each 08:21
32 bit platform is more annoying, as I guess that we're still talking 2 indexes of 32 bit each
jnthn Uh, it's the alternative approach that makes them smaller
Sticking the index etc into the header makes the larger on 32-bit
Same on 64-bit though. 08:22
nwc10 ah righto
yes, my gut feeling is that it's important to keep the same code paths on 32 and 64 bit systems
jnthn oh, certainly
nwc10 programmer sanity is much more valuable than the memory saving
it's why Perl 5 never got NVs moved into the SV head, as it would only make sense on 64 bit platforms
(OK, strictly, anything built with 64 bit integers) 08:23
jnthn Anyway, we need to do something about this.
As it's currently quite a slowdown 08:24
For compilation, taht is.
nwc10 hopefully not in the "do something" sense of en.wikipedia.org/wiki/Politician%27s_syllogism
jnthn Well, that's why I'm weighing up the solutions... 08:25
Trying to make sure the "something" gives the improvement we want without an icky drawback.
nwc10 I wonder if Wikipedia is accurate, and the entire "This is something" reasoning was not indentified before Yes, Prime Minister 08:26
jnthn A solution that lets us shrink every object is nice, but also hassle. Currently the forwarder pointer shares the SC slot, for example. 08:27
nwc10 yes, that was my point about the union
I can't see a good way to shrink objects
jnthn Well, the forwarder pointer can overwrite data in the old object body
nwc10 oh, yes, I forgot that. oops :-) 08:28
jnthn iirc there's one more funky thing in taht union 08:29
nwc10 yes
/* Used to chain STables queued to be freed. */
MVMSTable *st;
jnthn Though iirc it was something I found deplorable design-wise anyway :)
nwc10 is looking at said union
jnthn oh...
yeah, I think that can change easily enough. 08:30
nwc10 I think, if one is going to shrink stuff, that flags (or at least 1 bit of it) likely has to not be in a union with "forwarding pointer"
are STables so large that they are "oversized" and hence allocated individually? 08:32
jnthn I think so 08:33
Well, in gen2 anyway
in nursery they just eat space, but we make relatively few of them.
(compared to toher object tyeps)
nwc10 that seems to be sort-of-a bother as one way to eliminate that chain from the union would be to sweep the STable allocation pool. But there isn't a pool 08:34
in that, I'm wary of having the GC code need to allocate memory to create a structure to remember what it needs to free
jnthn teaching, bbl] 08:41
09:10 donaldh joined
nwc10 jnthn: you didn't ask for advice, so this may not be what you wanted :-) 09:40
but my gut feeling is start with "the simplest thing that could possibly work" to get down to O(n) 09:41
even if it increases memory use slightly
and then do or delegate the "figure out a terser way"
oh, and benchmark the "terser" way
10:12 woosley left
jnthn nwc10: That's my feeling also. Especially as it only increases it on 32-bit 10:25
And we know there's a path to decrease it again 10:26
And yes, delegating the clever way is also a good idea.
nwc10 I suspect that the net speed win from doing KISS earlier will pay off 10:31
jnthn aye 10:32
awww...I leave Stockholm on Wed, and snow is forecast for thu
So I miss the snow :(
DrEeevil i don't 10:45
10:49 cognominal joined
jnthn DrEeevil: You have snow? 10:50
Winter here was really tame...
DrEeevil about once a year
still too much cold stuff
jnthn Oh...I like the cold stuff :)
DrEeevil i need clothes at temeratures under 20c to not start shaking 10:51
winter is suffering
jnthn I tend to wear clothes in all weather, tbh... :)
I tend to suffer once it gets over 25... 10:52
DrEeevil around 35c clothes become silly
aka. every day in july ;)
jnthn Thankfully, 35C jsut about doesn't happen here :) 10:58
DrEeevil boring ;) 11:13
timotimo o/ 12:06
jnthn hi timotimo 12:25
FROGGS that was a very nice discussion btw, but can somebody explain what that means? "<nwc10> I suspect that the net speed win from doing KISS earlier will pay off" 12:33
that is like a WAT to me :o)
jnthn Do you understand the meaning of KISS? :)
Hint: not the rock band :P 12:34
Anyway, I think nwc10++ just means "better to do the simple thing soon and get a win, than do nothing until we've resources to do the hard thing" 12:35
FROGGS no, I do not understand KISS, but I get what you said :o)
jnthn Keep It Simple, Stupid 12:36
FROGGS ahh, yes
lizmat or: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” 12:37
--Brian Kernighan
jnthn You could always just hope you're smarter in the future :P
lizmat that's only valid up to a certain age :-)
jnthn pretends to still be young enough :) 12:38
nwc10 jnthn: how do JVM and Parrot backends avoid being O(n²) for Serialisation Contexts? 12:39
jnthn nwc10: They don't.
nwc10 ah OK, so this is a cross-backend problem?
or, more, same issue in 3 different code bases?
jnthn It's more an issue of "seting grew big enough to make it hurt" than "no problem"
So we'll want a JVM fix too 12:40
But it'll look different I suspect
[Coke] /me, in review, googles "perl 6 glossary SC", hits enter, immediately remembers what SC means in this.... context. 12:55
jnthn :D 13:49
14:03 btyler joined 15:08 brrt joined 15:42 brrt joined 15:58 donaldh joined 16:11 FROGGS joined 16:30 btyler joined 16:54 brrt joined
brrt I think i'm beginning to understand the workings of spesh 17:53
FROGGS brrt++
brrt but slowly
FROGGS (I did no attempt to understand it yet, but also I never did CS studies which could be helpful here) 17:54
brrt neither did i
but i have a book
also - i really really want to write MVMPointerBuffer 18:11
timotimo what'd that be? 18:14
brrt i'm writing it as we speak
(but having trouble with emacs thinking 2 spaces is enough indentation) 18:15
timotimo well, what do you use it for? 18:19
you can put MVMObjects into it and access their raw memory? :P
brrt i intend it for internal use :-) 18:25
wait, i show you 18:27
gist.github.com/bdw/11408247 18:28
basically, something for the (extremely common) use case of 'if (foo->bar_num >= foo->bar_alloc) { foo->bars = realloc(foo->bars, 2 * foo->bar_alloc * sizeof(MVMBar*); foo->bar_alloc *= 2; }' 18:30
or, also common:
'new_bar = malloc((foo->num_bar + 1) * sizeof(MVMBar*)); memcpy(foo->bar, new_bar, foo->num_bar * sizeof(MVMBar*)); foo->bars[foo->num_bar] = a_bar; foo->num_bar++;' 18:31
which src/spesh/graph.c repeats 5 times or so 18:32
imho thats just cognitive overload and an off-by-one waiting to happen
(or a lost free)
and.. while i know that jnthn for one must be really amazingly good by as little mistakes as seem to have been made 18:39
i'm pretty sure i'm not that good myself 18:41
timotimo oh, huh. 18:45
brrt i mean there's an error in the code i wrote just now :-) 18:47
19:13 brrt joined
jnthn
.oO( so he'd have been better off copy-pasting mine? ;) )
 20:29
.tell brrt feel free to factor that out, if it makes the code easier for you to work with. :)
aww, no msgbt
FROGGS he tends to backlog IIRC 20:30
TimToady we really need to dogfood that 20:31
nwc10 dogfoodmsgbot? om nom woof?
I think IRC bots would be excellent dogfood. I might have said this an annoying number of times already 20:32
FROGGS hehe, and nothing happened? :P
nwc10 there was a valid reason. There isn't now. 20:33
er, there was a valid reason not to. But that reason pleasingly resolved
TimToady resolving, at least
but that's why we should dogfood it 20:34
dalek arVM/vm-null: 0487e37 | jonathan++ | / (8 files):
Add MVMNull REPR, instance->VMNull.
 21:14
timotimo oh, we won't be exploding with null objects any more? :) 21:16
jnthn Well, once the rest of the work this needs is done... :)
But really I need to distinguish "not vivified" from "deliberately nulled" 21:17
So it's opt work that's finally forced the issue :)
timotimo oh, more opt work, eh? 21:20
jnthn after the yak shave, yes. :) 21:21
timotimo will this change also mean when we know the repr of something, we know it's not null? 21:25
jnthn no 21:26
VMNull has REPR MVMNull
dalek arVM/vm-null: 2de460c | jonathan++ | src/6model/reprs/MVMNull.h:
Add static inline func for doing a VM-null check.
 21:31
arVM/vm-null: 05e9397 | jonathan++ | src/core/interp.c:
Make nqp::null and nqp::isnull VM-null aware.
jnthn We'll also be able to rid ourselves of ass_null in P6opaque... 21:32
21:41 cognominal joined 21:52 cognominal joined 22:01 donaldh_ joined
dalek arVM/vm-null: a134f2c | jonathan++ | src/6model/serialization.c:
Teach serialization about VM nulls.
 22:02
arVM/vm-null: 859f173 | jonathan++ | src/ (3 files):
Teach P6opaque about VMNull; eliminate ass_null.
arVM/vm-null: e036632 | jonathan++ | src/core/interp.c:
Teach ifnonnull about VMNull.
arVM/vm-null: f53bc26 | jonathan++ | src/core/continuation.c:
Update continuations code for VMNull.
jnthn Well, NQP builds and passes tests on that at least... 22:03
Sleep time...more tomorrow 22:05
timotimo gnite jnthn! 22:07
22:37 ggoebel111112 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!