github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: MasterDuke17++ created pull request #927:
Speedup zero_slots by using memset...		 00:15
timotimo MasterDuke: i don't think nulling out an n64 or n32 slot with memset 0 is the same thing as assigning 0.0 00:42
i should probably put that in the PR 00:43
MasterDuke oh, right, didn't think about nums
timotimo ah you're still here, good
MasterDuke timotimo: stackoverflow.com/questions/462985...of-doubles 00:46
timotimo cool! 00:48
i'm glad it is so much faster 00:49
i would have expected the compiler to just turn the loop into a memset itself
MasterDuke yeah. hm, i didn't test with clang, wonder if there's still the same difference 00:50
and man, these OS X fails in travis are annoying 00:51
Geth MoarVM: e1df341199 | (Daniel Green)++ | src/6model/reprs/VMArray.c
Speedup zero_slots by using memset...

instead of looping over the array and setting each element.		 06:48
MoarVM: 05990ef908 | niner++ (committed using GitHub Web editor) | src/6model/reprs/VMArray.c
Merge pull request #927 from MasterDuke17/speedup_zero_slots_by_using_memset

Speedup zero_slots by using memset...
Geth MoarVM/jit-expr-refactor: 16 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/6...be94d51582		 09:07
lizmat why are IntLexRef's so expensive ? 10:29
jnthn Depends on the situation. They are an allocation, so that costs something. They refer to the enclosing frame, which may force a stack -> heap promotion (though with consistent use typically it will spot the pattern and switch to a direct heap allocation for the frame) 10:35
yoleaux 00:47Z <AlexDaniel> jnthn: please take a look at github.com/perl6/ecosystem-unbitrot/issues/41 there are at least two modules depending on it (and failing to install)
jnthn .tell AlexDaniel Been looking at that. Turns out it's not so simple to fix, and the fix that does land will likely force an API change in the module. 10:37
yoleaux jnthn: I'll pass your message to AlexDaniel.
lizmat jnthn: shouldn't something like multi sub infix:<->(int $a, int $b --> int) { nqp::sub_i($a, $b) } get OSR'd quickly ? 11:19
when run like 1M times ? 11:20
from the same callsite
jnthn OSR is about loops, there's no loop there 11:27
But also, the Rakudo static optimizer will inline such native calls, I believe
So there should just be sub_i in the --target=optimize
At least, it does that for those from CORE.setting 11:28
lizmat jnthn: so if the native infix:<-> appears in a profile, that's not working 11:30
MasterDuke jnthn: when you've got some free time, i would welcome your thoughts on github.com/rakudo/rakudo/issues/2158 11:32
lizmat jnthn: apparently that only works if both sides are direct lexicalrefs 11:35
afk for a bit 11:40
jnthn MasterDuke: Hm, no idea why it'd only show up problems with a particular encoding, unless it's revealed a bug in utf8-c8 itself that was previously hiding 12:24
dogbert11 jnthn: do you know if the flag MVM_SPESH_CHECK_PRESELECTION is still usable after all the changes lately? Enabling it sometimes generates a suspicious stacktrace when running spectest 12:38
i.e. github.com/MoarVM/MoarVM/blob/mast...frame.c#L6 12:39
MasterDuke jnthn: yeah, i'm not sure how reverting github.com/MoarVM/MoarVM/pull/631 fixes things. unless it's some interaction between the sizes it's reading and how it's doing the utf8-c8 encoding 12:42
jnthn dogbert11: Not sure; I have a vague recollection that it could trigger a false positive.
dogbert11: But worth looking at a bit more closely
dogbert11 jnthn: might the false positive have looked like this: Inconsistent spesh preselection of 'parse' (141): got 0, not -1 at src/Perl6/World.nqp:5168 (blib/Perl6/World.moarvm:canonicalize_pair) 12:44
jnthn Was too long ago to remember :) 12:46
dogbert11 I could report it so it doesn't slip through the cracks. 12:47
dogbert11 notes thunder and rain outside yay 12:48
Geth MoarVM: MasterDuke17++ created pull request #928:
Use correct types in find_deopt_target_and_index		 13:12
lizmat timotimo: interested in finding out how I can make "MoarVM oops: Spesh: failed to fix up handler 1 in <unit> (682, -1, -1)" go away ? 13:37
timotimo yes, but probably not right now %) 13:39
lizmat ok 13:40
timotimo it seems to happen with anything that does instrumentation, or at least it happens in both the profiler and ... i think the debugger? or perhaps it was the coverage log ... 13:46
jnthn .tell AlexDaniel Fixed Test::Scheduler, updated Concurrent::Progress tests to use it correctly, and verified SSH::LibSSH now installs OK. 13:50
yoleaux jnthn: I'll pass your message to AlexDaniel.
lizmat jnthn++ 13:55
jnthn Will need to spend some more brane on Test::Scheduler at some point 13:56
It's a kinda tricky problem space
But too hot for that today... 13:58
Geth MoarVM: f497f15394 | (Daniel Green)++ | src/spesh/optimize.c
Use correct types in find_deopt_target_and_index

