[02:48] *** colomon joined [02:51] *** vendethiel joined [03:07] *** TimToady joined [05:14] *** vendethiel joined [06:21] *** Ven joined [06:51] *** vendethiel joined [06:55] *** brrt joined [06:55] \o [07:47] *** zakharyas joined [08:14] *** zakharyas joined [08:37] *** Ven joined [08:45] *** vendethiel joined [08:52] *** rurban joined [09:12] *** Ven joined [09:18] jnthn, i have a burning question [09:18] it seems to me that decont/assign are not, in fact, invokish at all [09:18] did this change sometime in the last year? [09:19] brrt: ETA jnthn ~ 20 mins [09:19] ah [09:19] brrt: decont and assign may invoke [09:19] See Proxy [09:20] but.... but... [09:20] ok [09:20] fair enough [09:20] and yeah, still doing errands... :) [09:20] back for real soon :) [09:20] ok, don't let me distract you then [09:20] :-) [09:27] you are completely correct, of course [09:28] how did i not see that [09:49] *** brrt joined [10:28] *** Ven joined [11:34] *** vendethiel joined [12:03] *** vendethiel joined [12:23] *** brrt joined [12:30] *** mj41 joined [13:03] *** travis-ci joined [13:03] MoarVM build passed. Paul Cochrane 'Destroy correct string decodestream [13:03] http://travis-ci.org/paultcochrane/MoarVM/builds/60829756 https://github.com/paultcochrane/MoarVM/compare/f3eb892b1882^...ba700a7283f2 [13:03] *** travis-ci left [13:20] MoarVM: 4ca886c | jnthn++ | src/strings/ops.c: [13:20] MoarVM: Remove fragile assumption about buffer size. [13:20] MoarVM: [13:20] MoarVM: Just fwrite the \n separately rather that relying on the UTF-8 encoder [13:20] MoarVM: allocating a little more than needed just for this one case. [13:20] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4ca886cbb8 [13:20] MoarVM: 1f9d843 | jnthn++ | src/strings/utf8.c: [13:20] MoarVM: Fix UTF-8 encoder to handle NFG. [13:20] MoarVM: [13:20] MoarVM: Also, now we have to resize a buffer anyway, start out with a lower [13:20] MoarVM: assumption. [13:20] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1f9d843584 [13:30] *** rurban joined [13:37] *** travis-ci joined [13:38] MoarVM build passed. Paul Cochrane 'Inititialise `operand_size` in MVM_bytecode_dump() [13:38] http://travis-ci.org/paultcochrane/MoarVM/builds/60833279 https://github.com/paultcochrane/MoarVM/compare/ce890e62355d^...b6702843743d [13:38] *** travis-ci left [13:41] jnthn: re 4ca886cbb8 , maybe 'utf8_encoded_length + 1' => utf8_encoded_length? [13:43] JimmyZ: hm, yes [14:01] MoarVM: 97835d6 | jnthn++ | src/strings/ops.c: [14:01] MoarVM: More robust NULL string checking. [14:01] MoarVM: [14:01] MoarVM: This should avoid a bunch of SEGVs arising from NULL strings getting [14:01] MoarVM: passed into things not expecting them. [14:01] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/97835d6f52 [14:01] MoarVM: 2c9398a | jnthn++ | src/ (2 files): [14:01] MoarVM: Ensure we get NULL-terminated strings if needed. [14:01] MoarVM: [14:01] MoarVM: We used to get them more by accident than by design, but that made us [14:01] MoarVM: do an unrequired memset in the UTF-8 encoder. Call the function that [14:01] MoarVM: demands a null-terminated string. [14:01] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2c9398a4a5 [14:01] MoarVM: 8880d61 | jnthn++ | src/strings/ops.c: [14:01] MoarVM: Fix off-by-one in recent change. [14:01] MoarVM: [14:01] MoarVM: Noticed by JimmyZ++. [14:01] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8880d61cc8 [16:24] *** Ven_ joined [16:26] *** vendethiel joined [18:02] *** vendethiel joined [18:31] *** vendethiel joined [20:16] m: say 39126704 / 644090520 [20:16] rakudo-moar 676c25: OUTPUT«0.060747213␤» [20:16] So, about 6% of instructions executed at startup are being spent on UTF-8 decoding and normalization. [20:18] I don't think that explains the increase in startup time [20:19] which is more like 50% ? [20:19] I think things going on in CORE.setting loading have become more costly too [20:20] Actually the above isn't all the cost [20:20] But that bit alone means it's worth looking into. [20:20] maybe %*PRAGMAS cloning for each scope ? [20:21] Unlikely also [20:21] no, that would only be compile time, right ? [20:21] Right [20:21] And we're looking at -e '1' or so [20:21] It's worth noting that we'll still a good bit lower in instruction count at startup than we have been in the past. [20:21] so that would also explain slowdown in spectest (slower compile) [20:22] Yeah, but...it *should* be a drop in the ocean [20:22] well, I'm no longer working on making @*INC lazy [20:22] The applicationg of use fatal in try blocks will have been much more of a cost. [20:22] *application [20:22] instead, making the creation of CompUnitRepo objects as lazy as possible [20:27] lizmat: Sounds sensible [20:28] as described in https://gist.github.com/lizmat/c7f53fa206da900c2b42 [20:50] *** rurban joined [20:54] Gee, typoing >> as > gets you some bugs... :) [20:57] *** vendethiel joined [21:01] * masak .oO( "you can't just make shit up and expect the computer to know what you mean, retardo!" -- mjd ) [21:08] *** colomon joined [21:11] MoarVM: 5eb670c | jnthn++ | src/ (4 files): [21:11] MoarVM: Bytecode file stores Latin-1 when possible. [21:11] MoarVM: [21:11] MoarVM: This is not only cheaper to decode, but we also know that it's already [21:11] MoarVM: normalized, so don't have to apply NFG. [21:11] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5eb670c88d [21:19] Wow, that was wroth it [21:19] *worth [21:19] m: say 579180597 / 644090520 [21:19] rakudo-moar 676c25: OUTPUT«0.8992223593␤» [21:19] 10% less instructions retired at startup [21:20] :-) [21:21] less retired, so more at work? :o [21:22] jnthn: when you say latin-1, do you really mean 0..255 or 0..127 for ord() ? [21:25] 0..255 [21:25] Which overlap perfectly with the first 255 Unicode codepoints. [21:26] And are already in NFC (says Unicode consortium) and contain no combinining chars, so thus in NFG for free too. [21:28] *** colomon joined [21:32] hmmm.. I thought only 0..127 (aka 7-bit ASCII) matched Unicode [21:32] * lizmat learned something again [21:33] jnthn: should I lock.protect reading from a hash from several threads as well, if another thread can change it ? [21:34] or do I just need to make sure only one of them changes it at any time ? [21:35] lizmat: Only 0..127 have the same encoded bytes. But the *codepoints* are the same above that, IIUC. [21:35] *encoded bytes in UTF-8 [21:36] Hence US-ASCII needs no translation at all to convert to UTF-8, and Latin-1 can be trivially translated. [21:40] *** Ven_ joined [21:40] lizmat: Yes, you need to [21:40] lizmat: As the writer may cause a resize [21:40] (for example) [21:41] so it would make sense to encapsulate access to such a hash in a sub with Proxy, right ? [21:42] * lizmat wonders how many hashes we have in the core that are not guarded like that [21:43] *** colomon joined [21:51] m: say 568004995 / 579180597 [21:51] rakudo-moar 676c25: OUTPUT«0.9807044607␤» [21:52] Can haz another 2% less instructions off...pretty much most code. :) [21:52] That's measruing the startup effect though. :) [21:54] Improvements to startup have the advantage of happening for *every* run. [21:55] In fact, the biggest impediment to my Perl 6 coding right now is r-j startup slowing my debugging iteration cycle enough that I start mentally context switching. [21:56] And your biggest impediment to using r-m is the concurrency instability? [21:56] (If I could do it in r-m, I would, but we're talking 40-50 threads for my current work.) [21:56] yup [21:56] That's pretty near top of my list now NFG is largely there [21:56] \o/ [21:57] I should push on a bit with shaped arrays too [22:01] MoarVM: 03e4e38 | jnthn++ | src/ (3 files): [22:01] MoarVM: Optimize temporary root handling. [22:01] MoarVM: [22:01] MoarVM: Only do sanity checks when we switch them on; they've caught very few [22:01] MoarVM: bugs so far, so it doesn't pay to have them on all the time. This in [22:01] MoarVM: turn means they are well within the size where they make sense to do [22:01] MoarVM: inlining; mark with MVM_STATIC_INLINE to be sure of it. [22:01] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/03e4e38fc0 [22:02] jnthn: so MVM_STATIC_INLINE=1 would activate the sanity tests ? [22:07] *** colomon joined [22:09] lizmat: No, MVM_STATIC_INLINE is a way of marking something up in the C code so the compiler should always inline it. [22:09] so how would one activate the sanity checks then ? [22:09] lizmat: You'd #define MVM_TEMP_ROOT_DEBUG 1 to turn on the sanity checks [22:09] ah, it needs a recompile [22:09] ok [22:09] yeah, but it's rather rare [22:09] They've caught us little. [22:10] well, maybe a separate JARVIS run with that enabled ? [22:10] JARVIS? [22:15] Travis [22:15] oops [22:15] :-) [22:15] some butler name [22:15] .oO( "Hey You" ) [22:33] *** colomon joined [22:49] MoarVM: f701499 | jnthn++ | / (2 files): [22:49] MoarVM: Cache backend config hash. [22:49] MoarVM: [22:49] MoarVM: We request it 7 times during Rakudo startup; only build it once. [22:49] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f701499cbb