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 #935:
Silence an incorrect GCC string overflow warning		 03:29
Geth MoarVM/pea: ca89cd992f | (Carl Masak)++ | docs/bytecode.markdown
Remove incorrect byte sum

This number used to be correct, but 8a348d7480d47f1214d3201a7bd4c840bfb3f054 turned everything into 32-bit integers, and failed to update this sum from 10 to 12.
Probably unlikely that the sum will update again, but removing it because presenting the total number of bytes doesn't add much in terms of documentation. (Cf. it being the wrong number for the past five years.)		 08:39
masak :) 08:40
ur. wrong branch. dang.
Geth MoarVM: 082dddfdd2 | (Carl Masak)++ | docs/bytecode.markdown
Remove incorrect byte sum

This number used to be correct, but 8a348d7480d47f1214d3201a7bd4c840bfb3f054 turned everything into 32-bit integers, and failed to update this sum from 10 to 12.
Probably unlikely that the sum will update again, but removing it because presenting the total number of bytes doesn't add much in terms of documentation. (Cf. it being the wrong number for the past five years.)		 08:41
masak git++
travis-ci MoarVM build failed. Carl Masak 'Remove incorrect byte sum 09:02
travis-ci.org/MoarVM/MoarVM/builds/413478119 github.com/MoarVM/MoarVM/compare/3...2dddfdd228
masak I doubt that my docu update was what broke the build. 09:05
"===SORRY!=== Found a MoarVM binary but was not able to get its version number." 09:06
I saw that one in a build break a while back. no idea what causes it. 09:07
nwc10 $ ./perl6-m -Ilib t/04-nativecall/06-struct.t 10:13
===SORRY!===
No such spesh plugin 'decontrv' for current language
jnthn wat
nwc10 indeed :-/ 10:14
jnthn How can that even happen...
nwc10 also ASAN still excited
at least last night
hadn't got to the end yet to retest
jnthn: MVM_SPESH_NODELAY=1 10:15
jnthn oh...
Darn, can't reproduce the error 10:17
nwc10 I also have +#define FSA_SIZE_DEBUG 1 10:18
+#define MVM_SPESH_CHECK_DU 1
+#define MVM_ARRAY_CONC_DEBUG 1
and MVM_SPESH_BLOCKING=1
Geth MoarVM: 50b063e045 | (Jonathan Worthington)++ | 2 files
Mark sp_speshresolve as :useshll

Since plugins are resolved for the current HLL, so inlining this op will cause a mis-lookup.		 10:19
jnthn See if that helps
dogbert2 MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./perl6 -Ilib t/04-nativecall/06-struct.t 10:22
jnthn Yeah, that's what I ran
dogbert2 failed for me, but I'm just compiling your fix ... 10:23
preliminary findings are promising :) 10:24
nwc10 jnthn: OK, about to test. ASAN excitement was paste.scsys.co.uk/581373
dogbert2 nwc10: I reported that for you as github.com/MoarVM/MoarVM/issues/931 10:25
nwc10 now paste.scsys.co.uk/581374
beleive these are identical apart from addresses
and sadly diakopter's believed fix didn't fix *that*
dogbert2: thanks, yes, saw that in passing but then forgot that you'd done that 10:26
dogbert2 jnthn: my 32 bit Linux system gives your 'Mark sp_speshresolve as :useshll' fix a thumbsup :-) 10:28
jnthn yay :)
nwc10 "there will be a delay" - I'm told that lunch is ready
NQP build in progress
dogbert2 github.com/MoarVM/MoarVM/issues/931 is a bit odd though 10:29
the actual line causing ASAN/valgrind barfage seems to be github.com/MoarVM/MoarVM/blob/mast...ker.c#L336 10:31
dunno of that gives rise to any theories?
travis-ci MoarVM build failed. Jonathan Worthington 'Mark sp_speshresolve as :useshll 10:39
travis-ci.org/MoarVM/MoarVM/builds/413512903 github.com/MoarVM/MoarVM/compare/0...b063e04511
jnthn Will look at the bugs later... Been sketching out a spesh plugin for return type check / coercion handling 11:00
In the least valuable case this will halve the size of the type check bytecode we emit 11:01
Spesh was already quite good at stripping it all out anyway
jnthn But it's still quite bloaty in the unoptimized form 11:02
Plus a ton of error strings in the constant table etc.
jnthn lunch; bbiab 11:06
dogbert2 jnthn: cool, do you think the new plugin will have an effect on |Tux| code? 12:09
jnthn Not sure 12:12
Though I'm hoping it'll let me improve the inlining situation around array access which quite possibly would help 12:20
dogbert2 yes, it was something with going above the inlining limit or some such 12:21
jnthn Rakudo now builds using the plugin
Fails 3 tests from make test
dogbert2 doesn't seem so bad
jnthn Yeah, with all the definite/coercion/Nil/Failure special cases in there, it's rather complex 12:23
dogbert2 You should arm yourself with a cup of 'post lunch coffee' 12:28
jnthn Ah, hmm 12:31
Yeah, it's I think because the callercode op gives wrong results if the caller is inlined 12:33
Thankfully, I recently built a mechanism for fixing these things :)
Yup, that helps a lot :) 12:49
Anyone got a recent build handy and can tell me the size of their CORE.setting.moarvm? 12:51
Geth MoarVM: 09717adec8 | (Jonathan Worthington)++ | 6 files
Make the callercode op inline-aware

