00:47 geekosaur joined 00:48 geekosaur joined
japhb Given the number of times this year we've discovered a lot optimization, it almost seems like we ought to have a tool that builds new releases, profiles them doing standard things like the read/write a million lines or compile the setting benchmarks, 01:11
samcv good *
so guys i'm thinking about adding an op to let you get the columns and rows of the terminal 01:12
japhb and then messages #perl6-dev if the order of routines in the top 20 inclusive and exclusive most expensive routines changes.
samcv but i'm wondering. do we want it to be one op that returns an array?
japhb To catch places that we either lose or gain a significant optimization.
samcv japhb, that sounds like a good idea
japhb samcv: It doesn't need to be a fast op. Getting size of terminal is something you only need to do on TUI startup or on SIGWINCH 01:13
(If that matters to your thinking)
samcv but it can be resized
japhb samcv: That's SIGWINCH
(WINdow CHange)
samcv well that would require us catching that signal? 01:14
japhb samcv: That can be done in user space, no problem. The op would just avoid having to call out to `tput` twice -- or parse terminfo.
samcv well i mean we can use ioctl 01:15
on the filehandle
are you saying i shouldn't add this to moarvm?
geekosaur it's more a nativecall thing, I'd think 01:16
also consider that you have to do something completely different on Windows...
samcv well that's what #ifdefs are for
that's one reason i think having it in moarvm might be good
so rakudo doesn't have to worry about platforms
japhb samcv: We already handle termios in module space, I don't know that we need each nqp VM to do this for us. 01:17
samcv hmm
japhb Certainly, I'm not the arbiter of moarvm, it just seems like premature optimization.
samcv hmm 01:19
japhb For Terminal::Print, I'd *much* rather have faster string and I/O from moarvm than a special case for getting window size.
samcv ok good to know your thoughts though
japhb *string and I/O ops
samcv well it's not a special case. it'd just let you request the terminal size
it wouldn't affect any of the other ops
japhb shrugs
Like I said, not the arbiter of this codebase. :-) 01:20
samcv heh still glad you spoke up
japhb, does termios work for windows? 01:24
probably not?
japhb samcv: Actually, since you appear in the mood to do something different: There are two features that I really did want from MoarVM. 1. Uni input (instead of Str or Buf, so being able to read codepoints without waiting for combiners) 2. A fast way to determine the wcwidth of any character or sequence (so not just knowing about FullWidth and HalfWidth forms, but also knowing that several things joined by ZWJ can be just 1-2 width)
samcv: I would think that would only work under the Ubuntu subsystem in Win 10. 01:25
samcv yeah
geekosaur wcwidth is something of a problem
japhb geekosaur: Boy howdy.
samcv well
geekosaur and no, termios is not going to work on native Windows. I don't think you can even resize a text window normally
japhb Too much of a problem to do fast on thousands of screen cells at a time. 01:26
geekosaur arguably wcwidth is only determinable per font+output device combo
japhb geekosaur: Traditional wcwidth would be meaningless on anything but "monospace" fonts, but certainly you have the real-world problem of terminals that do font substitution for missing glyphs. 01:27
geekosaur yep
japhb The C library call just gives up on a great many sequences. Anything with a control character in it, for instance. 01:28
But that's a detail (escape stripping) that I can manage in a higher-level library. 01:29
samcv m: sub thing (Str $thing) { $thing.combĀ».uniprop('East_Asian_Width').grep({ .substr-eq( 'W'|'F')}).elems + $thing.chars }; say thing("ļ½ˆļ½…ļ½Œļ½Œļ½blah?AĆ”\c[united states]") 01:32
camelia 19
samcv this is approximate. counting full or wide as 2 and all others as 1
and not counting multiple codepoints within a grapheme 01:33
i mean it'd be way cheaper to do that inside moarvm but i don't think it would be a good idea 01:35
japhb samcv: Right, but it doesn't handle emoji sequences correctly, neh? 01:39
samcv well it does if your display doesn't fallback to multiple codepoints
japhb Hmmm
samcv though if you wanted to be technical. with a variation selector after the emoji it would always display that way. and then it wouldn't account for that 01:40
japhb What about if a string has non-breaking space, zwj that doesn't actually join things, etc.?
Sorry, the non-breaking non-space thing, I forget the name. 01:41
samcv NBSP non breaking space
japhb u: breaking
unicodable6 japhb, U+2011 NON-BREAKING HYPHEN [Pd] (ā€‘)
samcv i mean you want to calculate how long the line is? or where you can break it? 01:42
those are two different things 01:53
japhb FEFF, ZERO WIDTH NO-BREAK SPACE
Should be wcwidth = 0
200B, 200C, 200D, FEFF I guess
samcv i guess you could special case those?
japhb samcv: As far as were to break it, that would be valuable too I suppose.
samcv well there's the "Line_Break" property
japhb samcv: Right, but as soon as you special-case any particular characters, you're back doing loops in user space, and that's a lot slower.
samcv agreed
01:55 ilbot3 joined
samcv system filehandle 01:55
and we can check if the filehandle is a tty or not as well using moarvm 01:56
japhb samcv: You can get that from user space.
samcv well i never said you couldn't
geekosaur that to me just says filehandles, and other "system" objects, should have a way to attach user data that doesn't require monkey-patching
japhb samcv: See github.com/ab5tract/Terminal-Print...wInput.pm6
geekosaur like a hash or stash 01:57
japhb (Lines 29-35 are why I want Uni input; lines 13-20 are checking tty and handling raw fd)
samcv i mean termios uses nativecall. so it's essentially platform specific code 01:58
japhb And fwiw, your proposed screen size op would replace github.com/ab5tract/Terminal-Print...s.pm6#L102 01:59
02:43 TimToady joined
MasterDuke samcv: what would be an example of joining some strings where concat would not be stable? 03:26
samcv anything that combines 03:35
or if the canonical combining class of the right one is lower than the left one 03:37
CCC has to happen lowest to highest for combiniers
MasterDuke heh. i don't know combiners. do you have a quick example handy?
Geth MoarVM: MasterDuke17++ created pull request #705:
Just copy strands in MVM_string_join if able		 04:29
04:44 geekosaur joined 07:18 domidumont joined 08:06 leont joined 08:11 domidumont joined
samcv "Ć”\c[combining caron]".NFD.list.Ā».uniprop('Canonical_Combining_Class').say 08:20
m: "Ć”\c[combining caron]".NFD.list.Ā».uniprop('Canonical_Combining_Class').say
camelia (0 230 230)
samcv m: "Ć”\c[combining caron]".NFD.list.Ā».uniname.say 08:21
camelia (LATIN SMALL LETTER A COMBINING ACUTE ACCENT COMBINING CARON)
samcv like COMBINING ACUTE ACCENT, and COMBINING CARON. they both happen to have the same CCC so won't be reordered
but i could probbaly find other combiners that have different CCC that you can't change the glyph by changing the order of the combiners
10:43 domidumont joined 10:49 geekosaur joined 11:52 geekosaur joined 13:02 geekosaur joined
dogbert11 it's silent around here 13:36
dogbert11 is still contemplating the mysteries off callgrind 13:40
*of
ramble mode on, yesterday I callgrinded a program with the current version and 2017.07, with and without spesh, the results were as follows 13:42
MVM_SPESH_DISABLE=1 WITH SPESH
2017.07 20,325,247,133 Ir 7,861,290,267 Ir
current 18,419,032,475 Ir 16,440,182,184 Ir
MasterDuke figure something out? 13:43
dogbert11 turns out that there's something fishy going on here, I reran the 'WITH SPESH* tests three more times and here are the results 13:44
2017.07 7,861,290,267 Ir, 7,861,290,265 Ir, 7,861,290,267 Ir quite consistent I'd say
current 9,933,190,170 Ir, 17,370,345,458 Ir, 11,768,107,356 Ir no consistency at all 13:45
why are the results from the current version so different? 13:46
MasterDuke did you have MVM_SPESH_BLOCKING=1 set?
dogbert11 no, should I
dogbert11 tries that ... 13:47
MasterDuke yeah, that makes it deterministic since it's threaded now
timotimo if you set an MVM_SPESH_LOG you can figure out how much work it does in each case
dogbert11 this will take a little more time but it's beginning to look consistent now 13:51
current with MVM_SPESH_BLOCKING=1 9,483,385,317 Ir, 9,483,385,662 Ir, 9,483,595,755 Ir good consistency 13:52
timotimo aye
callgrind basically randomizes when the only running thread switches over
dogbert11 so to get good results I have to use that flag then 13:53
timotimo right
with SPESH_BLOCKING, it'll immediately let the spesh thread do its work once a log is filled with data 13:54
dogbert11 so the remaining question then is why is the program ~15% slower compared to 2017.07
timotimo the logging itself is deterministic, but it only has an effect once the spesh thread runs again
MasterDuke
.oO(if only we had a nice UI to view and diff spesh logs...)
 13:55
