00:00 cognominal joined 00:32 cognominal joined 01:31 FROGGS joined 01:56 FROGGS joined 04:10 FROGGS joined 05:16 jnap joined 06:16 jnap joined 06:35 cxreg joined 06:47 FROGGS joined 07:08 zakharyas joined 07:17 jnap joined 08:18 jnap joined 08:41 lue joined
nwc10 jnthn: mininal ASAN failing test case: paste.scsys.co.uk/362486 09:16
fails to get to the second say
no idea why ASAN is adamant about:
0x600800396f6c is located 28 bytes inside of 40-byte region [0x600800396f50,0x600800396f78)
but I think that that might be the clue
09:19 jnap joined
jnthn nwc10: Yeah. Don't immediatley see what's going on there. Hmmm. 09:21
freed by thread T1 here: #0 0x7ffff4e6347a (/home/nicholas/Install/gcc482/lib64/libasan.so.0.0.0+0x1547a) #1 0x7ffff4551eaf (/home/nicholas/Sandpit/moar-san/lib/libmoar.so+0x2f8eaf) 09:23
nwc10 yes, I can't get that trivially from ASAN 09:24
jnthn There's not a way to get that mapped to a human-readalbe file/line, is there?
ah, ok
nwc10 building ASAN-free to use valgrind
maybe 15 minutes until I can answer that
and I still haven't got to the hammock yet
jnthn Just trying to figure out if it's ctx that's bad or ctx->callsite 09:25
Looking at the addresses, I guess ctx->callsite
nwc10 I think that it's the latter, but has_flattening has the wrong offset 09:26
jnthn: paste.scsys.co.uk/362496 09:30
if (storage) free(storage); /* not thread-safe */ 09:32
that's line 1134 of ops.c
which really really isn't a callsite
but the problem may well be "It's not thread-safe."
like 1094
er, line 1094
I'm not sure *how* it ends up correctly freeing something totally wrong 09:33
jnthn Sorry, ahd phone call 09:40
One that told me my May will be an iota less stressful than first expected. :)
FROGGS less stressful outside of this channel :o) 09:41
jnthn nwc10: wtf??!!!
I don't even...
The only thing I can imagine is that an object is unmarked, we look into it, and pull out a completely arbitrary memory address...somehow. 09:42
nwc10 jnthn: I'm agreeing with the wtf??!!ā€½āø˜ELEVEN etc
FROGGS .oO( how could this have ever worked? ) 09:43
nwc10 oooh, !!ā’’
and some other stuff I don't have fonts for
FROGGS "ELEVEN etc" <-- *g*
nwc10 FROGGS: I'm assuming that the comments predicting doom, gloom, lack of thread safety, old ones, etc are reasonably accurate 09:44
and it's to do with crossing the streams. Er, using more than one thread
but I can't see *how*
jnthn Probably but...I think in this case it's doing it in a place where the thread is the only owner of the string in question...
nwc10 Unicode++ # does not yet have a "spinner" character, let alone one that a terminal would animate 09:45
I hope I don't give them ideas
jnthn shhh! :P 09:46
nwc10 jnthn: helgrind has a *lot* to say: paste.scsys.co.uk/362510 09:50
I'm not experienced with helgrind, so I can't offer any advice on what it's saying 09:52
I have Rakudo at ff04467628de2a004489ef31fdb8eb745c31f141
nqp at b596f16f9ecfb413fe7b11a576ec562c23046622
MoarVM at 405b1ec9a67131dcec363bdba982161936a2c1c0
jnthn if (++static_frame_body->invocations >= 10 && callsite->is_interned) { 09:53
nwc10 and that was helgrind from valgrind-3.8.1
jnthn /* Rough call count. May be hit up by multiple threads, and lose the odd
* count, but that's fine; it's just a rough indicator, used to make
* decisions about optimization. */
MVMuint32 invocations;
:)
nwc10 OK.
ideally would be a nice to have an optional way to build that is strictly correct 09:54
I think technically it's also possible to do a suppression file
jnthn *nod* 09:55
Some of them may be legit, of course.
nwc10 was going to try to suppress just that one
dalek arVM: 0487e37 | jonathan++ | / (8 files):
Add MVMNull REPR, instance->VMNull.
 10:06
arVM: 2de460c | jonathan++ | src/6model/reprs/MVMNull.h:
Add static inline func for doing a VM-null check.