If the caller frame had performed inlining, then we would get the wrong callercode result.		 12:53
lizmat jnthn: 14075648
as of HEAD just now
jnthn Mine with the change is 14047512 12:54
lizmat nice reduction
jnthn m: say 14075648 - 14047512
camelia 28136
jnthn make test happy, 2 spectest regressions I need to look at 12:55
lizmat m: say 14047512 / 14075648
camelia 0.99800109
jnthn ah, darn, it doesn't have entirely good performance consequences though :( 12:56
Wonder why
lizmat jnthn: fwiw, moarvm size last october was 12849568 12:57
jnthn Yeah, the opts can't always keep up with the CORE.setting additions :) 12:59
nwc10 CORE.setting.moarvm: 14075232 13:05
masak CORE.setting.moarvm: 14082176 (this is on Rakudo 7c08ba7) 13:07
travis-ci MoarVM build failed. Jonathan Worthington 'Make the callercode op inline-aware 13:13
travis-ci.org/MoarVM/MoarVM/builds/413567653 github.com/MoarVM/MoarVM/compare/5...717adec889
jnthn boggles at where the slowdown coulda come from 13:17
dogbert2 speaking of slowdowns, is it correct to say, that atm, some code runs slower than it did before you started on the performance grant 13:21
because some opts haven't yet beeen implemented?
jnthn It's possible, and even where there's opts done, there's trade-offs 13:23
dogbert2 there was one commit, where the text explicitly said that this would make things slower. I can't find it atm but I believe that it had something to do with moving some code from MoarVM to nqp 13:26
jnthn Ah, yeah
brrt \o
dogbert2 hi brrt
brrt .tell Kaiepi I would actually kind of rather have not a reimplementation of the lego JIT 13:27
yoleaux brrt: I'll pass your message to Kaiepi.
brrt ohai dogberg2
dogbert2
dogbert2 so now some code is almost two times slower than 2018.06
:)
diakopter images a floating DogBerg
*imagines
jnthn 171,437,489 /home/jnthn/dev/MoarVM/src/spesh/deopt.c:uninline [/home/jnthn/dev/MoarVM/install/lib
That...might have something to do with it... 13:28
dogbert2 aha
diakopter hopes for a 99.9999% slowness reduction
jnthn yeah, absolute flood of 13:29
Deopt one requested by JIT in frame 'pull-one' (cuid '10348') (330 -> 398)
Recreated frame 'consume-line-chars' (cuid '3829')
In the deopt log :)
dogbert2 does anyone know if part of Perl 6 has been inspired by Julia or could it be the other way around 13:34
diakopter I thought Julia was much older 13:37
dogbert2 I reacted to blurbs like 'Julia uses multiple dispatch as a paradigm, making it easy to express many object-oriented and functional programming patterns.' 13:38
and 'Julia is dynamically-typed, feels like a scripting language'
the spruced up their homepage a bit - julialang.org/ 13:39
ilmari First appeared: 2012 according to wikipedia
diakopter oh 13:40
masak dogbert2: Julia appeared in 2012, at which point Perl 6 had had multi dispatch *implemented* for a few years
so if anything, Julia was inspired by Perl 6
dogbert2 masak: cool
it seems to be the up and coming lang if your'e doing at lot of maths 13:41
masak yes, I wish Julia well -- it seems a cool, well-designed language 13:43
jnthn For some reason, we're inserting a guard that looks for a type object, which is bonkers 'cus most of the time it's a concrete instance, but also, we don't even care if it's a type object 13:45
diakopter jnthn: kiwf?
jnthn language class time, bbl 13:46
masak what a cliffhanger! 13:47
[Coke] am i the only one who tries to read "useshll" as sean connery? 14:20
Kaiepi that's alright brrt 14:23
yoleaux 13:27Z <brrt> Kaiepi: I would actually kind of rather have not a reimplementation of the lego JIT
lizmat [Coke]: I think so :-) 14:24
diakopter [Coke]: I do 14:27
[Coke]: the offishers and I will shubmerge beneath you and shcuttle the ship 14:28
lizmat ah, like that...
you just mean a heavy Scottish accent
ok, I can follow *that*
brrt i'd rather have an implementation built on the expression JIT, since that will involve far fewer assembly, and can reuse many more moving parts 14:30
timotimo jnthn: what do you think is the impact of making speshresolve :usehll? 14:35
we can totally have a speshresolvefrom op that has an hll name parameter 14:38
Kaiepi fair 14:47
brrt Kaiepi: the downside is, that isn't totally possible yet because we haven't translated everything to expression JIT again 15:05
*already
Kaiepi ah 15:06
brrt so
:-)
jnthn timotimo: I'd expect it's close to zero 15:16
timotimo: We have some guts code written in NQP that is called from Perl 6 code
But we have little the other way that's hot that I can think of, and NQP doesn't use spesh plugins
timotimo OK 15:19
jnthn So...what's wrong with this thing... 15:20
jnthn ho, the stats are bogus 15:29
408:
timotimo what spesh logs make?
jnthn 2 x type Str (TypeObj)
204 x static frame 'identity' (151) (caller is outer: 0, multi 0)
2 x type tuple:
Type 0: Str (TypeObj)
Where are the types for the other 202 calls? :)
jnthn still didn't figure out where on earth they're getting lost to... 15:45
timotimo getting confused by indices? 15:46
like, the 408?
or the correlation id getting messed up somehow?
jnthn No, the offset is OK
I guess maybe perhaps kinda but...that's still odd
Why are all the static frame entries OK? 15:47
timotimo no idea :(
jnthn And why do we get two - but only the type object cases - resolved?
uh, logged 15:48
I wonder if somehow the call to the spesh plugin confuses it
timotimo oh, jnthn, are you -1 or +1 on adding a "first time invoked" attribute to profiler call graph nodes? 15:52
jnthn What would it mean? :) 15:53
jnthn Or rather, how would it differ from seeing if the call count isn't zero? 15:54
timotimo well, just whenever a new node appears in the call graph we record what time-since-start it was 15:54
timotimo it'd help correlate different phases of programs against the GCs for example 15:54
jnthn ah, I see 15:55
Yeah, no problem
Zoffix Can utf8_c8 produce more bytes than in the original stream? If change `bytes` to `(bytes + 1)` in this malloc: github.com/MoarVM/MoarVM/blob/mast..._c8.c#L471 it fixes the SEGV in R#2158 trying to figure out if the result is undersized or if the position gets messed up somewhere.
synopsebot R#2158 [open]: github.com/rakudo/rakudo/issues/2158 [SEGV][regression][tests committed][⚠ blocker ⚠] :enc<utf8-c8> on Proc drops content / SEGVs
timotimo i'm also considering putting a "rss or maxrss at time of collection" thing in, but that would require careful accounting so as not to count the whole profiler data as well 15:56
jnthn More bytes, yes, but I can't think of a case where it'd result in more than one grapheme per byte
And we're allocating graphemes there 15:57
Zoffix ah, ok
jnthn Ohh.
Unless maybe there's a partial byte in the buffer
e.g. of bytes from the previous buffer that didn't before a char yet 15:58
So in that case + 1 fixing it would make sense
Zoffix FWIW, this is the bytes I'm reading from `cat tehfile`: github.com/perl6/roast/blob/b6fc8e....t#L21-L28 15:59
And when I was golfing those bytes, the SEGV would occur at 4-byte intervals (if I shorten the buf by 1 byte, no segv, 2, 3 bytes, no segv, 4 bytes, SEGV again 16:00
jnthn Yeah, that fits 16:01
So the + 1 is probably right
Zoffix jnthn: as a fix to the bug?
jnthn Yes 16:02
Zoffix Ah, cool
\o/
jnthn (As in, there's a reason for it to be a sensible fix, rather than it just hiding something else)
Zoffix I don't follow actually: "Unless maybe there's a partial byte in the buffer" <-- partial byte? or partial grapheme? 16:06
And if partial grapheme, wouldn't it still be at most 1 grapheme per bytes we got? 16:08
jnthn oh, hah, right. Hmm. 16:11
diakopter I thought you merged a fix to 2158 yesterday 16:14
PR 934
Zoffix diakopter: the fix fixed shortchange on read bytes, but now there's a SEGV 16:15
diakopter oh
xelak6 Zoffix: I have also done some debugging, and it seems that last grapheme of the previous input buffer is always inserted in the current result buffer. That means, the result buffer needs space for an additional grapheme when processing the last input buffer. 16:26
Zoffix xelak6: I'm giving up on this Issue :) Hope you can fix it. 16:28
Zoffix &
xelak6 Zoffix: Increasing the result buffer by 1 should fix the problem anyway ... 16:31
jnthn Argh, I've worked out what's going on 16:54
diakopter Argh 16:55
jnthn The `identity` function gets hot before various things using it
But we log return values and type tuples of parameters as part of the callee's spesh log entries 16:56
But once specialized it doesn't record them
So we end up with a few early unrepresentative values logged
Then identity gets specialized
Then we don't record any more return values
And thus end up with bogus stats, insert a guard that's rarely going to be met based on them, and deopt a load 16:57
dogbert17 is it an easy fix? 16:58
jnthn Not immediately sure
dogbert17 but spesh will be able to do a better job if the stats are correct then 16:59
Geth MoarVM: xelak6++ created pull request #936:
Increase the result buffer size.		 17:02
jnthn Yeah... Well, it's not a new problem, just made obvious when it killed performance of a benchmark I often run :) 17:05
Geth MoarVM: 4ec15fc568 | (Alexius Korzinek)++ | src/strings/utf8_c8.c
Increase the result buffer size.

The last grapheme of the previous input buffer is inserted in the current result buffer. Therefore, the result buffer needs space for an additional grapheme when processing the last input buffer.		 17:09
MoarVM: f700c13420 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/strings/utf8_c8.c
Merge pull request #936 from xelak6/master

Increase the result buffer size.
MoarVM: 91d2878f17 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/strings/utf8_c8.c
Document why we're bumping buffer by 1
 17:11
jnthn I guess we can log the returned type when the caller is being logged and stash it under the return bytecode offset or some such 17:15
But that can be a task for another day :)
Also I guess for things so simple as `identity` we don't want to go specializing them at all 17:17
There's nothing to even specialize
Time for some break/dinner :) bbl 17:20
brrt \o 20:17
jnthn o/ brrt 20:22
masak brrtings 21:02
jnthn Phew, only one more day of ridiculously hot before things get more sensible 22:16
timotimo hooray! 22:24
jnthn: how do you feel about making a distinction in the UI between inclusive and exclusive allocations?
as in, in the current frontend you can only get the exclusive allocations for the exact methods that have 'em 22:25
but in the call graph explorer, there could be more information for that
jnthn inclusive meaning allocations of this + all its callers? 22:30
timotimo callees* 22:31
but yes
jnthn d'oh, yes :D
Big +1 to that :)
timotimo glad to see i'm not the only one who thinks that's worth a lot :)
jnthn Think I've a fix for caller type stats recording 22:32
It looks like it's doing the right thing, anyway :)
Was much easier to come up with here with fresh air blowing in the window than in the hot office earlier on today :) 22:33
timotimo \o/
jnthn haha
4 files changed, 17 insertions(+), 29 deletions(-) 22:34
It's actually *simpler* to do it this way
timotimo nice. is it what you alluded to before you went out for dinner?
jnthn Yeah
Geth MoarVM: 51197804f8 | (Jonathan Worthington)++ | 4 files
Log return value types under the caller's log ID

