Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-10-08

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

All times shown according to UTC.

Time Nick Message
02:11 tokuhirom joined #moarvm
03:48 tokuhirom joined #moarvm
04:42 vendethiel joined #moarvm
05:58 FROGGS[mobile] joined #moarvm
06:10 FROGGS joined #moarvm
06:38 Ven joined #moarvm
06:55 zakharyas joined #moarvm
07:03 domidumont joined #moarvm
08:14 Ven joined #moarvm
08:27 kjs_ joined #moarvm
09:01 kjs_ joined #moarvm
09:33 jnthn lizmat: yes, they look fine; thanks
10:07 jnthn m: say uniname(0x6E)
10:07 camelia rakudo-moar f3aace: OUTPUT«LATIN SMALL LETTER N␤»
10:07 jnthn m: say uniname(0x2BC)
10:07 camelia rakudo-moar f3aace: OUTPUT«MODIFIER LETTER APOSTROPHE␤»
10:07 jnthn m: say chr(0x2BC)
10:07 camelia rakudo-moar f3aace: OUTPUT«ʼ␤»
10:08 jnthn m: say chr(0x149)
10:08 camelia rakudo-moar f3aace: OUTPUT«ʼn␤»
10:10 jnthn m: say chr(0x1F0); say uniname(0x30C)
10:10 camelia rakudo-moar f3aace: OUTPUT«ǰ␤COMBINING CARON␤»
10:12 jnthn m: say Uni.new(0x6A, 0x30C).NFC
10:12 camelia rakudo-moar f3aace: OUTPUT«NFC:0x<01f0>␤»
10:15 jnthn m: say Uni.new(0x03B9, 0x0308, 0x0301).NFC
10:15 camelia rakudo-moar f3aace: OUTPUT«NFC:0x<0390>␤»
10:15 jnthn m: say Uni.new(0x03B9, 0x0308, 0x0301).Str
10:15 camelia rakudo-moar f3aace: OUTPUT«ΐ␤»
10:46 Ven joined #moarvm
11:07 dalek MoarVM: 12c5262 | jnthn++ | src/strings/normalize. (2 files):
11:07 dalek MoarVM: Add normalizer API to push many codes to buffer.
11:07 dalek MoarVM:
11:07 dalek MoarVM: To ease implementing post-case-change renormalization.
11:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/12c52629c4
11:07 dalek MoarVM: 741cb9c | jnthn++ | src/strings/ops.c:
11:07 dalek MoarVM: Enforce NFG over growing case folds.
11:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/741cb9c3ea
11:52 brrt joined #moarvm
11:57 brrt good * #moarvm
11:59 timotimo heyo brrt
12:01 brrt i have established, among other things, that our dear frame at the very least does not return from the JIT code with its entry label NULLed
12:01 brrt (the EXPR frame, that is)
12:02 brrt consequently, it must be NULLed somewhere else
12:02 brrt or, I must have made a mistake in my gdb
12:03 timotimo it's a very curious thing to happen in any case!
12:03 brrt setting a breakpoint on jit field entry is actually extremely expensive
12:04 brrt s/field entry/leaving code/
12:04 timotimo maybe you can find a conditional you can append to the breakpoint that'll make it fire only when we've reached the right frame?
12:04 * brrt wonders, nay, is sure that adding a sequence number to JITted frames will make debugging easier
12:04 brrt yeah, that's what i do
12:05 brrt but it's probably significantly cheaper to create the branch in code and have the breakpoint there
12:05 brrt otherwise it breakpoints all the time, has to check the condition, and continue
12:07 Ven joined #moarvm
12:13 Ven joined #moarvm
12:31 jnthn brrt: One other thing to check: does a deopt happen at any point?
12:31 jnthn (Between the entering of the frame with the inlined lexical and the failed lookup)
12:31 jnthn Bit of a long shot though as we shoulda found the thing in the uninlined frame...
12:32 brrt not sure jnthn, i'll check that too
12:32 timotimo we could just turn deopt off via an env var! /s
12:33 brrt great idea :-P
12:34 jnthn Given that deopt stops us going ahead and reading bogus memory...maybe not :P
12:34 jnthn But there *are* deopt logging things
12:34 jnthn Which could be turned on by env var
12:36 brrt oh, that is probably an excellent idea
12:37 brrt the dynvar log was also very helpful :-)
12:37 timotimo mhm
12:50 brrt deopt is actually pretty unlikely, since i'd have to explain why the first 200 or so iterations we don't have deopt, and in the last one we do
12:53 brrt i still suspect that something is compiled underneath the old frame, and that the jit label is reinitialized somehow
12:56 timotimo we don't have to deopt if we're not opted in the first place
12:56 timotimo remember that spesh has multiple candidates per call site
13:06 brrt aye, that is true
13:13 Ven joined #moarvm
13:48 synbot6 joined #moarvm
13:51 Ven joined #moarvm
14:52 domidumont joined #moarvm
14:55 domidumont joined #moarvm
15:16 Ven joined #moarvm
15:24 Ven joined #moarvm
15:48 flussence I decided to mess around with callgrind... a full quarter of the CORE.setting compile is spent in MVM_sc_find_object_idx (twice as much as MVM_interp_run!)
15:51 jnthn o.O
15:51 jnthn That's...*really* odd, we're meant to be annotating the objects with that index so it's O(1)...
15:51 jnthn flussence++
15:54 flussence just ooc, I tried making it iterate over that array in the opposite direction. That shaves a few tenths of a second off most of the compile stages, but doubles the MAST part...
15:57 timotimo sort and binary search?
16:00 Peter_R joined #moarvm
16:01 jnthn But we should only be searching it as the "fallback" case
16:04 Ven joined #moarvm
16:05 timotimo well spotted in any case
16:05 flussence oh, MVM_get_idx_in_sc is inlined, so it doesn't show counts for that, but that hardly looks expensive to begin with.
16:07 timotimo is that run time spent in there? could be that it spends a lot of cycles there, but has hardly any cache traffic?
16:07 flussence that's exclusive-time in cycles (52 billion out of 211 billion)
16:08 flussence good question though, how big *is* that array it's scanning?
16:09 timotimo cachegrind would be able to give you more idata on that, i believe
16:09 timotimo i mean
16:09 timotimo on how it behaves in relation to the cache
16:10 jnthn flussence: It grows over the setting compile, it reaches over 64,000 items
16:10 jnthn Which is why we're meant to also cache the index on objects, but apparently that's not working as it should
16:11 flussence 64k sounds like it should fit into my CPU, but I'll re-run with --cache-sim=yes anyway. Might take a while...
16:12 jnthn We still shouldn't be scanning it though
16:13 timotimo i *think* --cache-sim=yes only has to simulate the L3 cache - or something like that?
16:26 tokuhirom joined #moarvm
17:10 FROGGS[mobile] joined #moarvm
17:22 leont joined #moarvm
17:28 cygx joined #moarvm
17:28 cygx o/
17:28 nwc10 \o
17:30 timotimo sup cygx :)
17:31 cygx Well, I looked at what I did back in February to see if there's anything that might be useful to push upstream
17:31 cygx the JVM open modes have already been merged
17:31 cygx I've 2 other branches of more questionable usefullness
17:31 cygx https://github.com/MoarVM/MoarVM/compare/master...cygx:virtualfiles and https://github.com/MoarVM/MoarVM/compare/master...cygx:embedapi
17:32 cygx the former allows to register virtual bytecode files, which is how I created a single-file NQP executable, embedding the .moarvm files
17:33 cygx the latter is a vtable-based API, useful eg for a MoarVM plugin
17:42 FROGGS joined #moarvm
17:45 flussence that run with --cache-sim *finally* finished... and it shows pretty much nothing in terms of misses. /me shrugs
17:45 timotimo oh
17:45 timotimo no misses! that's perfect! ;)
17:46 flussence well, not zero, but around 0-5%...
17:47 timotimo that's surprisingly good
17:47 timotimo i mean, the whole program's gotta go into cache via memory at least once
17:47 timotimo well, all the parts we run anyway
17:49 flussence for all the time MVM_sc_find_object_idx spends, only 2% of that is cache misses, 20% is cache hits, and I guess the remainder is it looping over that list
17:52 FROGGS jnthn: about serialization: https://gist.github.com/FROGGS/cf2a24d89361e760e7bc
18:20 dalek joined #moarvm
18:21 FROGGS[mobile] joined #moarvm
18:25 vendethiel joined #moarvm
18:48 dalek joined #moarvm
19:20 dalek MoarVM: 3b09c21 | jnthn++ | tools/ucd2c.pl:
19:20 dalek MoarVM: Add SpecialCasing to Unicode DB generation script.
19:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3b09c21a90
19:20 dalek MoarVM: 0981b5e | jnthn++ | src/strings/unicode_ (2 files):
19:20 dalek MoarVM: Update Unicode database with SpecialCasing.
19:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0981b5e4c5
19:26 dalek MoarVM: eea3ed8 | jnthn++ | src/strings/unicode_ops.c:
19:26 dalek MoarVM: First pass at handling special casings.
19:26 dalek MoarVM:
19:26 dalek MoarVM: Covers most of the cases, though some further work will be needed to
19:26 dalek MoarVM: properly handle these in combination with synthetic codepoints.
19:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/eea3ed82d2
19:26 leont o/
19:26 FROGGS hi leont
19:27 jnthn The synthetics aside, there's only that darned final sigma greek thing to deal with
19:31 timotimo is the "final sigma" the only letter in greek that does that?
19:31 jnthn Yeah, but it *seems* that to implement it you have to look ahead one char to see if it's the "end of the word"
19:31 * jnthn is struggling to find a rigourous definition of what that means
19:31 timotimo ugh. and that's always unhappy when we're not sure if any more data is going to come in
19:32 jnthn Well, this is for uc/tc/lc etc. so we'll just have to go on the string you give us
19:37 jnthn omg, it seems you maybe have to look behind also
19:39 timotimo urgh
19:39 timotimo but why
19:40 jnthn Because the rule only applies if it's the final letter in the word, but not the only letter in the word
19:40 timotimo but wait ... this is only about changing case on a string we already have, right?
19:40 jnthn http://knight666.com/blog/the-curious-case-of-the-greek-final-sigma/ is helpful
19:40 jnthn Right
19:40 jnthn It's not a probably to implement the lookaround
19:40 timotimo OK, so not necessarily a problem with regards to data coming through a tcp connection or something
19:40 jnthn Just want to get it right
19:41 timotimo it's also a plus if we don't take a performance hit for every single string we case-change just because there could be a sigma somewhere
19:41 jnthn Aha. That uses the GeneralCategory of Letter.
19:41 jnthn And then start/end of string bound checks
19:42 jnthn And I was thinking \w and then the latter, but Letter is righter
19:42 jnthn timotimo: I'll later special-case ASCII to avoid the property lookups completely
19:44 jnthn Anyway, think I did enough for today, but will deal with final sigma and some tests tomorrow :)
19:52 timotimo \o/
19:54 timotimo food is done!
20:00 [Coke] jnthn++
20:03 lizmat jnthn++ indeed :-)
20:23 cygx left #moarvm
20:28 tokuhirom joined #moarvm
21:30 LLamaRider joined #moarvm
22:24 _itz_ joined #moarvm
23:19 tokuhirom joined #moarvm

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