| timotimo | it looks like we're discarding facts when inlining stuff | 01:53 | |
| that way my innermost loop creates an Int object because binding to the CArray returns the bound value | |||
| and that seems to cause one GC run per frame, on average | 01:54 | ||
| and it seems like every third frame there isn't a GC run, which makes that frame a whole bunch faster | |||
| hm. the flags from the facts are gone, but the usages aren't | 01:55 | ||
| but right now i'm feeling too tired to dig into this more | 01:57 | ||
| uh... huh? | 02:05 | ||
| REPR(repr_data->elem_type)->box_funcs.set_int(...) for binding an int value into a CArray ... | |||
| this must be about different sizes, right? | |||
| could this indirection be really expensive, i wonder? | 02:06 | ||
| i'll probably find out more about that if i use a Buf[int32] instead of the CArray[int32] and seeing how that changes things | 02:10 | ||
| Type check failed in assignment to ; expected int32 but got Int (4294967295) | 02:12 | ||
| :\ | |||
| oh, duh | 02:13 | ||
| OK, so with a my int32 @pixdata instead of the CArray it doesn't get much faster | 02:14 | ||
| hardly at all, actually | |||
| i'm out of smart ideas. apart from the "properly eliminate the returned value and remove a boxing in the process" i don't know how to make this noticably faster ;_; | 02:18 | ||
| but i'm rather glad that both postcircumfix:<[ ]> and ASSIGN-POS are properly inlined here | |||
|
02:48
ilbot3 joined
|
|||
| timotimo | m: say 320 * 240 | 02:52 | |
| camelia | rakudo-moar 8fdaad: OUTPUTĀ«76800ā¤Ā» | ||
| timotimo | 76k 32bit values per frame, hmm. | 02:53 | |
| m: say (320 * 240 * 4) / 1024 | |||
| camelia | rakudo-moar 8fdaad: OUTPUTĀ«300ā¤Ā» | ||
| timotimo | 300 kB of data, eh? | ||
| i don't have a good frame of reference to know if ~15 frames per second setting 300 kilobytes of memory to one of two values is ridiculously slow or just quite slow | 02:54 | ||
| m: say 15 * (320 * 240 * 4) / 1024 | 02:55 | ||
| camelia | rakudo-moar 8fdaad: OUTPUTĀ«4500ā¤Ā» | ||
| timotimo | 4 megabytes per second? is that right-ish? | ||
|
04:34
cognominal joined
04:58
vendethiel joined
09:12
psch joined
09:51
vendethiel joined
10:27
q0tw4 joined
11:32
domidumont joined
11:39
vendethiel joined
12:15
vendethiel joined
12:19
FROGGS joined
12:53
FROGGS joined
13:40
vendethiel joined
|
|||
| FROGGS | timotimo: remember me saying that I've got a mutator method on a CStruct and that it doesnt mutate it? | 13:54 | |
| well, the problem seems to be about multi methods where one method is native, and the other isnt | |||
| and the multi methods are a workaround for this: | 13:58 | ||
| m: sub foo(num32()) { * }; foo 42 | |||
| camelia | rakudo-moar 7010f3: OUTPUTĀ«Method 'num32' not found for invocant of class 'Int'ā¤ in sub foo at /tmp/G106f0f0Bg line 1ā¤ in block <unit> at /tmp/G106f0f0Bg line 1ā¤ā¤Ā» | ||
| FROGGS | m: use NativeCall; sub foo(num32()) is native { * }; foo 42 | ||
| camelia | rakudo-moar 7010f3: OUTPUTĀ«Potential difficulties:ā¤ In 'foo' routine declaration - Not an accepted NativeCall type for parameter [1] : Anyā¤ --> For Numerical type, use the appropriate int32/int64/num64...ā¤ at /tmp/j0VnKY0qTb:1ā¤ ------> veCall; sub foo(num32()ā¦Ā» | ||
| FROGGS | jnthn: do you agree that both lines are valid? | 14:18 | |
| (the code, not the output) | |||
|
14:40
vendethiel joined
15:19
vendethiel joined
15:28
zakharyas joined
16:07
dalek joined
|
|||
| FROGGS | and if I have this: | 16:54 | |
| multi method mutate1() { self.mutate1(self) } | |||
| multi method mutate1(StructIntStruct) is symbol('MutateStructIntStruct') is native('./06-struct') { * } | |||
| I get: | |||
| Cannot invoke object with invocation handler in this context | |||
| jnthn | I'm not especially inclined to support coercion types in NativeCall | 17:15 | |
| I suspect it'll complicate the efforts to more efficiently compile them | 17:17 | ||
| arnsholt | I'm not sure a method with is native would work even if it weren't multi? | 17:18 | |
|
17:28
domidumont joined
|
|||
| FROGGS | arnsholt: ohh, it does | 17:44 | |
| arnsholt: the invocant is just a fancy first argument | 17:45 | ||
| arnsholt | Oh, neat! | ||
| FROGGS | jnthn: so any clue why my last example explodes like that? | ||
| hmm, maybe I can call a sub as a workaround | 17:46 | ||
| timotimo | i often put "my sub" inside classes when building NativeCall stuff | 17:48 | |
| FROGGS | I can't :o( | ||
| because methods are getting mangled differently than subs | 17:49 | ||
| timotimo | damn. we might need a trait for that | ||
| FROGGS | no, I just create a private method with another name (to not have a multi) | 17:50 | |
| or can it have the same name? I guess so | |||
| that works!! \o/ | 17:51 | ||
| method !SetAsBox(num32 $hx, num32 $hy) is symbol<b2PolygonShape::SetAsBox> is native<Box2D> { * } | |||
| method SetAsBox($hx, $hy) { self!SetAsBox: $hx.Num, $hy.Num } | |||
| I dont even need the 'is symbol' trait here | |||
| nice | 17:52 | ||
| timotimo | oh, that's surprising | ||
|
18:42
ilbot3 joined
|
|||
| FROGGS | jnthn: then we need to error out nicely | 20:24 | |
| jnthn | FROGGS: I'd rather try and fix that particular one :) | 20:38 | |
| FROGGS | then I misunderstood :o) | 20:39 | |
| jnthn | Well, I wasn't clear either :) | 20:40 | |
| It boils down to a limitation in MoarVM, which I think we can lift with some thought. I forget the exact details. | 20:41 | ||
| But will be looking carefully at invocation soon anyways. | |||
| FROGGS | I believe this is a thinko: github.com/MoarVM/MoarVM/blob/mast...uct.c#L351 | 21:14 | |
| the last argument to initialize is the body of the attr in question | 21:15 | ||
| and this body cannot be inlined in the structs memory | |||
| otoh, I need such a mechanism to do inlined stuff correctly | 21:18 | ||
| currently an inlined something still allocates, which is wrong | |||
| jnthn | Note that not all attributes are in initialized_slots | 21:19 | |
| iirc, those that are references (non-inlined) won't be in there at all | |||
| FROGGS | only bigints might make it in there | ||
| jnthn | Not in the CStruct case | 21:20 | |
| But in P6opaque, yeah | |||
| But we also use it to make sure num fields get initialized to NaN | |||
| FROGGS | P6int and P6num dont have initialize, so these dont make it in there too | ||
| jnthn | Oh? | ||
| I thought P6num did | |||
| FROGGS | /home/froggs/dev/MoarVM/src/6model/reprs/P6int.c:207: NULL, /* initialize */ | ||
| /home/froggs/dev/MoarVM/src/6model/reprs/P6num.c:157: NULL, /* initialize */ | |||
| jnthn | Hm, interesting, it doesn't | 21:21 | |
| m: class A { has num $.b }; say A.b | |||
| camelia | rakudo-moar 7010f3: OUTPUTĀ«Invocant requires an instance of type A, but a type object was passed. Did you forget a .new?ā¤ in block <unit> at /tmp/VapoOAEI2M line 1ā¤ā¤Ā» | ||
| jnthn | m: class A { has num $.b }; say A.new.b | ||
| camelia | rakudo-moar 7010f3: OUTPUTĀ«0ā¤Ā» | ||
| jnthn | oops | ||
| m: my num $a; say $a; | |||
| camelia | rakudo-moar 7010f3: OUTPUTĀ«NaNā¤Ā» | ||
| FROGGS | and even if they had, passing the memory of the CStruct (plus offset) as the OBJ_BODY() of a num is wrong too | ||
| jnthn | Should be that... | ||
| Yeah, I suspect that code is lifted straight from P6opaque | 21:22 | ||
| Where it would be the right thing to do | |||
| FROGGS | yeah | ||
| I wonder what we should do here... passing the real storage to initialize (or something similar called) is what I could need | 21:23 | ||
| jnthn | Something like that, yeah. | 21:24 | |
| Though interesting...I guess maybe the "shadow" storage also needs to be considered... | |||
| (for wrappers) | |||
| FROGGS | can I just add initialize_native? | 21:28 | |
| or is that the Wring Approachā¢? | |||
| Wrong* | |||
| jnthn | Sounds odd | 21:29 | |
| FROGGS | *g* | ||
| just the name or the approach? | |||
| jnthn | It may be that CStruct simply wants to know about/recognize embeddings of CArray/CStruct and specially handle them | 21:30 | |
| FROGGS | yes exactly | ||
| jnthn | I don't think there's a combinatoric explosion here | ||
| So I don't know we need to define an extra bit of REPR API | 21:31 | ||
| Not unless we see we really need it | |||
| FROGGS | CStruct, CPPStruct, CUnion and CArray | ||
| ohh | |||
| jnthn | Hm, forgot we had CPPStruct too :) | 21:32 | |
| FROGGS | I could let the ->cstruct of the attr point to the right place and then call initialize (for inlined CStructs) | ||
| and then dont malloc | |||
| jnthn | I *think* that seems workable, but what about child_objs handling? | 21:35 | |
| FROGGS | what do you mean? | 21:36 | |
| jnthn | Well, I guess I don't know how that is handled at all for inlined structs... :) | 21:38 | |
| But guess it must be | |||
| ah, I think I see how it works, looking at the code :) | 21:39 | ||
| So, no worries | |||
| FROGGS | phew :o) | 21:40 | |
| so I continue plaing around | |||
| playing* | |||
| jnthn | :) | ||
| FROGGS++ | |||
| jnthn looks forward to playing around with things a good bit more again soon :) | |||
|
22:36
q0tw4 left
|
|||
| japhb | jnthn++ # Lots more leak fixes | 23:35 | |
| timotimo | i'm briefly looking at DWARF and the tools that exist to handle it (dwarfdump, dwgrep, libzwerg) | 23:45 | |
| that'd probably be easier than parsing the C source to figure out how structs and such work | |||
| especially because of things like aligning that you'd have to implement some algorithms for, afte rall | |||
| developerblog.redhat.com/2015/01/2...nd-profit/ | 23:46 | ||
| in any case, dwarfdump spits out struct names and sizes and members with their "DW_AT_data_member_location" | 23:50 | ||
| so for a heap explorer, this stuff can be quite helpful i imagine | 23:51 | ||
| anyway, towards bed. hoping to get better 'til tomorrow | |||