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
brrt \o 06:55
07:47 zakharyas joined 08:14 zakharyas joined 08:37 Ven joined 08:45 vendethiel joined 08:52 rurban joined 09:12 Ven joined
brrt jnthn, i have a burning question 09:18
it seems to me that decont/assign are not, in fact, invokish at all
did this change sometime in the last year?
lizmat brrt: ETA jnthn ~ 20 mins 09:19
brrt ah
jnthn brrt: decont and assign may invoke
See Proxy
brrt but.... but... 09:20
ok
fair enough
jnthn and yeah, still doing errands... :)
back for real soon :)
brrt ok, don't let me distract you then
:-)
you are completely correct, of course 09:27
how did i not see that 09:28
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
travis-ci MoarVM build passed. Paul Cochrane 'Destroy correct string decodestream 13:03
travis-ci.org/paultcochrane/MoarVM/...s/60829756 github.com/paultcochrane/MoarVM/co...700a7283f2
13:03 travis-ci left
dalek arVM: 4ca886c | jnthn++ | src/strings/ops.c:
Remove fragile assumption about buffer size.

Just fwrite the \n separately rather that relying on the UTF-8 encoder allocating a little more than needed just for this one case.		 13:20
arVM: 1f9d843 | jnthn++ | src/strings/utf8.c:
Fix UTF-8 encoder to handle NFG.

Also, now we have to resize a buffer anyway, start out with a lower assumption.
13:30 rurban joined 13:37 travis-ci joined
travis-ci MoarVM build passed. Paul Cochrane 'Inititialise `operand_size` in MVM_bytecode_dump() 13:38
travis-ci.org/paultcochrane/MoarVM/...s/60833279 github.com/paultcochrane/MoarVM/co...702843743d
13:38 travis-ci left
JimmyZ jnthn: re 4ca886cbb8 , maybe 'utf8_encoded_length + 1' => utf8_encoded_length? 13:41
jnthn JimmyZ: hm, yes 13:43
dalek arVM: 97835d6 | jnthn++ | src/strings/ops.c:
More robust NULL string checking.

This should avoid a bunch of SEGVs arising from NULL strings getting passed into things not expecting them.		 14:01
arVM: 2c9398a | jnthn++ | src/ (2 files):
Ensure we get NULL-terminated strings if needed.

We used to get them more by accident than by design, but that made us do an unrequired memset in the UTF-8 encoder. Call the function that demands a null-terminated string.
arVM: 8880d61 | jnthn++ | src/strings/ops.c:
Fix off-by-one in recent change.

Noticed by JimmyZ++.
16:24 Ven_ joined 16:26 vendethiel joined 18:02 vendethiel joined 18:31 vendethiel joined
jnthn m: say 39126704 / 644090520 20:16
camelia rakudo-moar 676c25: OUTPUTĀ«0.060747213ā¤Ā»
jnthn So, about 6% of instructions executed at startup are being spent on UTF-8 decoding and normalization.
lizmat I don't think that explains the increase in startup time 20:18
which is more like 50% ? 20:19
jnthn I think things going on in CORE.setting loading have become more costly too
Actually the above isn't all the cost 20:20
But that bit alone means it's worth looking into.
lizmat maybe %*PRAGMAS cloning for each scope ?
jnthn Unlikely also 20:21
lizmat no, that would only be compile time, right ?
jnthn Right
And we're looking at -e '1' or so
It's worth noting that we'll still a good bit lower in instruction count at startup than we have been in the past.
lizmat so that would also explain slowdown in spectest (slower compile)
jnthn Yeah, but...it *should* be a drop in the ocean 20:22
lizmat well, I'm no longer working on making @*INC lazy
jnthn The applicationg of use fatal in try blocks will have been much more of a cost.
*application
lizmat instead, making the creation of CompUnitRepo objects as lazy as possible
jnthn lizmat: Sounds sensible 20:27
lizmat as described in gist.github.com/lizmat/c7f53fa206da900c2b42 20:28
20:50 rurban joined
jnthn Gee, typoing >> as > gets you some bugs... :) 20:54
20:57 vendethiel joined
masak .oO( "you can't just make shit up and expect the computer to know what you mean, retardo!" -- mjd ) 21:01
21:08 colomon joined
dalek arVM: 5eb670c | jnthn++ | src/ (4 files):
Bytecode file stores Latin-1 when possible.

This is not only cheaper to decode, but we also know that it's already normalized, so don't have to apply NFG.		 21:11
jnthn Wow, that was wroth it 21:19
*worth
m: say 579180597 / 644090520
camelia rakudo-moar 676c25: OUTPUTĀ«0.8992223593ā¤Ā»
jnthn 10% less instructions retired at startup
lizmat :-) 21:20
tadzik less retired, so more at work? :o 21:21
lizmat jnthn: when you say latin-1, do you really mean 0..255 or 0..127 for ord() ? 21:22
jnthn 0..255 21:25
Which overlap perfectly with the first 255 Unicode codepoints.
And are already in NFC (says Unicode consortium) and contain no combinining chars, so thus in NFG for free too. 21:26
21:28 colomon joined
lizmat hmmm.. I thought only 0..127 (aka 7-bit ASCII) matched Unicode 21:32
lizmat learned something again
jnthn: should I lock.protect reading from a hash from several threads as well, if another thread can change it ? 21:33
or do I just need to make sure only one of them changes it at any time ? 21:34
japhb 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
Hence US-ASCII needs no translation at all to convert to UTF-8, and Latin-1 can be trivially translated. 21:36
21:40 Ven_ joined
jnthn lizmat: Yes, you need to 21:40
lizmat: As the writer may cause a resize
(for example)
lizmat so it would make sense to encapsulate access to such a hash in a sub with Proxy, right ? 21:41
lizmat wonders how many hashes we have in the core that are not guarded like that 21:42
21:43 colomon joined
jnthn m: say 568004995 / 579180597 21:51
camelia rakudo-moar 676c25: OUTPUTĀ«0.9807044607ā¤Ā»
jnthn Can haz another 2% less instructions off...pretty much most code. :) 21:52
That's measruing the startup effect though. :)
japhb Improvements to startup have the advantage of happening for *every* run. 21:54
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:55
jnthn And your biggest impediment to using r-m is the concurrency instability? 21:56
japhb (If I could do it in r-m, I would, but we're talking 40-50 threads for my current work.)
yup
jnthn That's pretty near top of my list now NFG is largely there
japhb \o/
jnthn I should push on a bit with shaped arrays too 21:57
dalek arVM: 03e4e38 | jnthn++ | src/ (3 files):
Optimize temporary root handling.

Only do sanity checks when we switch them on; they've caught very few bugs so far, so it doesn't pay to have them on all the time. This in turn means they are well within the size where they make sense to do inlining; mark with MVM_STATIC_INLINE to be sure of it.		 22:01
lizmat jnthn: so MVM_STATIC_INLINE=1 would activate the sanity tests ? 22:02
22:07 colomon joined
jnthn 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
lizmat so how would one activate the sanity checks then ?
jnthn lizmat: You'd #define MVM_TEMP_ROOT_DEBUG 1 to turn on the sanity checks
lizmat ah, it needs a recompile
ok
jnthn yeah, but it's rather rare
They've caught us little.
lizmat well, maybe a separate JARVIS run with that enabled ? 22:10
jnthn JARVIS?
lizmat Travis 22:15
oops
:-)
some butler name
japhb
.oO( "Hey You" )
22:33 colomon joined
dalek arVM: f701499 | jnthn++ | / (2 files):
Cache backend config hash.

We request it 7 times during Rakudo startup; only build it once.		 22:49

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!