timotimo gnite jnthn 00:04
MasterDuke timotimo, dogbert17_: how do you get a perl6 level backtrace in gdb? 00:34
timotimo call MVM_dump_backtrace(tc) 00:49
will probably have to "up" a few times until you find a frame that has "tc" in it 00:50
MasterDuke: ^
oh, you already found out
01:02 pyrimidine joined 01:13 pyrimidine joined 02:48 ilbot3 joined 02:53 pyrimidine joined
MasterDuke how do i create an MVMString that's just the null char (e.g., '\0')? 03:28
03:55 pyrimidine joined 05:07 geekosaur joined 05:08 pyrimidine joined
samcv uhm MasterDuke 05:11
there's uh
one i added recently could do it 05:12
MasterDuke some function you added? 05:14
samcv MVM_unicode_codepoints_c_array_to_nfg_string
MasterDuke thanks, i'll take a look
samcv yeah i added it for my MVM_unicode_string_from_name "\c[unicode sequence here]"
here's how i called it MVM_unicode_codepoints_c_array_to_nfg_string(tc, (MVMCodepoint *) pointerto 32bit int, array_size); 05:15
err actually MasterDuke you may want to look at chr? 05:16
but the one i just said will work for sure
MasterDuke, yeah here MVM_string_chr(tc, MVMGrapheme32); 05:17
will give you back an MVM_string
MasterDuke what's the codepoint for '\0'? 05:18
samcv 0
MasterDuke doh
samcv (MVMGrapheme32) 0
think that shuld work
MasterDuke seems to do what i want so far, thanks 05:20
samcv \o/
MasterDuke it worked, but what i tried is slower than the existing code. oh well 05:25
samcv: do you happen to know if there's a way in moar to catch exceptions thrown in moar? 05:30
samcv no i do not know
what are you working on?
MasterDuke playing around with radix, trying to make it faster in the case of calling it with base = 10 and all ascii chars 05:31
but few MVMStrings actually have a body.storage_type of ascii 05:33
so converting them to ascii (regular char *) so strtoll can be called on them is actually slower 05:34
samcv strtoll what base are you converting? 05:37
MasterDuke the one passed in an nqp::radix() call
samcv is this arbitrary base? 05:38
MasterDuke yeah
samcv ok
MasterDuke well, up to 36
samcv cause i have a fast atoi function but that's just base 10
so we used strtoll before?
MasterDuke yeah
this is the radix function: github.com/MoarVM/MoarVM/blob/mast...rce.c#L352
it's what gets called by nqp::radix() 05:39
samcv #define strtoll _strtoi64
MasterDuke but doing +"1234" calls coerce_s_[i,n], which is faster 05:40
but that dies if it gets a Unicode Nd
samcv so coerce is faster than radix?
ah
MasterDuke coerce just calls strtoll
samcv you're just trying to make it faster for base 10 right? 05:41
see my fast_atoi function
MasterDuke well, faster for everything would be even better, but base 10 is the most common, so gains there would be great also
samcv github.com/MoarVM/MoarVM/blob/mast...ize.c#L330
was like at least 4x faster than strtol 05:42
MasterDuke hm, doesn't do much error checking though. i'll have to think if i can guarantee when i could use that 05:43
samcv yeah
i don't use it on user inputted data tho, just cause the canonical combining class is stored an ascii 05:44
well i have to get the ascii string because the enum isn't in order
so sped up slurping a big file
by 15%
MasterDuke yeah, radix can get called with anything though
but maybe we can quickly figure out if the string is safe 05:45
samcv yeah
05:46 pyrimidine joined
MasterDuke essentially what i'm doing to test now is convert from MVMString to ascii, replacing any non-ascii chars with '\0', and then checking if strlen == chars of the MVMString 05:47
samcv ah
MasterDuke but that conversion to ascii seems to be where the performance is lost 05:49
MVM_string_ascii_encode_substr 05:50
samcv hm 05:54
does it need to be substr or can it just do the whole string?
oh nvm MVM_string_ascii_encode just calls the substr one 05:56
MasterDuke an offset is passed to radix. also MVM_string_ascii_encode (without the substr) doesn't do the non-ascii replacement, it just dies if it sees any non-ascii char
dies because it passes NULL as the replacement to the substr one
samcv make MVM_string_ascii_encode_substr faster? 05:57
or find some way to check the cp's of the string before converting
MasterDuke i don't see anything obvious to try in MVM_string_ascii_encode_substr 05:58
samcv you can get the graphemes at each point in the strings
and see if they're all in the ascii range 05:59
MasterDuke well, that's pretty much what radix does. just walk the string looking at each char
if MVM_STRING_GRAPHEME_ASCII's were created instead of the other types, we could fast-path them without all the expensive conversion and checking 06:05
but none are created during a compile of nqp or rakudo
any idea how expensive it is to convert/upgrade a MVM_STRING_GRAPHEME_ASCII string to a MVM_STRING_GRAPHEME_32? 06:07
ahh, so late! off to sleep. later... 06:08
samcv night! 06:13
i may be going to sleep soon too
06:17 TimToady joined 06:47 pyrimidine joined 07:08 domidumont joined 07:15 domidumont joined 07:53 brrt joined 08:28 zakharyas joined 08:44 geekosaur joined 10:21 dalek joined 11:00 pyrimidine joined 11:06 pyrimidine joined
brokenchicken oh cool, lizmat is part of TPF too 11:15
call for new TPF grants committee member: news.perlfoundation.org/2017/01/gra...new-m.html 11:16
timotimo that post already has a spam reply :\ 11:18
11:24 pyrimidine joined
brokenchicken heh 11:29
11:49 FROGGS joined
lizmat brokenchicken: I'm not part of TPF, I'm just a member of the grants committee 12:02
brokenchicken Oh, I thought one implied the other... 12:03
lizmat nope :-)
moritz lizmat: how much time do you invest in grant commitee work? 12:49
[Coke] lizmat: I mean, if you squint, we might be considered part of the TPF. but we really have zero exposure to anything outside of "please vote on this grant." 13:04
(that last part to not-lizmsat.)
*lizmat. (wow, typo'd it AGAIN with the s)
moritz lizmsat sounds like a cool name for a satellite :-) 13:05
[Coke] if you just vote and don't manage grants, the time committment is pretty small. (at most a few hours every few months, and that's if there's a large number (or number of contentious) grants.
secretary is a much bigger time commitment, and I'm sure makoto would be happy to discuss that. 13:06
(I am of course answering your lizmat-directed question for me, not liz. :)
moritz [Coke]: ok, thanks 13:08
[Coke]: would you like to nominate me as a member (not secretary)? 13:09
lizmat moritz: what [Coke] said 13:13
[Coke] moritz: I would. 13:33
lizmat would second that :-) 13:34
[Coke] Done. 13:35
moritz thanks 13:36
15:09 FROGGS joined 15:58 domidumont joined 18:01 samcv joined 19:01 pyrimidine joined 19:19 pyrimidine joined 19:36 pyrimidine joined 19:56 pyrimidine joined 20:31 zakharyas joined 21:37 pyrimidine joined 21:54 pyrimidine joined 22:11 pyrimidine joined
MasterDuke samcv: managed to make radix take fewer instructions according to callgrind, but it still takes the same amount of time 23:03
so far i've accomplished both one step forward and two steps back, and one step forward and one step back
MasterDuke is not the best person to be doing this 23:04
timotimo you can decrease the amount of instructions, but reduce the number of instructions per cycle 23:06
23:06 pyrimidine joined
timotimo i *think* time -v could display that 23:07
aha, perf can give you an IPC measurement
perf stat -B dd if=/dev/zero of=/dev/null count=1000000
[...]
1,403,561,257 instructions # 0.679 IPC (scaled from 50.23%)
2,066,201,729 cycles # 2160.227 M/sec (scaled from 66.67%)
^- there you can see it 23:08
MasterDuke: you think this can help you?
MasterDuke timotimo: cool 23:11
timotimo tbh i don't know what this "scaled from" thing is about 23:12
MasterDuke my output of perf stat -B looks kind of different 23:13
what os are you on?
timotimo perf.wiki.kernel.org/index.php/Tutorial 23:14
i copy-pasted it from here
254,043,038 cycles:u # 2.641 GHz
416,806,930 instructions:u # 1.64 insn per cycle
this is what i get locally
the :u means it measured at user-level rather than kernel-level, i believe
MasterDuke 2,173,434,367 instructions:u # 1.73 insn per cycle
the IPC doesn't seem terribly different between my two versions, but i guess even a small change can add up 23:15
afk for a bit
timotimo don't have a clue ;) 23:16
perf record -e cache-misses gives something entirely unsurprising 23:32
7.6% in MVM_serialization_read_int is the highest bidder
followed closely by 6.8% in MVM_gc_gen2_allocate
and 6.13% in MVM_bytecode_unpack 23:33
oooh neat 23:34
perf stat has a -r flag that makes it run the same command multiple times and give you stats about the values it outputs
23:45 ggoebel joined
Geth arVM/line_based_coverage_pr: a66e2475c5 | (Timo Paulssen)++ | 16 files
Merge the line based coverage functionality.
 23:47
samcv MasterDuke, curious about what you changed to get a few less instructions 23:49
Geth arVM: timo++ created pull request #512:
Line based coverage pr
23:49 pyrimidine joined
timotimo how's the roadmap towards putting the compressed list of names into moarvm master branch? 23:50
23:50 pyrimidi_ joined
timotimo will it go in as a part of a complete ucd2c.pl rewrite? 23:50
samcv uhm if people want it i can try and de it before 23:51
but it was going to go in as part of the rewrite, but we can do it sooner, and phase in the sections, which may be smart
or at least have it in another branch at first 23:54
timotimo i don't know if it'd be a good idea. might be wasted effort 23:56
IMO either way would be totally fine
samcv it wouldn't be the hardest thing to do 23:57
so i think it may be worth doing
timotimo optimize for fun :)
samcv easier than the other parts

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!