00:32 tokuhiro_ joined 02:33 tokuhiro_ joined 02:48 ilbot3 joined 04:33 vendethiel joined 04:35 tokuhiro_ joined 05:59 xiaomiao joined 06:36 tokuhiro_ joined 06:57 FROGGS joined 07:03 domidumont joined 07:08 domidumont joined 07:26 tokuhiro_ joined 07:28 flaviusb joined
nwc10 good *, #moarvm 08:00
diakopter o/ nwc10
08:22 zakharyas joined, domidumont joined 08:24 Ven joined 08:31 tokuhiro_ joined 08:48 Ven joined 09:32 tokuhiro_ joined 09:39 Ven joined
jnthn moarning o/ 09:46
hoelzro: By "common callsite" you probably mean "interned", and there's a flag for that. 09:47
09:49 kjs_ joined 10:05 zakharyas1 joined 11:21 dalek joined 11:22 dalek joined 11:34 tokuhiro_ joined 11:45 Ven joined 12:04 kjs_ joined 12:32 Ven_ joined 12:45 kjs_ joined 13:14 brrt joined
brrt good * #moarvm 13:15
jnthn o/ brrt 13:27
brrt \o jnthn 13:32
13:34 zakharyas joined 13:35 tokuhiro_ joined
hoelzro jnthn: ah, thanks! I didn't notice that 13:51
good moarning all!
14:04 domidumont joined
brrt good * hoelzro 14:19
14:37 tokuhiro_ joined
timotimo diakopter: to be honest, if the spec tests all succeed, i don't think you need to hold back that one-line patch :) 14:37
14:49 Ven joined
diakopter brrt: hi! 15:28
timotimo: well, [as jnthn mentioned in privmsg] it's suspect that it helps, since an object should already have that set when it is assigned to an SC to be serialized 15:29
timotimo oh?
diakopter I'm still looking for the exact right place to ensure it's set correctly as intended 15:30
brrt hi diakopter
desginish question again
jnthn Could it be that we don't set the fast lookup thing when deserializing?
diakopter O_O
well I looked there, but I'll look again
I thought I fixed it, but it caused another problem [which may be indirectly related or unrelated] 15:31
diakopter feels determined to solve it!
timotimo it definitely looks like a juicy target
diakopter jnthn: but all the wastage is when getidx is called from nqp code, so it's for when objects are being serialized 15:32
(as supported by the evidence that the improvement is almost entirely in mast/optimize phases
)
brrt labels are inserted, currently, during inorder traversal 15:34
diakopter well, I suppose it's a remote possibility it's for a very few extremely-hot items that were deserialized from the bootstrap
(which would make it an even awesomer improvement opportunity!) XD 15:35
brrt when inserting them in the tile list, shall i, a): make special-purpose magic tiles, or b): insert markers for the compiler to tak eover
i kind of like the markers idea, myself...
diakopter me2
timotimo also me 15:36
seems a bit more explicit and probably not costly in terms of performance, eh?
diakopter by beer? 15:37
jnthn haha 15:39
timotimo performance by beer? 15:40
jnthn
.oO( Beer pressure )
diakopter FROGGS' quit message
lol beer pressure
10:37 -!- FROGGS [~froggs@p54BF18C2.dip0.t-ipconnect.de] has quit [Quit: Connection reset by beer]
timotimo ah, hehe 15:41
diakopter (for the online clog
timotimo my weechat filters out joins/parts in many cases
diakopter aha! 15:42
jnthn: found it 15:43
how do I tell make spectest to use https for cloning 15:44
timotimo oof
well, if you manually git clone, it should just use that; otherwise GIT_PROTOCOL in env? is that something we invented or does git itself support that?
hoelzro I think that's something we introduced 15:45
diakopter the spectest checkout doesn't respect --git-protocol to Configure 15:47
GIT_PROTOCOL doesn't work either
sigh
fixing I think 15:48
hoelzro you can use git's proxy options, but that unfortunately isn't terribly simple 15:49
timotimo doesn't sound so good
hoelzro you could also try Git's URL rewriting feature
something like git config url.https.insteadOf = git 15:51
brrt yeah, inserting markers isn't costly, 15:52
16:02 kjs_ joined
diakopter *grumble* *grumble* 16:18
16:20 vendethiel joined
dalek arVM/cache_sc_idx: dab9af8 | diakopter++ | src/6model/s (2 files):
write sc idx when deserializing, repossessing, and preparing to serialize
16:34
diakopter jnthn: take a look at that branch?
jnthn diakopter: Will do after current thing I'm working on :) 16:35
Or while current thing spectests...
16:36 zakharyas joined
dalek arVM/cache_sc_idx: 192a79e | nicholas++ | src/6model/serialization.c:
Bump minimum serialization format version.

Now that we've rebootstrapped, we no longer need the code to read older serialization versions.
Again, mostly removal of if statements with ...->root.version checks, and re-indenting because of the blocks this eliminates.
16:37
arVM/cache_sc_idx: 47ab6f3 | hoelzro++ | src/strings/utf16.c:
Resize buffers as needed when taking a UTF-16 substring
diakopter merge.. 16:38
16:38 tokuhiro_ joined
ilmari hoelzro++ # UTF-16 buffer resizing 16:38
ilmari was hoping someone else would do that ;) 16:39
hoelzro =)
ilmari has a nagging feeling there's some serious refactoring potential between all the MVM_string_*_encode_substr
functions
modifying them was very repetititive 16:40
timotimo diakopter: i thought "hey, maybe it's a reposession problem" while AFK, but it seems like you've already considered that properly
diakopter timotimo: \o/
timotimo i mean ... just looking at the commit message, not the actual diff
but it seems like you were a couple of commits behind from master?
diakopter Stage start : 0.000 16:41
Stage parse : 46.536
Stage syntaxcheck: 0.000
Stage ast : 0.000
Stage optimize : 6.803
Stage mast : 12.416
Stage mbc : 0.257
real1m6.150s
user1m5.103s
sys0m0.928s
urp
timotimo didn't you say you were at about 70 seconds of build time before? 16:42
diakopter the original best was 72 seconds 16:44
so, 66.1 seconds is a big improvement 16:45
timotimo oh! 16:46
\o/
diakopter (yes, spectest clean)
don't know about rebootstrap clean though XD XD
dalek arVM: 8380116 | jnthn++ | src/core/frame.c:
Context-captured frames should remember caller.

