00:44 `_^gk`_^1wm`_^ joined 01:01 pyrimidine joined 01:26 pyrimidine joined 02:48 ilbot3 joined 02:51 pyrimidine joined 02:54 pyrimidi_ joined 03:57 pyrimidine joined 04:11 zakharyas joined
MasterDuke samcv: re github.com/samcv/UCD/blob/master/U...L808-L857, a quick test on my machine shows that Int hash keys were slightly faster 04:34
m: my %h; for ^100_000 { %h{$_} = 1; }; say %h.keys.sort(*.Int).elems; say now - INIT now
camelia rakudo-moar aac9ef: OUTPUT«100000␤3.63051851␤»
MasterDuke m: my %h{Int}; for ^100_000 { %h{$_} = 1; }; say %h.keys.sort.elems; say now - INIT now
camelia rakudo-moar aac9ef: OUTPUT«100000␤2.89883963␤»
04:50 pyrimidine joined 04:55 pyrimidine joined
Geth MoarVM: MasterDuke17++ created pull request #537:
Del unused var, don't call MVM_string_graphs twice		 05:07
05:13 pyrimidine joined 06:59 pyrimidine joined
samcv MasterDuke, how does that make any sense... it has to look up them in other hashes 08:17
so it'd have to convert back to a string. or do you just mean the sort operation
the sort operation is fairly fast. the issue is all the rest
it would slow it down a lot to do that, because it'd slow down the rest of the things in the code 08:18
timotimo, it's been moved to its own sub now, just pushed 08:23
github.com/samcv/UCD/blob/master/U...en.p6#L755
at least it doesn't take like 8 minutes anymore at least 08:24
or probably much longer than that, not sure
08:36 agentzh joined 09:03 pyrimidine joined 09:16 zakharyas joined 10:04 pyrimidine joined 10:17 pyrimidine joined 11:00 Ven joined 11:07 agentzh joined 11:17 pyrimidine joined 11:41 zakharyas joined 12:05 zakharyas joined 12:22 pyrimidine joined 12:34 brrt joined
brrt .tell samcv that yes, to correctly step in a C-language program, you need to compile with --optimize=0 12:34
yoleaux2 brrt: I'll pass your message to samcv.
samcv but that defaults the point :P 12:35
yoleaux2 12:34Z <brrt> samcv: that yes, to correctly step in a C-language program, you need to compile with --optimize=0
brrt why?
samcv since i really only care about the final compiled stuff
brrt if that's what you want, use si to step individual instructions
samcv if an ugly if else chain with tons of -= is faster then that's faster (turned out to be 20% slower than linear search)
ok thanks 12:36
maybe more than 20% slower, forget
brrt i'm typically setting display /10i $rip
samcv ?
brrt if i'm stepping through machine code
but to be fair, i try to avoid that nowadays
takes a long time and provides very little insight
timotimo i should steal that display line 12:38
brrt and interpreting register values is .. nearly impossible
timotimo if i ever need to si
if i ever need to "si" the machine code
brrt it is from memory, so may not be 100%correct
samcv k
i am off to bed. night all
brrt sleep well
12:38 ggoebel joined
timotimo nite sam 12:39
oh
i still need to write the "from codepoint to name" code, right?
samcv yes :P
timotimo right
oh, look, a squirrel
timotimo chases
samcv for some reason it gets off track but i'm not sure if it's the code or if it's something else being off 12:40
will need to write some testing harness for it so i can check at what point it messes up 12:42
but it's like thousands of cp's in at least
timotimo what's "it" here? the stuff you've been working on in C code with if/elseif vs the table, yes? 12:43
samcv oh no, talking about the names here
but also need to do the same for the bitfield file
going to be outlining the project plan tomorrow, so I think that's a good partial way point that needs to be done before adapting the code to the mvm base and other thing sthat need to happen before integration 12:44
gotta write out the 'inch stones' as the pod template calls them
timotimo mhm
i wonder if we can have any benefit from the many 0 fields in the bitfield rows at all
samcv night though o/
timotimo yeah, night!
samcv the many 0 fields? 12:45
timotimo i seem to recall seeing many 0 entries
samcv well those are mostly boolean. the size of the bitfield is really not that big
timotimo oh!
samcv they only take 1 bit width
timotimo well, that makes a big difference, then :)
samcv :)
may eventually pack them into bigger integers but that would be after some other things happen first 12:46
but at least as far as i've tested it up several hundred cp's the bitfield works perfectly
and grabbing enum values etc
pretty happy with progress so far
night! 12:47
13:13 pyrimidine joined 13:18 pyrimidine joined 13:40 agentzh joined 14:20 pyrimidine joined 14:40 Geth joined 14:46 SmokeMachine joined 14:52 BinGOs joined 15:03 pyrimidine joined 15:19 agentzh joined 16:03 pyrimidine joined 16:08 brrt joined 16:41 pyrimidine joined 17:00 pyrimidine joined 18:33 ggoebel joined 19:21 agentzh joined
samcv timotimo, you around 19:29
timotimo yup 19:32
samcv ok so i put that sub that makes/dedups the bitfield rows in its own sub 19:33
timotimo yup, i saw
samcv what are the steps needed to check on speshalization or JITing?
timotimo i started a perf run and then promptly forgot about it
samcv heh 19:34
timotimo set the env vars MVM_SPESH_LOG and MVM_JIT_LOG to a filename
you ought to see the name of the sub show up there 19:35
in the spesh log you'll see three stages for each instance of a given candidate for a given frame to show up in 19:37
"inserting log instructions" (oslt) gives you the raw bytecode in its "before" and tells you where it grabs registers for closer inspection in the "after" section 19:38
there's tools/graph_spesh.p6 or so that'll eat a single frame copy-pasted into its stdin and spit out a .dot that you can put into the "dot" command 19:40
like graph spesh | dot -Tsvg > speshgraph.svg
or -Tpng
actually, -Tx11 is best, because you can scroll around in it 19:41
samcv hmm k 19:45
timotimo gonna go pick up a bit of food for me, my friend, and our cats 19:53
well, the food isn't meant for the cats, but they end up getting their will one way or the other
samcv kk 19:54
i'll brb too
timotimo maybe you can get me inspired to finally build the cp-to-name code …
IOninja Was there any conversation vis-á-vis merging the coverage branch into master? 19:56
Like what's stopping it from occuring.
I wanna use it, but don't know how to unbust it when it gets busted by new stuff in master making master unmergeable 19:58
20:19 agentzh joined 20:27 agentzh joined
timotimo someone has to review it 20:57
21:26 agentzh joined
jnthn did leave a comment on it 21:30
I forgot that I wrote :)
timotimo oh? i think i didn't even notice that :s 21:49
21:55 ggoebel joined
samcv hmm i don't see dedupe-rows in the spesh log or the jit log 21:56
kate is saying both contain invalid UTF-8 characters :P 21:57
do we utf-8 encode it before writing?
weird 21:58
jnthn Did you try --profile also? That shows some stats on spesh/JIT 22:18
samcv no 22:21
jnthn In fact, half of the reason I wrote the profiler was to understand how those two behaved on code ;)
And to try and give others insight into that, of course :) 22:22
samcv can i look at how spesh/jit perform on a single sub?
jnthn On the routines tab, it should show how many calls were interpreted, spesh'd, and JIT'd.
(In the --profile output, that is) 22:23
samcv i remember in this section it was JIT'd a lot when it was in pure perl6
writing it in nqp made it orders of magnitude faster, but would still like it faster than 70s
jnthn In the next iteration of spesh, I'd like to get it to be able to explain more of the stuff it goes
samcv to do that section
jnthn *it does
samcv running profile now 22:24
jnthn Suspect it'll be late spring before I dig into that though
jnthn will be doing Perl 6 stuffs tomorrow o/ 22:26
22:37 hoelzro_ joined 22:43 BinGOs joined 22:46 mst joined 22:47 geekosaur joined 22:52 BinGOs joined 22:58 leedo joined
samcv so it's totally red, the spesh/jit bar 23:23
timotimo oh crap 23:24
samcv is that bad
timotimo it means it didn't even go through the spesh at all 23:25
what other things are all red?
samcv push is mostly red 23:27
90% red
one other push is all red
jnthn Sleep time for me.
timotimo the red things, do they have few invocations?
samcv some anon things are all red
jnthn Will be interested to backlog this tomorrow :)
'night
samcv night jnthn
uh the first push has 419657 23:28
and 90% red
tiny bit of yellow
timotimo hmm ... i think if you have interpolation in calls and such that'll usually prevent spesh? 23:29
samcv post circumfix { } looks like 40% red, 30% yellow and 15% green or something
timotimo but other than that ... not being called often enough will prevent it
samcv like string interpolation?
timotimo no
only argument interpolation
string interpolation gets compiled to a bunch of ~ calls 23:30
samcv map is half red 868842 entries
timotimo like flattening with |@foo or |%bar
samcv ah ok
timotimo map itself hardly does anything
can you sort by exclusive time and look at what's up top?
samcv SETTING::src/core/Any-iterable-methods.pm:454
at 20%
idk if that's accurate? 23:31
timotimo sink-all, ok
samcv i mean dedupe rows has 40% inclusive time
0% exclusive 23:32
timotimo that's not the one you pulled out, is it?
samcv that is
timotimo oh, OK
so a good potential win
samcv and it's basically all nqp
timotimo does the "call graph" tab show anything much?
also, if it has 0% exclusive time that'd mean it does all of its work via other subs 23:33
is that the case at all?
samcv it is just nqp
and those don't seem to show up
doesn't do any work through other subs. that's the nqp section i pulled out
23:33 agentzh joined
timotimo right, nqp stuff aren't calls to subs or something 23:33
samcv uh callgraph for dedupe-rows 23:35
timotimo it surprises me that it could even reach 0% exclusive time. could be calculating stuff wrong perhaps?
samcv shows 83% in sink
timotimo OK, so there's a loop in there?
can you tell what file/line the sink is from?
samcv yeah
timotimo as we have like 100 methods "sink"
maybe 500
samcv SETTING::src/core/Seq.pm:183
that shows all green 23:36
timotimo OK, that's mostly "please do this for loop now k?"
samcv and only one call
yeah
timotimo it should have hardly any time spent iside itself and do all of its work via the block that you have in your code fro the for loop
samcv well it's all nqp
and that's why i don't think it shows up
timotimo weird. it shouldn't prevent it in any case 23:37
samcv want to see the profile?
timotimo yeah sure 23:38
samcv cry.nu/profile-1487111206.48787.html
timotimo oh jesus 23:39
how big is it btw?
samcv 3.5 MB
timotimo OK
that's passable
does it spend a lot of time in GC in total?
oh! 23:40
hahaha
samcv hmm?
timotimo i still had the build where the nursery is tiny
so in my profile it shows ~60% in just the hash gc_mark function
samcv lol
timotimo you have 15% in GC which isn't good, but it's not out of the ordinary 23:41
600ms full collection time is impressive
21% of time spent inside sorting stuff 23:43
have you considered doing something to make that not as bad?
samcv possibly 23:44
i could do something for that
timotimo it might not go away fully, but 20% is a juicy target either way 23:47
what's line 766 about? from the ucd-gen script ...
ah, inside dedupe-rows 23:48
that's good, though
that one's fully jitted
you can find it in the speshlog by searching for "UCD-gen.p6:766"
samcv ok i see it 23:49
the whole function is JIT'd?
timotimo well, that's only the innermost for-looped block 23:50
the *outer* for-looped block is also 100% jitted 23:51
that's the entry with line number 763
say ... can you turn one of the hashes into an array perhaps? are these hashes keyed by int? 23:53
samcv no 23:54
i already removed that before
they'ed keyed with strings
aside from the %points hash, which i can't make an array because there's gaps
23:55 Geth joined
timotimo the gaps are huge? 23:55
i'm not very happy that the allocations tab broke :(
samcv some are 23:56
timotimo if it were a native int or num array, then we could rely on the kernel to just leave the gaps out of memory 23:57
but you probably have objects in there, which means the GC has to go through on every major collection

Powered by Cro and the Raku® Programming Language.

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

Thank you!