The signature had MVMint32 for the deopt_target_out and deopt_index_out parameters, but they were only ever passed MVMuint32s.		 14:06
MoarVM: 22d710e099 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/spesh/optimize.c
Merge pull request #928 from MasterDuke17/use_correct_types_in_find_deopt_target_and_index_signature

Use correct types in find_deopt_target_and_index
MoarVM: 46c08a0e8e | (Jeremy Studer)++ | src/6model/reprs/CArray.c
Fix memory leak in CArray given P6 Strs

Within the CArray's bind_pos function, we are creating UTF8-encoded C-strings but are never freeing them. Make sure to free them when the CArray is GC collected.
MoarVM: 700ce36852 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/CArray.c
Merge pull request #921 from jstuder-gh/carray_str_leak

Fix memory leak in CArray given P6 Strs
MoarVM: b66be6edbb | (Jeremy Studer)++ | src/jit/core_templates.expr
Move exprjit templates to the proper location

In order to match oplist and interp.c		 14:07
MoarVM: 7cab426c20 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/jit/core_templates.expr
Merge pull request #920 from jstuder-gh/mv_templates_right_location

Move some exprjit templates to the proper order
MoarVM: 3bf120a132 | (Ben Davies)++ | Configure.pl
Fix Configure.pl version detection

Configure.pl was sometimes giving versions based off past tags instead of the current one.
MoarVM: ca0ece596b | (Jonathan Worthington)++ (committed using GitHub Web editor) | Configure.pl
Merge pull request #888 from Kaiepi/configure

Fix Configure.pl version detection
dogbert11 MasterDuke: wrt R#2158 have you tried valgrind ... 14:28
synopsebot R#2158 [open]: github.com/rakudo/rakudo/issues/2158 [regression] :enc<utf8-c8> on Proc appears to drop a lot of content
MasterDuke dogbert11: hm, haven't yet, guess i should try 14:31
dogbert11 I think so :)
MasterDuke oh! 14:36
dogbert11 perhaps samcv can do something with that 14:40
MasterDuke jnthn, samcv: github.com/rakudo/rakudo/issues/2158 now has some valgrind output showing invalid writes and reads decode_stream.c and utf8_c8.c
samcv hmm i didn't make any recent changes to tose files 14:41
MasterDuke you'll at least be better at finding a problem than i 14:42
xelak MasterDuke, jnthn: regarding github.com/rakudo/rakudo/issues/2158 - it looks there is an issue with "decoder.add-bytes()" - see gist.github.com/xelak6/c9812201a19...2b15084892 15:53
Geth MoarVM/jit-expr-refactor: 322114d87f | (Bart Wiegmans)++ | 5 files
[JIT] Eliminate MVMJitExprOpInfo