Lazily allocate lexical containers.
This means that most of the time we won't allocate $/ and $!, and perhaps $_ too, when they are never used.
10:06 dalek joined 10:19 jnap joined 10:33 dalek joined 11:06 donaldh joined 11:13 donaldh joined 11:20 jnap joined 12:21 jnap joined
nwc10 jnthn: seems that only 6 of the helgrind complaints are about that one 12:38
13:22 jnap joined 14:22 jnap joined 14:24 donaldh joined 14:31 jnap joined
timotimo sounds like i ought to start a benchmark run soon, eh? :) 15:03
jnthn timotimo: go for it :) 15:08
walk, pondering stuff & 15:16
timotimo bon marcher
nwc10 jnthn: you're determined to continue an endangered skill? www.bbc.co.uk/news/magazine-27186709 15:31
japhb jnthn: Where is the current version of the rakudo-nqp-backends layering block diagram? I'd like to use it in my talk-in-progress, if that's OK .... 15:39
jnthn nwc10: I actually walk pretty often in cases where I could hop on public transport for a couple of stops. :) 15:48
japhb: Not quite sure what diagram you mean, unless it's one I've done in a talk sometime, in which case it's been a while... 15:53
timotimo jnthn: should i manually bump the moar revision in nqp and the nqp revision in rakudo to get the benchmark data? or should i trick p6bench into building master again? :) 15:56
jnthn timotimo: Whatever's easiest for you. It seems to not regress spectests. 15:59
timotimo faked it
FROGGS japhb: I think you mean one from the talk given at YAPC::NA 2013, and that talks was given by pmichaud I think 16:01
japhb FROGGS: Huh, I thought jnthn gave the most recent one. Ah well. 16:05
jnthn: I was talking about the one that shows what parts of the stack are Perl 6, what's NQP, and what's VM specific. 16:06
FROGGS japhb: this? youtu.be/XgPh5Li3k4g?t=24m58s 16:07
nwc10 jnthn: HEAD/HEAD/HEAD~2 works on "my" machine, apart from previously known fun 16:27
japhb FROGGS: Now that I'm near sufficient bandwidth not to annoy my peers, I took a look. Yes, that's the correct diagram -- but that was from before MoarVM was added to it. 17:11
I'm looking for one after MoarVM became "official".
FROGGS hmmm, maybe jnthn knows any of his slides where that is in :o) 17:13
17:15 LLamaRider joined
japhb FROGGS: I've looked through several of his most recent Rakudo and MoarVM decks, and didn't see one new enough. 17:21
Hmmm, I wonder ...
17:22 LLamaRider joined
japhb Gah, not in the internals course, either. :-/ 17:23
jnthn japhb: Yeah, I don't remember doing a recent one of those. 17:33
timotimo jnthn: t.h8.lv/p6bench/2014-05-01-vmnull.html - we can't quite stop doing the optimization thing just yet 18:18
jnthn: please don't ask me why some of the benchmarks start out very slow 18:21
FROGGS timotimo: can I ask why there is no rakudo/nom and no perl5 included? :P 18:22
I can only read benchmarks when I can compare something 18:23
timotimo hmm
rakudo/nom is eager_vivification
FROGGS ohh
timotimo nom/master/master is lazy_vivification
18:51 btyler joined 18:52 daxim joined
japhb jnthn: Is there editable source for that block diagram I was asking about earlier, like an SVG file? Maybe my best course of action is just to update it. :-) 20:11
jnthn japhb: For Pm's, maybe. Mine was drawn in Powerpoint...
timotimo jnthn: what's the next amazing optimization opportunity? 20:21
if we introduce a fact KNOWN_NONNULL, we can optimize these isstr, islist, ... things away
FROGGS timotimo: implement labels for jvm to optimize user experience? *g*
lizmat timotimo: perhaps low hanging fruit, but there is a candidate for slice :delete access in sink context 20:27
look for :$SINK! in array_slice / hash_slice.pm 20:28
timotimo i'll keep it for #monday :) 20:29
21:09 lue joined
japhb #monday? Are you just referencing p6weekly in a general sense, or does the '#monday' tag now do something special? 22:22
timotimo it doesn't do something special 22:28
except for this very case i'll probably search for it :) 22:29
22:52 colomon joined
dalek arVM: 4050a53 | jnthn++ | src/core/frame.c:
Optimize frame allocation.

Use calloc rather than malloc + memset.		 23:08
arVM: ca47831 | jnthn++ | src/core/frame.c:
Remove unrequired memory barriering.

We didn't expose the frame anywhere else at the point we set these, so no need to barrier.
jnthn timotimo: One thing that may help a bit is to teach spesh about nqp::can 23:10
timotimo oh! aye
jnthn Just looking at the forest fire C-level profile and can is actually the leading cause of hash lookups...
timotimo 16/43 benchmarks for rakudo-jvm >_> 23:11
jnthn Yeah, and goalposts moved again. 18b7e2e I just did in Rakudo got me a 5%-10% improvement on ff.
timotimo would people mind if i set up a public gobby server on raduko.org or something like that?
oh dang!
er, but what's ff?
jnthn forest fire 23:12
timotimo i forgot what perl6 server i had access to and with what username and ssh key >_<
oh, that's good!
jnthn Reducing GC pressure will only help so much in forest fire, it seems... 23:15
'cus it's already down at around 12.5%
timotimo 12.5% what? 23:16
time spent in the gc?
jnthn Of runtime.
timotimo ah
yes, we want to get that back up to 50% while keeping the gc run time constant :)
jnthn Which as things go is quite good.
timotimo aye
jnthn I've been doing some pondering on spesh
I think I'm going to give it a "logging"/"data-collection" pass 23:17
So it can gather a load more info, that it can use to make guarded assumptions.
Also thought a bit about your "can haz spare register" question.
timotimo that sounds good 23:18
got an answer yet?
jnthn I wondered if the simplest way isn't to simply reserve some extra space after the arg buffer
Currently we have
->work pointing to a block of memory like | ...locals... | ...space to put args when calling... | 23:19
We could sneak an extra pair of registers after that.
One you can use for a .o/.s, the other for a .i/.n
For inlining, I realized the easiest way is to just concatenate the chunks. 23:20
'cus then it's dead easy (memcpy) to grab them out when we de-opt 23:21
timotimo oh?
well, that sounds lovely
jnthn Writing the deopt bit of inlining is going to be "fun"...
In so far as if it happens, we'll need to make the frames we optimized away suddenly start existing. 23:22
timotimo ah, yes
jnthn I also realized that "how do we get stacktraces right when we've inlined" can be dealt with by just de-opting. 23:23
timotimo aye 23:24
23:40 lue joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!