Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Nicholas [* GOOD *] 06:39
nine *.map: *.GOOD 08:25
MasterDuke i don't remember if there were any comments on irc at the time, but any thoughts about github.com/MoarVM/MoarVM/pull/1470 ? 08:45
vrurg Are `nqp::uni*` thread-safe? 18:35
tellable6 2021-10-05T09:27:00Z #moarvm <jnthnwrthngtn> .tell vrurg It's about separate compilation; the compilation of a module should start with an empty GLOBAL and accumulate the things that are `use`d by it.
vrurg Wow, it was an old one... 18:36
japhb vrurg: Yeah, tellable6 is re-delivering messages it couldn't guarantee had been delivered properly before. 18:50
jnthnwrthngtn vrurg: They should be, but looks like something is wrong. Do you have a reproduction or can you get it to oops under rakudo-gdb-m and provide the stack trace? 20:42
The matter will probably give a big clue
vrurg jnthnwrthngtn: "They should be" is ok for now. I'm just trying to figure out the best fix for sub codename2proppref in unicodey.pm6. 20:43
Unfortunately, so far the best is to wrap the whole sub in a lock which is going to slow it down. :( 20:44
jnthnwrthngtn Ah, just saw the latest on the thread and it looks like there's actually some rakudo-level caching going on? 20:45
Yeah, that's that threadsafe at all
s:2nd/that/not 20:47
sourceable6 jnthnwrthngtn, No idea, boss. Can you give me a Code object? Output: 4===SORRY!4=== Error while compiling /tmp/HJi8w7z78Z␤Confused␤at /tmp/HJi8w7z78Z:1␤------> 328⏏4nd/that/not␤ expecting any of:␤ whitespace␤
jnthnwrthngtn hah 20:48
vrurg Phew, I was trying to figure out what you mean until the "not" was added. :)
jnthnwrthngtn I wonder if we could pre-calculate the hash at compile time
vrurg It mostly is. Caching is for what is overlooked, perhaps. 20:49
Or at least this is how I get it. I'm bad with unicode.
jnthnwrthngtn I suspect additions to this are rare, though, so an alternative is to never bind into the hash, but instead clone it, add the new key, and bind the copy in place of the old one (can't be `constant` then but, well, there's nothing constant about it anyway... 20:50
That's probably cheaper than the lock, anyway
vrurg That's what I'm currently considering. 20:51
jnthnwrthngtn Although for a locking appraoch, note that unless $prop2pref also also written to, then it may be that only the nqp::ifnull(...) part needs wrapping in a `$lock.protect`
vrurg There might be extra misses on the same key, but I don't think it would be too costly to have it cached on a second pass.
jnthnwrthngtn Indeed
vrurg $prop2perf is a RO, but I don't like lock.protect as it may break inlinability. 20:52
So, atomic replace, after all. 20:53
Thanks!
BTW, I wonder how much would it cost to have a low-level lock-protected hash for cases like this? Locking at C-level shouldn't be that expensive. 20:56
jnthnwrthngtn Probably won't save that much, since nqp::lock/nqp::unlock are pretty direct mappings onto C stuff anyway 21:00
And especially if they're jitted the interpreter cost goes away
vrurg Low-level wouldn't require an object allocation though.
jnthnwrthngtn Which object?
vrurg nqp::lock needs a concrete with ReentrantMutex repr 21:01
Or whatever the repr is named.
jnthnwrthngtn Sure, but for cases like this it's long lived anyway, plus the allocation might not even be the dominant cost (dunno without profiling, but it's also calling the pthread mutex creation stuff either way) 21:02
vrurg Oh, and correct NQP/Raku level locking requires handling of exceptions which wouldn't be needed for C-level hash protection.
Yeah, I'm trying to multi-task and forgot that allocation "issue" I have excluded myself too. Only to get back to it again... :) 21:03
Bet the exception is a problem because, again, it's about phasers and inlineability. 21:04
s/Bet/But/ 21:10

Powered by Cro and the Raku® Programming Language.

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

Thank you!