The only remaining use for this is constructing operators and getting the name for logging purposes, so there's no reason this should be a global structure.
brrt \o 15:58
timotimo o/
brrt couldn't write for a few seconds
Geth MoarVM/jit-expr-refactor: 17 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/3...e66e867b36		 15:59
lizmat brrt: yeah, anti-spam measure 16:04
brrt :-( 16:05
jnthn xelak: Interesting...that's certainly worth adding to the ticket
gist.github.com/jnthn/1e865a06d213...2908858a57 is an early draft proposal for some new low-level bits of working with binary data. It's immediate application would be replacing the QAST -> MAST phase with something that just produces the bytecode. 16:07
It also includes a proposal for exposing the functionality at Perl 6 level.
brrt will read it as soon as i have my PR ready 16:08
xelak jnthn: I'll add it to the ticket 16:09
jnthn xelak++
lizmat jnthn: "widened to a 64-bit uint" that would require to have fully functional 64bit uints, right ? 16:12
jnthn Yup
lizmat cool 16:13
timotimo jnthn: as a part of this, we should perhaps also decide whether utf16 (and other fixed-but-multi-byte formats like that) should go in Buf8 or Buf16 and up 16:14
jnthn Yeah, that needs some consideration 16:15
timotimo last time i checked you can't work with utf16 because one part (probably i/o?) wants the 8 bit and the other (i think the encoder/decoder) wants 16
lizmat utf16 isn't fixed size, is it ?
timotimo right, i meant something else by that
jnthn Well, it is in that the "units" are 16 bits wide
timotimo i suppose you'd call it ... yes, units 16:16
lizmat ah, ok
timotimo utf8 has either 8 bit, 16 bit, 24 bit, etc per code point, but utf16 has 16, 32, 48, ... or at least i think that's how it works
jnthn 16 or 32 so far as codepoints go 16:18
There's no codepoints that need more than 32 bits
timotimo that makes sense
though other systems have been bitten in the past by "we don't need to support more than n bytes per unit" :D
nine jnthn: 2 questions: did it actually rain in Prague today? And did it help?
yoleaux 4 Aug 2018 14:56Z <jnthn> nine: Not immediately clear it'd be an OSR issue, unless it goes away with MVM_SPESH_OSR_DISABLE=1 (which ain't one of the flags you mentioned)
Geth MoarVM: bdw++ created pull request #929:
Refactor Expression JIT to make tree manipulation easier		 16:21
brrt nine: fwiw, it did certainly not rain in NL :-) 16:22
timotimo ;(
brrt we still have hope for the future 16:24
lizmat Tue will see 37 degrees again for me
:-(
timotimo ugh 16:25
my condolences
brrt how is thursday looking lizmat 16:26
we have some hope for rain and 22 degrees
aka 'a normal sunny summer day'
lizmat 26 and possible rain for me 16:27
jnthn nine: Last night we got a very nice loud thunderstorm and hail. That helped a lot. 16:28
nine: Today there was a bit of light rain too; sadly, today's rain seems to have just resulted in humidity.
The forecast for the coming days looks...unpleasantly hot :( 16:29
nine So all hope rests on the nights' cooldown 16:30
jnthn Yeah
timotimo looks like tuesday through friday could potentially see rain every day 16:31
monday has both a higher max and a lower min than sunday: 19 to 34. that's quite a spread for having 0% rain chance
what the heck 16:32
jnthn Next 4 days highs are forecast as 31, 35, 36, 35 16:33
No rain forecast
timotimo allegedly it was 31 degC 15 minutes ago, but we just opened all the windows because it's ... cold outside
lizmat wouldn't mind a bit of that right now 16:34
timotimo well, it feels cold compared to what we had inside before 16:35
brrt jnthn: I left a comment 16:36
Obviously, the next question, after you've specified 'lets make a low-level binary API' is 'how are we going to remove the overheads' :-) 16:38
but I think that this should leave it reasonably doable
jnthn brrt: Well, I figure all those methods will be tiny and so inline cheaply
(The Perl 6 ones, I mean) 16:39
So then it's "how do we optimize the ops", and I suspect we get some nice specialization going on there
brrt I was thinking more of the MoarVM ones :-)
It'd be nice if we could eliminate the bounds check or move it upwards 16:40
timotimo that'd be cool, yeah
we're not interested in ziggy or zaggy views into buffers? 16:41
lizmat so I'm looking at the QAST for my ($a,$b) = (42,666)
jnthn timotimo: Well, I'm not at present :-)
brrt that's actually a reasonably simple abstraction on top, i think
lizmat the odd thing is, that the left hand side's List is created at runtime with a callstatic infix:<,>
while the right-hand side is optimised into a WVal List 16:42
jnthn lizmat: Why is that surprising? $a and $b aren't available until runtime
timotimo jnthn: any particular reason you only want to eliminate the first dimension, and not any dimension with the viewdim op?
jnthn timotimo: I figured you can just stack them up :)
timotimo: We can introduce an nd version that takes a list of dimensions if we gotta 16:43
timotimo i don't think you can stack them so you can get varying first and fixed second dimension
jnthn Oh, that
No, there's nothing for that, though from a Perl 6 perspective there's not really a way to write it either I guess
timotimo oh 16:44
jnthn I mean, @a[1] on a 2D array would fix the first dimension
timotimo @a[*;1] and @a[1;*] is not that?
jnthn The * there expands into "all the elements" 16:45
Indexing is eager
timotimo OK, that makes sense. in that case i want someone to come up with a way to spell what i mean :D 16:45
jnthn :) 16:46
timotimo there's probably no use case for this, but do we want a way to cheaply add an extra dimension that only accepts the index 0? 16:46
i.e. turn @a = 1, 2, 3; into @a = [1, 2, 3],;
jnthn brrt: fwiw, I'd also pondered whether we want a different REPR for the dimension thing 16:47
brrt: We might just want to do that to make it a bit easier to handle optimization
timotimo yeah, how often is one piece of code going to service both kinds 16:48
jnthn Hm, true
Yeah, probably those want to be two new REPRs
lizmat m: my ($a,$b); # this creates a List at runtime
timotimo should say "one instance of a piece of code", vis-a-vis inlining
camelia ( no output )
jnthn lizmat: Even if you don't assign to it? And it's in sink context? 16:49
lizmat yup
jnthn lizmat: that's a tad sloppy
Probably relatively easy to fix
lizmat so I guess we can get the static optimizer to make that 2 QAST::Var's right ?
jnthn We don't even need to do that, I guess
We don't need the list at all 16:50
So perhaps wrapping things up in a QAST::Want 'v' or similar at the point we produce the list
lizmat tries to parse 16:51
lizmat jnthn: any pointers on where I could do this, by any chance ? 16:52
jnthn See around src/Perl6/Actions.nqp:3586 16:52
lizmat ack 16:53
jnthn There's an if $<initializer>
And an error-checking elsif
And I guess maybe it's possible to stick after that something like
else {
$list := QAST::Want.new( $list, 'v', QAST::Op.new( :op('null') ) )
} 16:54
Or similar
lizmat tries 16:54
lizmat ok, that works :-) 17:29
yoleaux 17:08Z <AlexDaniel> lizmat: log is now linked on github.com/rakudo/rakudo/wiki/Mont...Squash-Day
lizmat and spectests clean 17:29
jnthn: so, the case of my ($a,$b,$c) = <foo bar baz>; 17:30
lizmat the optimizer already constant folds the right hand side to a WVal List 17:30
so I was thinking of further optimizing that case to basically my $a = "foo"; my $b = "bar", my $c = "baz"; 17:31
any thoughts / objections against that ? 17:32
it would make things like that about 15x faster
jnthn Hm, may need to be careful about evaluation order
But it's probably viable
lizmat right hand side is a WVal List already
jnthn Ah, yes, in this particular case it's especially easy :) 17:33
lizmat right
jnthn Yeah, probably can do a tree transform in the optimizer to handle that case without too much trouble
lizmat yeah, just read the nqp::atpos(Wval.value,0)
MasterDuke lizmat: if you've got time, and since it seems related, you might have a better/cleaner solution doing a similar optimization for array slices than github.com/rakudo/rakudo/pull/1844 17:36
lizmat looking at that this very moment :-)
so, is/was there a reason you're limiting it to 2 indices ? 17:39
MasterDuke lizmat++
well, i think i was thinking that since it was sort of a special case optimization, just limit it to the most common case 17:41
if you can follow what i just said (because i only barely did)
lizmat ok 17:42
lizmat does some benchmarking
MasterDuke but yeah, if it's a good approach, it probably could be generalized a bit
lizmat not sure of the approach just yet :0) 17:45
MasterDuke oh wait, i don't think it is limited to just 2 indices
lizmat :-) rather
ah, you're right
MasterDuke: what this sillyness? && ((try $!symbols.find_lexical($op.name)) || 1) 17:49
does it need to be primed everytime ?
MasterDuke huh, not really remembering what that was about 17:51
brrt \o 18:25
MasterDuke lizmat: fwiw, re 1844, colabti.org/irclogger/irclogger_log...8-06-10#l6 18:27
Geth MoarVM/jit-expr-refactor: aea1037900 | (Bart Wiegmans)++ | 5 files
[JIT] Eliminate MVMJitExprOpInfo

