github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
jnthn :) 00:08
jnthn goes to get some rest
'night o/
00:19 buggable left, buggable joined 01:17 stmuk joined 01:19 stmuk_ left 03:24 stmuk_ joined 03:25 stmuk left 06:09 lizmat left 06:17 domidumont joined 06:23 domidumont left 06:24 domidumont joined
samcv good morning 06:36
Geth MoarVM: e94d3dfdb5 | (Samantha McVey)++ | 6 files
Remove previous hash handle pointers in hash implementation

This makes each hash handle 8 bytes (on 64-bit) smaller. It results in a speedup on my hash speed test by ~1% as well (likely due to more entries fitting in the cache) and reduces memory by 8MB with a million hash entries. The test wastes about half cpu on GC so likely the speed increase is at least 3% or more if just taking the hash impl. code into ... (10 more lines)		 06:52
MoarVM: 0dd6ce5478 | (Samantha McVey)++ (committed using GitHub Web editor) | 6 files
Merge pull request #904 from samcv/remove-backref-hash2

Remove previous hash handle pointers in hash implementation
07:00 lizmat joined
Geth MoarVM: a50a0b15bb | (Samantha McVey)++ | tools/compare-oplist-interp-order.sh
Make compare-oplist-interp-order.sh more POSIX compliant