timotimo and since the optimized versions of routines get installed once the spesh thread is finished, it can have strong effects on the total time spent
MasterDuke: it's not in my grant application any more ;( 13:56
though i also want to have it just in general
perhaps it'll happen in between work on the other UIs
dogbert11 I see that the most called routine is, no surprise I guess, MVM_interp_run in bothe version, i.e. 2017.07 and current
timotimo you're probably looking at "instructions executed inside", not "calls to" 13:57
MasterDuke heh. well the faster you finish up the first grant the faster you can submit another for that. get working! no sleeping! no eating! just coding!
timotimo yeah, starving timo does the fastest work
MasterDuke eternal crunch mode always produces the best code
dogbert11 in current MoarVM the function MVM_multi_cache_find_callsite_args is in second place
timotimo what functions call it the most? 13:58
dogbert11 timotimo: here's a gist gist.github.com/dogbert17/87247c92...950f32efa2 14:00
timotimo that doesn't tell me what called it :) 14:02
you can figure that out more easily with kcachegrind
because then you can select that function in the left list and then look at "callers" or "all callers" on the right
MasterDuke ot, but would anyone object to renaming MVM_fixed_size_alloc_zeroed to MVM_fixed_size_calloc? 14:04
dogbert11 sry, misread your question, doing what you suggest points to a function called MVM_frame_find_invokee_multi_ok
timotimo OK, would be interesting to see one more level there 14:05
you can see that more easily in the graph view perhaps
though it's most likely just called from interp.c
dogbert11 MVM_interp_run 14:06
timotimo OK, not terribly surprising, then. also more or less a dead-end :) 14:07
dogbert11 it was worth a shot :)
timotimo hm, so, putting a printf into spesh's getlexperinvtype gives me a lot of successes 14:09
dogbert11 please elaborate 14:10
timotimo so one reason we're getting a lot of MVM_string_equals could be from late-bound lookup of $?CLASS in all manner of places in the regex engine 14:11
when compiling the core setting, i mean
there's an optimization in spesh that can turn that into just a constant 14:13
i thought perhaps that optimization got damaged somehow in the time between the releases
dogbert11 and ...
timotimo it does seem to trigger and succeed often 14:14
dogbert11 does that mean it's ok? 14:15
timotimo well, something's still strange 14:20
15:36 domidumont joined 17:02 AlexDaniel joined 19:43 geekosaur joined 20:43 leont joined 21:10 leont joined 21:59 geekosaur joined 22:33 geekosaur joined 23:41 timo 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!