Otherwise we cannot traverse it later.
17:19
arVM: 308b9b7 | jnthn++ | src/core/interp.c:
Re-use MVM_frame_context_wrapper for nqp::ctx op.
timotimo 58.69user 0.39system 0:59.06elapsed 100%CPU -> 56.74user 0.38system 0:57.10elapsed 100%CPU 17:20
turns stage mast from 12.136 to 10.518 17:21
diakopter try a few runs ;)
I get like 4-5% variation either way 17:22
timotimo wow
oh, i still had your one-line patch 17:29
silly me
now the difference is much more pronounced! 17:31
17:31 tokuhiro_ joined
timotimo 1:05 is the actual before-time. 17:32
jnthn gets on to reviewing the patch :) 17:33
diakopter: Patch seems good to me; will cherry-pick and test locally :) 17:37
make test fails :( 17:42
(In Rakudo
All the nativecall tests seem to segfault
diakopter did you make clean :S
jnthn yes.
:(
diakopter well spectest was fine :S
jnthn Clean nqp, make install that, clean rakudo,make install that
Does make test work out for you? 17:43
diakopter yah but I haven't pulled the last two things you just did 17:44
jnthn Seems to be a mis-compile 17:45
Reverting the patch and make test again didn't clear it up; removing NativeCall.pm.moarvm and rebuilding that and make test passed 17:46
Dinner time; bbl :) 17:48
nwc10 curry? :-)
jnthn No :) 17:50
diakopter maybe make clean doesn't delete NativeCall.pm.moarvm 17:51
jnthn That'd cause an error always 17:53
(Wrong version)
diakopter oh
jnthn (As in, compiled against wrong version of setting) 17:54
So I don't think it's that
diakopter curious
17:59 FROGGS joined
diakopter FROGGS: lol at your quit message 18:01
FROGGS *g*
tadzik kekeke 18:08
ilmari hoelzro++ # rakudo now passes 'make test spectest' with moarvm compiled with ASAN 18:34
18:36 xiaomiao joined 18:43 kjs_ joined 18:54 domidumont joined 19:21 leont joined 19:25 zakharyas joined 19:26 diakopter___ joined 19:30 diakopter___ joined 19:33 tokuhiro_ joined 19:54 diakopter___ joined 20:01 zakharyas joined
dalek arVM/cache_sc_idx: 8380116 | jnthn++ | src/core/frame.c:
Context-captured frames should remember caller.