The only remaining use for this is constructing operators and getting the name for logging purposes, so there's no reason this should be a global structure.		 18:37
MasterDuke brrt: while you're here, concur with timotimo on github.com/MoarVM/MoarVM/pull/926 ? 18:50
also, any reason not to merge github.com/MoarVM/MoarVM/pull/915 ? 18:53
Geth MoarVM/jit-expr-refactor: 18307b638c | (Bart Wiegmans)++ | 2 files
[JIT] Please Travis

  - uses an old perl which doesn't understand keys @arrays
  - clang complained about a printf		 19:10
brrt MasterDuke: no reason why not 19:16
MasterDuke cool, i'll go ahead and merge it then 19:24
Geth MoarVM/master: 4 commits pushed by (Daniel Green)++, MasterDuke17++ 19:26
MoarVM/master: 18 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/6...6939528813		 19:36
Geth MoarVM: b3eb1f459b | (Timo Paulssen)++ | src/spesh/inline.c
shameful hotfix for gigantic profiler output files

an inlined throwpayloadlexcaller can cause the profiler to miss one or more "frame leave" events, at which point the call graph can become extremely elongated.
For now, prevent frames from being inlined if they have that op in them while profiling is active.		 19:45
Geth MoarVM: 346df9ebd8 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/spesh/inline.c
Mark "shameful hotfix" as TODO

So it doesn't stay there forever		 19:56
Geth MoarVM: 166c4a2530 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/spesh/inline.c
Fix wrong comment
 19:59
Geth MoarVM/jit-expr-optimizer: 4 commits pushed by (Bart Wiegmans)++ 20:14
brrt ^ rebased, updated jit optimizer 20:15
timotimo good idea zoffix, thanks 21:36

Powered by Cro and the Raku® Programming Language.

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

Thank you!