This means that we still log them if returning from specialized to unspecialized code. Since it's an unspecialized caller that needs the information, this makes a lot more sense. There are situations where a callee called from many places is specialized before various of its callers are. In the worst case (which has been observed happening in ... (8 more lines)		 22:50
timotimo "resoliving" <3 22:51
jnthn Darn it, I read that like 3 times :P 22:52
MasterDuke anyone mind if i merge github.com/MoarVM/MoarVM/pull/935 ? 22:54
jnthn #include "gcc_diag.h" 22:55
What's that gonna do on non-GCC?
timotimo it succeeds in the clang jobs on travis at least 22:56
jnthn What about MSVC?
MasterDuke yeah, src/6model/reprs.c also includes it
timotimo well, appveyor builds it fine 22:57
nqp also does its "make install", but not its "make test" for some reason? was that deactivated?
jnthn yawns 23:02
Will test out that commit on my real example tomorrow at the office :)
timotimo: Does appveyor use MSVC?
timotimo i believe so, yes 23:04
visual studio 2015
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64
compile: cl /nologo /MT /Ox /GL /DNDEBUG /DWIN32 /DAO_ASSUME_WINDOWS98
timotimo assume windows 98 m) 23:05
beautiful
MasterDuke 98se may be the first OS i ever purchased 23:06
MasterDuke either that or a red hat 23:07
travis-ci MoarVM build failed. Jonathan Worthington 'Log return value types under the caller's log ID 23:09
travis-ci.org/MoarVM/MoarVM/builds/413822384 github.com/MoarVM/MoarVM/compare/9...197804f823 23:10
jnthn season-lab.github.io/papers/osr-dis...pldi18.pdf 23:49
timotimo jnthn: i'd like to expose the managed size of types in the profile, any objections? 23:52
jnthn No :)
timotimo gnite jnthn :) 23:58
jnthn timotimo: btw, I didn't read that paper yet by it may be applicable to profiling application/unapplication 23:59
(Read properly, at least :)
'night

Powered by Cro and the Raku® Programming Language.

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

Thank you!