Otherwise we cannot traverse it later.
20:01
arVM/cache_sc_idx: 308b9b7 | jnthn++ | src/core/interp.c:
Re-use MVM_frame_context_wrapper for nqp::ctx op.
arVM/cache_sc_idx: e325b48 | (Matthew Wilson)++ | src/core/ (2 files):
Merge pull request #304 from MoarVM/master

merge from master
20:40 diakopter___ joined
hoelzro the more I use valgrind, the more I love it 20:42
20:42 mtj_ joined
arnsholt I attribute my very good grade in a network communications course to already knowing about valgrind 20:43
That, and the fact that my laptop at the time was a PPC Mac, which meant that any slipup with network order/host order was immediately highlighted when I tested things between my x86 desktop and PPC laptop
Callgrind is pretty awesome too 20:44
hoelzro yeah, I realized I've only scratched the *grind surface 21:10
21:14 zakharyas joined
dalek arVM: 83b3ae3 | brrt++ | src/core/frame.c:
Dynvar lookup check if we're using the JIT code

For some reason, we sometimes 'drop out' the jitcode, into the spesh code, and I can't really find out why. But checking if this is the case fixes the long-standing panda bug.
21:22
jnthn \o/ 21:23
brrt++
So hard bug. So small patch. 21:24
(A good sign. Means you probably fixed the real bug.)
21:26 brrt joined
brrt yes, finally gone :-) 21:27
(long time bus trips are good for something, at least)
jnthn :)
brrt although, it is mysterious to me why we'd have a spesh cand, the spesh cand have jitcode, and the frame not being on the jitcode - but on the spesh code 21:28
any idea on how that might happen? 21:30
jnthn No...it's really odd 21:33
brrt doesn't seem to be related to OSR, or anything like that 21:34
jnthn But could be interesting to know in so far as it'd mean we're not using the JITted code when we could, and so may be losing out
brrt hmmm
jnthn And deopt would go to the unspesh'd done, so I can't see it being that either...
brrt also doesn't seem to be happening during deopt, or we should find deopt crashing much more often 21:35
21:35 tokuhiro_ joined
brrt i mean before deopt 21:37
maybe worthwhile to check within-rangeness of jit entry label at points where we use it 21:38
anyway, i'll be off tonight, sleep well and all that :-) 21:39
jnthn Yeah, me too soon 21:40
Crazy early start
:( 21:41
brrt sleep well :-) 21:42
jnthn Thanks, you too! o/
22:15 colomon joined
hoelzro should unicode_property_values_hashes live on the interpreter object instead of static memory? valgrind gets pretty mad that we don't clean up after it =/ 22:21
22:22 mtj_ joined 22:36 diakopter___ joined
diakopter___ yah it should be cleaned up 22:38
hoelzro diakopter___: do you think it should be moved under the interpreter object? otherwise cleanup could get messy in a multiple interpreter environment 22:45
diakopter___ hoelzro: well, the MVMInstance, since it's all unchanging data, right? 22:53
hoelzro ah, yes
diakopter___ oh, you mean multi-Instance
hoelzro yes
but one per instance (vs one per TC) should be fine, yes? 22:54
diakopter___ I guess the way to do it is make a protected (atomic) refcount of such shared global things
so that the last instance alive can clean it up
(where that atomic counter is also global) 22:57
hoelzro so even multiple MVMInstances should share that object? I suppose that would cut down on memory usage quite a bit 23:00
diakopter___ yeah, I think it's worth doing at some point. seems like a quick task 23:02
hoelzro maybe I'll get a round tuit tonight 23:03
diakopter___ obviously it would happen behind the scenes of MVMInstance creation (person writing code to link with libmoar and run multiple instances wouldn't need to worry about this)
hoelzro right 23:04
just a part of create/destroy
timotimo Writing profiler output to profile-1448149404.2365.html 23:08
===SORRY!===
KnowHOW methods must be called on object instance with REPR KnowHOWREPR
i wonder where this comes from :|
hoelzro =/
23:16 colomon joined 23:37 tokuhiro_ joined