Replace things undefined things in POSIX shell with things that are. Noticed by CodeFactor.		 07:08
08:48 robertle joined 08:51 domidumont left 09:01 lizmat left 10:11 lizmat joined 10:23 domidumont joined 10:29 MasterDuke left 11:41 Ven`` joined 11:59 MasterDuke joined
Geth MoarVM: samcv++ created pull request #905:
Test branch		 12:17
13:35 Ven`` left 13:40 Ven`` joined 14:25 zakharyas joined
timotimo i wonder how often we try to add VMNull to a worklist in the gc, and if checking for VMNull in certain spots, like maybe VMArray, would be beneficial 14:55
14:57 reportable6 left, reportable6 joined 15:05 zakharyas left, zakharyas joined
samcv timotimo: well it was faster to not check from my timing. 15:06
15:06 zakharyas left
samcv but we could check if we need to, though i could measure the time difference 15:06
15:07 zakharyas joined
timotimo did you only check for null or for VMNull, too? 15:09
samcv oh. actually yeah it was just a null check 15:10
that it doesn't check for when worklist->include_gen2 is true
though i'd think it'd be even slower if we checked for VMNull as well
but you could bench it
timotimo hm, but VMNull will have its "it's in gen2" bit set, so it wouldn't end up in worklists in the minor collections anyway 15:16
16:04 zakharyas left 16:05 zakharyas joined 16:30 AlexDaniel left 16:33 AlexDaniel joined 16:36 Ven`` left 16:38 Ven`` joined
masak Juerd: I know I'm in a minority, but I'm _really_ cagey about junctions. and I say that as someone who originally loved the idea of junctions. 16:40
I got a twinge of jealousy when PEP 572 started talking about a "witness" to any() and all() 16:41
because at least one of the way people use junctions is to ask "is any() of the cards on hand an ace?"
"yep"
"well, which one?"
"beats me. search for it?"
which is where, to me, the idea goes from cool handwaving about "quantum superpositions" to not-so-helpful 16:42
sorry, that came out as overly negative :) but I do think there's something suboptimal about the way junctions are designed 16:43
the way junctions invade the type hierarchy and get special treatment in the dispatcher and fork the (green) thread of execution is also a part of why I don't want to rely on them too much 16:45
generally, you want to make wrong code look wrong, but junctions make wrong code look right. the interpretation of something becomes wildly different if it turns out it gets executed multiple times. 16:46
in summary, (a) not helpful enough, (b) based on questionable theory, (c) insane power/catastrophe balance 16:47
...hey, this is not #perl6... 16:49
sorry for the noise. *blush*
lizmat masak: so you're saying some function that converts a Junction to a Set matching a condition ? 16:56
geekosaur I think in that case you might do better with tracking conditions throughout? (or, this is better suited to a neural network than junctions, perhaps?) 17:02
not that you can introspect how a neural network came to its decision very well; every approoach has its drawbacks 17:03
17:07 zakharyas left 17:18 zakharyas joined 18:00 Ven`` left 18:24 brrt joined 18:28 Ven`` joined
brrt \o 18:38
18:51 Ven`` left 18:52 Ven`` joined
masak lizmat: I've been toying with the idea of "syntactic junctions", something like `$x == 1 | 2` compiling down to `$x == 1 || $x == 2`. they'd be strictly weaker than runtime junctions, but it's very rare I need/want that extra power. and they'd be a lot more predictable. 18:59
timotimo kind of just one step farther than 1 < $x < 4 turning into 1 < $x && $x < 4 19:01
19:04 zakharyas left
MasterDuke there are a bunch of logs that only optionally put a pid in the filename. given that rakudo runs multiple threads by default, should everything use a pid as standard (like MVM_TELEMETRY_LOG does)? 19:04
19:05 domidumont left 19:52 brrt left, brrt joined
lizmat masak: afaik, timotimo actually already did that in the Optimizer 20:10
20:10 brrt left 20:19 zakharyas joined, brrt joined
brrt hmm. we don't want to use C99 features if we can avoid it, do we 20:39
that's unfortunate, flexible array members would've solved my problem quite nicely 20:40
lizmat well, it looks like Perl 5 has been dependent on C99 for quite some time, judging from this perldelta entry: 20:42
metacpan.org/pod/distribution/perl...-compilers
that implies to me that some part of Perl 5 at least has been dependent on C99 features already
if you want to compile MoarVM on a 15+ year old compiler, what does that mean ? 20:43
MasterDuke isn't windows the problem? msvc doesn't support all of C99 or something like that? 20:44
brrt windows is always a problem
20:45 zakharyas left
lizmat masak: perhaps special case Junction.first and Junction.grep ? 20:45
m: dd (1|2|3).grep(1) 20:46
camelia any((1,).Seq, ().Seq, ().Seq)
lizmat or let .Seq coerce an "any" junction to its members ? 20:47
m: dd (1|2|3).Seq # instead of this, (1,2,3).Seq
camelia any((1,).Seq, (2,).Seq, (3,).Seq)
lizmat of have a function .eigenstates that creates a .Seq of the members of the Junction ? 20:49
(1,2,3).eigenstates.grep(1) # (1,).Seq
(1|2|3).eigenstates.grep(1) # rather 20:50
with "eigenstates" being a funny enough name for people to know their doing something potentially iffy ?
brrt okay, so i can't make an array-of-flexible-array-members 20:52
so let's ignore that one
masak lizmat: I guess what I'm after is not something that's "potentially iffy", but something that better accommodates that use case ;) 21:10
21:22 brrt left 21:42 stmuk joined 21:44 stmuk_ left
timotimo ha! 21:57
i just looked at a recent spesh log of JSON::Fast doing some parsing
there's lots of BBs that are inlined and only either one or two set instructions are all that remains 21:58
surely that was sink calls or something like that, but still 21:59
anyway, that's beautiful
oh, it's a two-level inline, via Seq.pm6's from-loop 22:01
looks like we often retain "identity" being inlined as two sets, one for the getarg, one for the return 22:05
22:06 robertle left
jnthn Yeah, we're not quite smart enough to do away with that yet :) 22:07
22:15 Ven`` left
timotimo oh jnthn, i found an easy win! 22:37
did you know that we don't discover facts when we see an sp_fastcreate?
jnthn hm, no :) 22:39
timotimo oh 22:47
the spesh slot in question stores the STable, but our facts refer to types rather than STables 22:48
that's ... not so great, is it? 22:49
jnthn We generally store whatever is most convenient :)
Well, more to the point, whatever makes it fastest to execute the operation in question
timotimo yeah, STable is most convenient for fastcreate to operate, but not for facts discovery
so, what now? add a second spesh slot argument to sp_fastcreate just to store the type object we got the STable from? 22:50
i wouldn't want to make sp_fastcreate slower by adding the extra pointer deref to get from the type object to the STable for the benefit of fact discovery later on 22:51
actually, do we perhaps always only need the STable when we talk about KNOWN_TYPE? 22:56
jnthn I don't see the problem; the type object is just available as st->WANT
oops
st->WHAT
timotimo oh, is it!
well, that's very easy, then %)
jnthn So can just do that to set the known type ;)
timotimo somehow i totally missed that
jnthn :)
timotimo let's run some tests ... 23:01
i would assume sp_fastcreate isn't the only sp_ op that's missing from fact discovery, actually 23:32
sp_getspeshslot could have known value, for example 23:33
sp_getwvalfrom should also get facts
but that could already be everything 23:34
jnthn *nod*
Yeah, worth doing that for inlines :)
timotimo oh, getstringfrom also could

Powered by Cro and the Raku® Programming Language.

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

Thank you!