MasterDuke timotimo: have you seen this, a size profiler for binaries? blog.reverberate.org/2016/11/07/int...tface.html 02:01
02:48 ilbot3 joined
samcv goddamit. grapheme cluster break is broken for bool and for int 02:48
no wonder it didn't work. oh well. will just do it by string
MasterDuke `my $j = "mem_leak.json".IO.slurp; for $j.comb.grep { .uniprop-bool('Grapheme_Cluster_Break') } { .say }` like this? 02:50
samcv oh i see because there's no \n in the actual json file. that's why
well no literal newline
i gotta do from-json 02:51
sec
gonna start listing minory bugs and buglets here github.com/MoarVM/MoarVM/projects/1 02:53
will need to think up some way to test all of them 02:54
ok the special GCB cp's are (9 10 13 27) 02:55
MasterDuke, and you say that even with your change for crlf it is still taking a very large amount of time in re_nfg? 02:58
MasterDuke rep
*yep
samcv ok it has two high cp's 02:59
which are higher than MVM_NORMALIZE_FIRST_SIG_NFC which = 0x0300 03:00
(8216 8217) are the high cp's
was wondering if we strip those two cp's if it would affect the runtime. would you be able to test that for me if i give you a stripped json?
MasterDuke yeah 03:01
samcv sweet. will help to eliminate that as contributing to it or not
is there a reverse of 'ords' that is not Uni.new? 03:03
there should be if it doesn't exist
MasterDuke chars, right? 03:04
samcv chrs? 03:05
that might be it
yep. that's it
always forget about that one
chrs, chars. but totally different methods lol
MasterDuke, here's a gist gist.github.com/4247f877e42832362f...26b4689cad 03:07
MasterDuke same 03:09
same run time, same % for re_nfg, but a little less memory used 03:11
2185296maxresident for orig, 2181080maxresident for new
samcv ok cool 03:13
MasterDuke i'm falling asleep, so time to head off. good luck with re_nfg 03:14
samcv ok cool. how are you benchmarking? so i can try and replicate 03:15
MasterDuke, 03:16
MasterDuke `use JSON::Fast; my $j = "mem_leak2.json".IO.slurp; for ^1 { $ = from-json $j; }` 03:22
samcv and what are you using to profile it?
perf?
MasterDuke yeah
and /usr/bin/time or heaptrack to get memory info
`perf record -g --call-graph dwarf` and then `perf report --call-graph=none --no-children` 03:23
06:58 domidumont joined 07:06 domidumont joined 08:14 brrt joined 08:44 zakharyas joined 11:50 zakharyas joined 12:31 MasterDuke_ joined 12:36 spebern joined 12:42 spebern left, spebern joined
spebern hi, I got a question on nativecall: If "CArray" is used together with some struct it stores pointers to structs, however it seems like it's not possible to store structs in contiguous memory (there is also a bug report on that). Is there some way to do that? In the docmentation of nativecall the secion of "Blobs" and "Buffers" is marked as TBD. Is this probably the way to go? 12:47
timotimo spebern: there'? a module for you 12:48
that was supposed to read "there's"
but yeah, it'd be cool if you could look more into this stuff 12:49
not sure how to factor it on the Perl6 level
like, would we want a different type that configures the CArray repr in a different way?
spebern I had a look at the code and it really doesn't seem possible
but I'd be interested in helping there, since I already had a look at the nativecall code 12:50
timotimo if we have some kind of CStructArray, its atpos_o could create CStruct instances from a field that you registered upon creation
spebern I also think that another type might be needed
timotimo like, use the parametric extensions to 6model to register the type of Struct that's inside 12:51
though we'll also want to make the CStruct able to point to memory owned by a different object
spebern how would that look in perl6 syntax? 12:53
timotimo i'd assume we'd "my CStructArray[MyCoolStruct] $foo"
spebern ah ok CArray -> CStructArray for alligning the structs directly 12:54
timotimo something like that, yeah
if we were to repurpose CArray, we'd either have to turn all other uses of CArray from CArray[Thing] to CArray[Pointer[Thing]]
spebern is anyone working on nativecall recently?
yes that wouldn't be nice 12:55
jnthn We probably want whatever solution we pick to generalize to CUnion also
timotimo though since we have CArray repr as well as CArray type, we can change that
like, the CArray type and the CStructArray type would both use the CArray repr 12:56
but the CArray will automatically put a Pointer[ ] around any CStruct (or CUnion) type it gets passed
and that's then something at the NativeCall module level 12:57
which means we could do something like "use NativeCall :ArraysOfStructAreAlwaysFlat"
to toggle the type's constructor (well, the parameterize method) behavior 12:58
MasterDuke_ jnthn, timotimo: have either of you guys had a chance to look at the new PRs i created recently? nine said he thought #557 was good, but i'm hesitant to continue down the path i'd started for uint attribute fixes unless #557 really is correct (and merged) 13:01
13:02 ggoebel joined
timotimo i see a gigantic problem with that pull request: markdown formatted your exponentiation stars as fi you meant to boldface some text 13:03
MasterDuke_ ha, completely missed that, timotimo++. and fixed 13:04
timotimo the "int sign" sounds more like "is it a negative or positive number?" 13:06
rather than "are we handling a signed or unsigned number?"
so i'd rename the parameter "signed" or "signedness"
MasterDuke_ timotimo: yeah, that makes sense 13:09
timotimo other than that i'd be +1 on this PR. not that i know what i'm doing %) 13:11
MasterDuke_ that parameter goes away in my still-a-work-in-progress branch to fix more uint stuff, but it should be made more clear in the meantime (esp since i have no idea how long the other branch will take to get into a PR state)
timotimo oh, OK
MasterDuke_ i'm attempting to break it into a mp_get_int64 and mp_get_uint64, but i think i need support for uint attributes first 13:16
timotimo could very well be, yeah 13:18
MasterDuke_ and have also run into a problem with reprs 13:19
13:32 nwc10 joined
MasterDuke_ timotimo, jnthn: i think this github.com/MoarVM/MoarVM/blob/mast...ers.c#L168 is where i ran into repr problems 13:39
timotimo what kind? that you'd have to put in a new function into the repr base struct that all the reprs fill out for themselves? 13:40
MasterDuke_ MVMNativeRefREPRData doesn't have enough info to know whether we want a signed or unsigned int
timotimo right. we can put that in there, though 13:41
of course we'll have to fill in that info, too
fortunately we only have to make unsigned int, not unsigned num and no unsigned str
MasterDuke_ yeah, i'd mentioned adding a P6bigunsignedint, but jnthn thought that wasn't necessary 13:43
*P6biguint
timotimo that might want a mp_uint struct, too :P 13:44
not that i see a good way to build that without going through all of libtommath
MasterDuke_ so maybe the solution is adding a flag to some of the existing reprs
and then a native_ref_fetch_u can be added 13:45
or native_ref_fetch_i can figure out which to get/return 13:46
brrt MasterDuke_: I may be wrong about this, but i find it somewhat suspicious that we'd need to treat native-sized integers as 'signed' or 'unsigned' in transfer 13:52
i mean; the things are 64 bits and never cast in any way; so they should transfer throughout the returns and assigns etc... 13:53
(this is true on x64, at least, ymmv on 32 bit platforms) 13:54
MasterDuke_ brrt: i don't think it's that we're treating them differently, so much as where we get them from. e.g., `res->i64 = MVM_nativeref_read_lex_i(tc, cont);` would need to be `res->u64 = MVM_nativeref_read_lex_i(tc, cont);` 13:56
brrt still, on x64, that shouldn't matter a bit 14:01
MasterDuke_ and `MVM_nativeref_read_lex_i` would need to `return ref->body.u.lex.var->u64;` instead of `return ref->body.u.lex.var->i64;`
brrt CPU's are like perl, the only types are in the operators (instructiosn), not in the operands 14:02
i
i guess i'm just saying i'm a bit afraid for duplication of code paths that make no difference 14:03
MasterDuke_ well, if there weren't any unsigned ops/code paths at all, i could see adding just one would be a problem
but we do have things like `case MVM_reg_int8: foo; case MVM_reg_uint8: bar;` 14:04
but this isn't stuff i'm an expert on, so i very well could be doing something wrong (or at least unnecessary) 14:06
there definitely are existing bugs related to signed vs unsigned native attributes 14:07
brrt for smaller things, you'll notice the difference for sure
but yeah, in general the system is not worked out at all 14:08
MasterDuke_ m: say class :: { has uint64 $.x; }.new( x => 2**64-1 ).x
camelia -1
brrt yeah, but that's a matter of interpretation, innit
so where that goes wrong is that the (u)int64-to-Int conversion doesn't take the unsginedness into account
MasterDuke_ you pointed out some problems in codegen related to the above
brrt i guess i did... 14:09
MasterDuke_ but i'm not sure where that knowledge about signed vs unsigned should go in that particular case
unfortunately i'm not at my computer to look at my code and i don't remember the *exact* problem i was running into 14:11
i think after you last pointed out the codegen problem i was delving into nqp to try a fix there, but somehow ended back up in moar 14:12
brrt hmmm
i'm not sure either and i don't really have the opportunity to look into it 14:13
MasterDuke_ but i may have just gotten prematurely lost trying to figure out github.com/perl6/nqp/blob/master/s...#L651-L731 14:15
i'll just keep asking questions, hopefully a nice solution will work its way out eventually 14:18
16:07 zakharyas joined 16:14 brrt joined 16:35 domidumont joined 17:41 japhb joined 18:19 zakharyas joined 18:28 domidumont joined 18:32 FROGGS joined 20:08 pyrimidine joined 20:22 avar joined 20:23 zakharyas joined 20:31 domidumont joined
samcv good * 20:33
samcv yawns
timotimo heyo 21:03
21:28 pyrimidine joined 22:22 pyrimidine joined
timotimo i wonder if i can make JSON::Fast better by just splitting the text on \ as the first order of business 23:23
23:53 pyrimidine joined 23:58 Guest48761 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!