Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-03-21

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
02:01 MasterDuke timotimo: have you seen this, a size profiler for binaries? http://blog.reverberate.org/2016/11/07/introducing-bloaty-mcbloatface.html
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:48 samcv goddamit. grapheme cluster break is broken for bool and for int
02:48 samcv no wonder it didn't work. oh well. will just do it by string
02:50 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
02:50 samcv well no literal newline
02:51 samcv i gotta do from-json
02:51 samcv sec
02:53 samcv gonna start listing minory bugs and buglets here https://github.com/MoarVM/MoarVM/projects/1
02:54 samcv will need to think up some way to test all of them
02:55 samcv ok the special GCB cp's are (9 10 13 27)
02:58 samcv 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
02:58 MasterDuke *yep
02:59 samcv ok it has two high cp's
03:00 samcv which are higher than MVM_NORMALIZE_FIRST_SIG_NFC which = 0x0300
03:00 samcv (8216 8217) are the high cp's
03:00 samcv 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?
03:01 MasterDuke yeah
03:01 samcv sweet. will help to eliminate that as contributing to it or not
03:03 samcv is there a reverse of 'ords' that is not Uni.new?
03:03 samcv there should be if it doesn't exist
03:04 MasterDuke chars, right?
03:05 samcv chrs?
03:05 samcv that might be it
03:05 samcv yep. that's it
03:05 samcv always forget about that one
03:05 samcv chrs, chars. but totally different methods lol
03:07 samcv MasterDuke, here's a gist https://gist.github.com/4247f877e42832362f6e1126b4689cad
03:09 MasterDuke same
03:11 MasterDuke same run time, same % for re_nfg, but a little less memory used
03:11 MasterDuke 2185296maxresident for orig, 2181080maxresident for new
03:13 samcv ok cool
03:14 MasterDuke i'm falling asleep, so time to head off. good luck with re_nfg
03:15 samcv ok cool. how are you benchmarking? so i can try and replicate
03:16 samcv MasterDuke,
03:22 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?
03:22 samcv perf?
03:22 MasterDuke yeah
03:22 MasterDuke and /usr/bin/time or heaptrack to get memory info
03:23 MasterDuke `perf record -g --call-graph dwarf` and then `perf report --call-graph=none --no-children`
06:58 domidumont joined #moarvm
07:06 domidumont joined #moarvm
08:14 brrt joined #moarvm
08:44 zakharyas joined #moarvm
11:50 zakharyas joined #moarvm
12:31 MasterDuke_ joined #moarvm
12:36 spebern joined #moarvm
12:42 spebern left #moarvm
12:42 spebern joined #moarvm
12:47 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:48 timotimo spebern: there'? a module for you
12:48 timotimo that was supposed to read "there's"
12:49 timotimo but yeah, it'd be cool if you could look more into this stuff
12:49 timotimo not sure how to factor it on the Perl6 level
12:49 timotimo like, would we want a different type that configures the CArray repr in a different way?
12:49 spebern I had a look at the code and it really doesn't seem possible
12:50 spebern 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
12:50 spebern I also think that another type might be needed
12:51 timotimo like, use the parametric extensions to 6model to register the type of Struct that's inside
12:51 timotimo though we'll also want to make the CStruct able to point to memory owned by a different object
12:53 spebern how would that look in perl6 syntax?
12:53 timotimo i'd assume we'd "my CStructArray[MyCoolStruct] $foo"
12:54 spebern ah ok CArray -> CStructArray for alligning the structs directly
12:54 timotimo something like that, yeah
12:54 timotimo if we were to repurpose CArray, we'd either have to turn all other uses of CArray from CArray[Thing] to CArray[Pointer[Thing]]
12:54 spebern is anyone working on nativecall recently?
12:55 spebern yes that wouldn't be nice
12:55 jnthn We probably want whatever solution we pick to generalize to CUnion also
12:55 timotimo though since we have CArray repr as well as CArray type, we can change that
12:56 timotimo like, the CArray type and the CStructArray type would both use the CArray repr
12:56 timotimo but the CArray will automatically put a Pointer[ ] around any CStruct (or CUnion) type it gets passed
12:57 timotimo and that's then something at the NativeCall module level
12:57 timotimo which means we could do something like "use NativeCall :ArraysOfStructAreAlwaysFlat"
12:58 timotimo to toggle the type's constructor (well, the parameterize method) behavior
13:01 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:02 ggoebel joined #moarvm
13:03 timotimo i see a gigantic problem with that pull request: markdown formatted your exponentiation stars as fi you meant to boldface some text
13:04 MasterDuke_ ha, completely missed that, timotimo++. and fixed
13:06 timotimo the "int sign" sounds more like "is it a negative or positive number?"
13:06 timotimo rather than "are we handling a signed or unsigned number?"
13:06 timotimo so i'd rename the parameter "signed" or "signedness"
13:09 MasterDuke_ timotimo: yeah, that makes sense
13:11 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)
13:11 timotimo oh, OK
13:16 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:18 timotimo could very well be, yeah
13:19 MasterDuke_ and have also run into a problem with reprs
13:32 nwc10 joined #moarvm
13:39 MasterDuke_ timotimo, jnthn: i think this https://github.com/MoarVM/MoarVM/blob/master/src/6model/containers.c#L168 is where i ran into repr problems
13:40 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
13:41 timotimo right. we can put that in there, though
13:41 timotimo of course we'll have to fill in that info, too
13:41 timotimo fortunately we only have to make unsigned int, not unsigned num and no unsigned str
13:43 MasterDuke_ yeah, i'd mentioned adding a P6bigunsignedint, but jnthn thought that wasn't necessary
13:43 MasterDuke_ *P6biguint
13:44 timotimo that might want a mp_uint struct, too :P
13:44 timotimo not that i see a good way to build that without going through all of libtommath
13:44 MasterDuke_ so maybe the solution is adding a flag to some of the existing reprs
13:45 MasterDuke_ and then a native_ref_fetch_u can be added
13:46 MasterDuke_ or native_ref_fetch_i can figure out which to get/return
13:52 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:53 brrt i mean; the things are 64 bits and never cast in any way; so they should transfer throughout the returns and assigns etc...
13:54 brrt (this is true on x64, at least, ymmv on 32 bit platforms)
13:56 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);`
14:01 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;`
14:02 brrt CPU's are like perl, the only types are in the operators (instructiosn), not in the operands
14:02 brrt i
14:03 brrt 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
14:04 MasterDuke_ but we do have things like `case MVM_reg_int8: foo; case MVM_reg_uint8: bar;`
14:06 MasterDuke_ but this isn't stuff i'm an expert on, so i very well could be doing something wrong (or at least unnecessary)
14:07 MasterDuke_ 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
14:08 brrt 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
14:08 camelia rakudo-moar e5528d: OUTPUT: «-1␤»
14:08 brrt yeah, but that's a matter of interpretation, innit
14:08 brrt so where that goes wrong is that the (u)int64-to-Int conversion doesn't take the unsginedness into account
14:08 MasterDuke_ you pointed out some problems in codegen related to the above
14:09 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
14:11 MasterDuke_ 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:12 MasterDuke_ 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
14:13 brrt i'm not sure either and i don't really have the opportunity to look into it
14:15 MasterDuke_ but i may have just gotten prematurely lost trying to figure out https://github.com/perl6/nqp/blob/master/src/vm/moar/QAST/QASTCompilerMAST.nqp#L651-L731
14:18 MasterDuke_ i'll just keep asking questions, hopefully a nice solution will work its way out eventually
16:07 zakharyas joined #moarvm
16:14 brrt joined #moarvm
16:35 domidumont joined #moarvm
17:41 japhb joined #moarvm
18:19 zakharyas joined #moarvm
18:28 domidumont joined #moarvm
18:32 FROGGS joined #moarvm
20:08 pyrimidine joined #moarvm
20:22 avar joined #moarvm
20:23 zakharyas joined #moarvm
20:31 domidumont joined #moarvm
20:33 samcv good *
20:33 * samcv yawns
21:03 timotimo heyo
21:28 pyrimidine joined #moarvm
22:22 pyrimidine joined #moarvm
23:23 timotimo i wonder if i can make JSON::Fast better by just splitting the text on \ as the first order of business
23:53 pyrimidine joined #moarvm
23:58 Guest48761 joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary