00:27 agentzh joined 00:41 pyrimidine joined
timotimo rakudo is currently bad at inlining operators involving native types, MasterDuke 00:45
maybe that's what you're seeing; can you try with non-natives instead?
MasterDuke oh weird, not specifying any types was faster 01:20
and had 1m fewer call frames
was 100% speshed vs 50 % speshed, 50% jitted for natives 01:21
timotimo fewer call frames would support my hypothesis that it's about natives preventing inlining of operators 01:22
how much faster? and what's the comparison between nqp and rakudo-without-natives? 01:23
MasterDuke nqp was 1607ms, rakudo w/ native was 3007ms, rakudo w/ no types was 2815ms 01:24
timotimo still a bad performance hit
did you use := in perl6 after you threw out the types? 01:25
MasterDuke rerunning the non-type with $l := nqp::readlinefs() was 2720ms 01:26
only ran them all once, so there could be some noise i'm not averaging out 01:27
afk for a bit
timotimo right 01:29
MasterDuke make the rakudo version into this; 'use nqp; sub a() { nqp::stmts((my $f := nqp::open("small_compile.sql", "r")), (my $l), (my $s = 0), nqp::while(($l := nqp::readlinefh($f)), ++$s), $s) }; say(a())' 02:10
just made the sub body a nqp::stmts(). that dropped it to 2170ms 02:11
02:12 pyrimidine joined
MasterDuke timotimo: is it a rakudo, nqp, or moarvm problem that natives prevent inlining? 02:13
timotimo rakudo 02:16
and to a lesser extent moar
MasterDuke fwiw, the naive perl6 version: 'sub a() { my $s = 0; ++$s for "small_compile.sql".IO.lines; $s }; say(a())', was 100% jitted and took 4700ms 02:17
interestingly, a perf record/report of all version shows the same top two symbols (MVM_string_utf8_decodestream and find_separator.isra.6) 02:26
and they are the highest percentages by far, though the percent for each drops as the total runtime increases 02:27
which makes sense in a way. there is a certain fixed amount of time needed to read the file, and the higher level versions of my benchmark just add more and more overhead 02:28
though i think the time to read the file could/should be improved 02:30
02:38 agentzh joined 02:48 ilbot3 joined 05:25 pyrimidi_ joined 06:37 pyrimidine joined 07:11 brrt joined 07:22 domidumont joined 07:27 domidumont joined 07:35 domidumont joined 08:00 pyrimidine joined 08:30 brrt joined, TimToady joined
brrt .tell nine, no, we don't use that information currrently 08:33
yoleaux2 brrt: What kind of a name is "nine,"?!
27 Jan 2017 17:29Z <nine> brrt: so as we're talking about a JIT, do you actually have some information about runtime behavior accessible in the register allocator? I.e. does it have an idea how often loops may run?
brrt tell nine no we don't use that information currently
08:33 domidumont1 joined 08:36 zakharyas joined
nine brrt: a shame :) 08:37
brrt agreed
however, there's a reasonable reason for tht 08:38
which is that the expression JIT doesn't extend that far just yet
the expression JIT only works for basic blocks now
nine fair enough :) 08:39
brrt handling all the issues (especially surrounding throwing/catching) was considered too complicated
however
i'm intent on implementing a stack-walking functionality that can find the current entrypoint from the JIT bytecode 08:40
from that, we can easily find the labels to which that entrypoint belongs
and from that, we know exactly 'where we are' when throwing/catching
this should save us a store operation for every basic block, quite a saving 08:41
nine sounds good :) 08:42
brrt yeah. the cost is that we have to compile moarvm with frame pointers kept arround
that is a pesssimization
otherwise stack walking is not possible 08:43
the second bit is, we'd ultimately want to implement tracing for spesh 08:45
09:02 pyrimidine joined 09:23 pyrimidine joined 09:44 brrt joined
jnthn o/ #moarvm 10:16
brrt \o jnthn 10:17
10:26 pyrimidine joined 10:28 domidumont joined 11:45 brrt joined 12:35 brrt joined 14:33 hoelzro joined 14:43 avar joined 14:53 KDr2 joined 15:42 pyrimidine joined 16:05 brrt joined 16:16 pyrimidine joined 16:25 pyrimidine joined 16:44 agentzh joined 17:42 pyrimidine joined 17:45 zakharyas joined 17:48 FROGGS joined 17:52 pyrimidine joined 18:05 pyrimidine joined 18:15 nebuchadnezzar joined 18:26 agentzh joined 18:37 domidumont joined 19:31 agentzh joined 20:09 pyrimidine joined 20:15 pyrimidine joined 20:56 pyrimidine joined
samcv morning 21:10
lizmat samcv o/ 21:11
samcv: could you give a small description of what 3a774066d585062c52191e10 is about for the user ? 21:12
for the P6W :-)
samcv k 21:15
Samantha McVey has added the last of the Unicode named sequences[1], which are in addition to the Emoji sequences that had been added earlier. 21:20
Getting codepoints or sequences by name is also now case-insensitive, "\c[solidus]" / "\c[Grinning Face]" 😀.
A docs article has been added about using Unicode sequences [2]
[1] www.unicode.org/Public/UCD/latest/u...uences.txt
[2] docs.perl6.org/language/unicode
jnthn o/ samcv 21:21
samcv: Will look at your PR in the morning; ran out of brane for today
lizmat samcv: thanks! 21:23
samcv :) 21:26
thanks jnthn
this atom plugin is so nice, having all my subs and classes on the left bar to access 21:27
way easier to get around a 700 line file when all the subs are in a list in my editor i can click on and go to 21:28
21:45 agentzh joined 22:41 pyrimidine joined 23:47 pyrimidine 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!