01:19 statisfiable6 joined, benchable6 joined
samcv yay. new script to generate the collation C data is much better and shorter and cleaner 01:20
seems to work at least. i have more failures but i quickly checked some of the multi cp sequences and they seem to have passed to i'm guessing the data must be right
uhm maybe not quite. well getting closer :) 01:24
01:52 ilbot3 joined 03:06 eater joined
Geth_ moarvm.org: CharleyPeng1++ created pull request #6:
Update roadmap.html		 05:24
05:39 brrt joined
samcv reading the "Avoiding Normalization" section of the unicode documentation 05:58
some of these failing are failing because a decomposed character gets different collation keys than a composed one. and so the test is relying on it getting the decomposed ones
"LATIN CAPITAL LETTER U WITH HORN" + "COMBINING TILDE OVERLAY" compared to "LATIN SMALL LETTER U WITH HORN AND ACUTE" + "COMBINING TILDE OVERLAY". in unicode, there is a specific order that accent marks go after a character. so the ones closest to the letter go closer to the letter and the ones that are higher/lower than really close to the letter come after based on the canonical combining class of the accent character 05:59
and so because it's a letter U with a horn and acute. it can't reorder the combining tilde overlay because the horn and acute are part of the codepoint
brrt good * samcv 06:05
samcv hey :-)
brrt re: perl6 popularity 06:06
at $work, i may have gotten some people enthusisastic about perl6 and moarvm
samcv going to try decomposing all decomposable characters and just see what happens... then try and figure out what to do about the issue since i don't want to decompose everything 06:07
nice!
weird. so i'm looking at this and the order of the codepoits they list is not in sorted order. so i don't know 06:18
this is confusing
brrt hmm, that's odd 06:19
samcv maybe i'll just ignore that test i dunno
i'll igore it for now at least
06:38 lizmat joined 06:41 brrt joined 06:46 domidumont joined 06:52 domidumont joined 07:19 TimToady joined 07:43 zakharyas joined 07:54 AlexDani` joined
nwc10 jnthn: (as best I can tell from skimming the spectest harness end summary) ASAN makes no comment on moar-frame-extras 07:58
08:01 AlexDani` joined
jnthn nwc10: Yay, good to hear :) 08:51
yoleaux 08:09Z <lizmat> jnthn: any thoughts on the performance difference between "1".match(/1/) and 1.match(/1/) ? ( easily seen in a for ^10000)
Geth_ moarvm.org: 5627a7f16f | CharleyPeng1++ (committed using GitHub Web editor) | roadmap.html
Update roadmap.html
 08:52
moarvm.org: a842bc0de7 | (Jonathan Worthington)++ (committed using GitHub Web editor) | roadmap.html
Merge pull request #6 from CharleyPeng1/patch-3

Update roadmap.html
jnthn 2 more steps to go on the "easy" MVMFrame wins 08:57
Which will give a pointer reduction each
So far 40 bytes (on 64-bit) saved, and callgrind reckons 295 million instructions less during CORE.setting compilation
brrt nice 09:10
the bug density in the prepare_arglist_and_call is humbling...
09:16 zakharyas joined
Geth MoarVM/frame-extras: bddafb2452 | (Jonathan Worthington)++ | 5 files
Move continuation tags into frame extras.

A very small number of frames have them.		 09:20
MoarVM/even-moar-jit: 6b7bdd2a9d | (Bart Wiegmans)++ | 2 files
Stack transfers don't count for toposort

Not that it had any effect, but we thought we needed to do more moves than we really did. And also remove the auto-scheduling of the call/arg resolution, because these will be handled by the free- edges loop a few lines lower anyway.		 09:27
MoarVM/even-moar-jit: 4374536973 | (Bart Wiegmans)++ | src/jit/linear_scan.c
Store range start and end in struct

Not only does this save us from recomputing, it doesn't cost any additional storage, since the synthetic-tile position markers are now redundants.
MoarVM/even-moar-jit: fee7630082 | (Bart Wiegmans)++ | src/jit/linear_scan.c
Extend ARGLIST children range to include CALLL

This prevents us from allocating a value for registers used by CALL that would overwrite a value still used in ARGLIST. Conceptually, an ARGLIST child should be live until the CALL, because it is still in use .
brrt this makes even-moar-jit work on windows
jnthn brrt++ 09:30
Geth MoarVM/frame-extras: 2bd3bd8b0b | (Jonathan Worthington)++ | 3 files
Move invoked_call_capture to frame extras.

It shows up quite rarely.
jnthn Total savings up to 56 bytes
Currently getting a measure of the ratio of frames that cache a dynamic lexical 09:32
nine jnthn: wow, almost a full cache line 09:45
jnthn About 4.5% of frames have a dynamic lexical cached on them 09:51
That's during CORE.setting compilation
Which is something I'd expect to be among the higher users of the cache 09:52
Guess that means it makes some sense to move it 09:54
samcv yay 65 failing tests now :) 09:59
down 5
jnthn :) 10:04
samcv++
Geth MoarVM/frame-extras: 659c68b35d | (Jonathan Worthington)++ | 6 files
Move dynamic lexical cache to frame extras.

Less than 5% of frames in CORE.setting compilation use this. The 95% can save at least 16 bytes per call frame.		 10:09
jnthn I think throw_address can go away also, saving a further 8 bytes 10:13
Then I'll re-order things and I think we can squeeze another little saving out of needing less padding 10:14
brrt hehe, just about 12 merge conflicts between spesh-worker-master and even-moar-jit :-) 10:20
jnthn Not bad given you're merging a 3-digit number of commits :) 10:21
10:22 zakharyas joined
brrt :-) 10:24
so far nothing really ugly, just git being confused
i'm thinking of a better jit logging / debugging 'framework'
or rather
i'd like to be able to have very verbose JIT output for a select few frames, and very little output otherwise 10:25
and i'd be okay with those frames selected as env vars or during compile time as definitions
Geth MoarVM/frame-extras: 9c3a640d46 | (Jonathan Worthington)++ | 5 files
Eliminate throw_address from frames.

The information can instead be stored in exception objects, which is where it belongs anyway.		 10:27
MoarVM/frame-extras: 19cf730ee4 | (Jonathan Worthington)++ | 3 files
Force MVMReturnType to be a single byte.

This, with a little re-ordering, saves another 8 bytes (on 64-bit) off MVMFrame, partly by its own size reduction and the rest from no longer needing a padding hole.		 10:39
jnthn I think that's all the size reduction we can reasonably have
We could pay an extra indirection every time we access the spesh slots but I don't know that it's worth it, 'cus we can need them quite often 10:40
10:47 solarbunny joined 11:17 brimonk joined
Geth MoarVM/frame-extras: b15874e816 | (Jonathan Worthington)++ | src/core/args.c
Toss never-used nameds re-use logic.

We never re-use frames any more, so we can never re-use this either.		 11:20
MoarVM/frame-extras: 994a757ad7 | (Jonathan Worthington)++ | src/core/frame.c
Eliminate need to memset MVMFrame.

With many things moved off to extras, nearly every remaining member of MVMFrame is set by the invocation sequence. Zero/NULL the handful of remaining things that need to be (many conditionally) and eliminate the memset. In CORE.setting compilation this will save about 79 million calls to memset (one per frame invocation).
brrt here's hoping the merge was right 11:23
jnthn :)
Righty, time for lunch, and callgrind can do some measuring on my changes this morning to see what it makes of them :) 11:24
Back 12:02
callgrind not done yet
But getting there 12:03
oops, I think I mighta misread what a column was when I wrote that 79 million 12:12
ah no, seems it was right 12:13
Aww, instruction count is up :-( 12:15
brrt :-( 12:19
(okay, building rakudo on even-moar-jit-merged 12:20
jnthn Does shave a couple of megs off CORE.setting memory use though, guess just out of every closure being smaller 12:46
[Coke] jnthn: are all instructions created equal?
jnthn [Coke]: No 12:47
And memory accesses sure ain't 12:48
It's also not up by much
I was just hoping it'd be down a bit is all
Also the cache use improvements are worth something too 12:52
[Coke] mm 12:55
jnthn Hm, oops, I introduced a small leak also 12:57
So that couple of megs off low-balls it
brrt i'm getting abort on my merged build... 13:22
13:31 AlexDani` joined
brrt jnthn, i get aborts on the multi-cache-add thingy 13:33
panic!
or something
jnthn o.O 13:34
That's...odd
brrt aye
jnthn I didn't touch that part, I don't think
brrt let's try with a clean master..
jnthn While I wait for a fresh callgrind, been having a crack at not allocating a byte array for the named args used thing 13:39
Or rather, only doing that if there's > 64 of them
And otherwise using a bit field
Turns out that manually NULLing the extras entries, 'cus there's various of them, comes out worse than just calling memset 13:40
Seems the named used bitfield thingy works 13:48
Geth MoarVM/frame-extras: dbad6b8c41 | (Jonathan Worthington)++ | 2 files
Remove historical, now-unrequired, nullings.
 13:55
MoarVM/frame-extras: 743796be4a | (Jonathan Worthington)++ | 5 files
Use a bit field for named args used when possible.

When there only 64 named arguments, we can use a bit field instead of allocating a byte array. This saves an allocation, a memset to zero it, and a free, in pretty much every use of named arguments (we have to handle the case where there are more than 64 of them, but it is likely incredibly rare).
jnthn Alright, I think that's all I'll do in this branch. Even that last commit is a bit of a stretch for the scope of the branch :) 13:56
jnthn merged it 14:06
Geth seems a bit shy to report it :)
Geth MoarVM/master: 11 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/d...743796be4a		 14:07
brrt the abort happens when the pthread_mutex_unlock fails, which happens (probably)because a different thread from the one that owns it unlocks it 14:09
timotimo damn 14:10
brrt no, why? 14:11
timotimo hm, how do we fare when you have a lock.protect around an await in v6.d?
brrt (i mean, don't say 'damn', say 'why?' :-))
timotimo hah
jnthn timotimo: Badly, I think; Lock.protect should really declare my $*AWAITER to be the blocking one
timotimo why, brrt? :)
brrt i have no idea :-P 14:13
so, i'm consistently seeing a failure in t/nqp/105-multicache.t 14:14
on OS X
timotimo damn :)
brrt that is on master, as well on even-moar-jit-updated-to-master
jnthn o.O
I think I did touch that to ensure it always locks 14:15
Rather than having the "maybe lock" branch
brrt well, it appears to try and unlock on a differen branch 14:16
gist.github.com/anonymous/5d25ac82...cc3610507a 14:17
jnthn ohh 14:18
huh, this musta been busted in any multi-threaded app before now
brrt which is now all of them :-) 14:19
(i do wonder what 'this' exactly is)
jnthn Odd now it never whined off OSX
dogbert17 jnthn: do you need to use a branch from rakudo/nqp in order to use your latest changes? I'm getting 'src/vm/moar/ops/perl6_ops.c:731:18: error: ‘MVMFrame’ has no member named ‘special_return’ when trying to build rakudo
Geth MoarVM: 6a1c6e871e | (Jonathan Worthington)++ | src/6model/reprs/MVMMultiCache.c
Don't release lock before we acquired it.
jnthn dogbert17: yes, the branch in Rakudo moar-frame-extras
Will bump and merge shortly 14:20
brrt: Try that :)
dogbert17 cool, I'll wait then :)
jnthn Just waiting for a callgrind run to finish
dogbert17 hoping for big improvements?
brrt jnthn: that fixes it 14:21
jnthn yay :)
brrt \o/
jnthn dogbert17: Not massive, but something :)
I mean, a should be avoiding a load of allocations 14:22
*it should
dogbert17 sounds like a win to me 14:24
timotimo it won't single-branchedly make your code blazing fast, but it'll be nice 14:27
14:37 lucasb joined
jnthn Yeah, lowest instruction count I've seen on it today 14:41
By some 300 million instructions
jnthn also has another patch for NFA stuff that he stashed away a couple of days ago to try out 14:45
I'll measure that, and then afterwards will do revision bumps 14:49
dogbert17 o.O (a hidden patch)
jnthn I stashed it away 14:50
Oh, I said that
Got distracted by other bits :)
But it in theory cuts out a very expensive memset
dogbert17 so even more instructions could be saved 14:51
jnthn Yup 14:53
Well, here goes callgrind again
timotimo jnthn: i have a branch that applies memory pressure on string operations. want me to merge it? 15:02
jnthn Ummm
Maybe in a day or two? I'm worried that the bump I'm about to do bring in some really huge amount of changes 15:03
timotimo github.com/MoarVM/MoarVM/commit/bb...6d54f7b9fd
jnthn Not sure we want to add more to that pile :)
timotimo right
15:05 brrt joined
brrt dunno if geth has told you yet, but i've just pushed the merge with master 15:06
by the way 15:16
jnthn++ for awseome work on spesh
jnthn Another 14 billion instructions off for the NFA improvement :) 15:36
Geth MoarVM: 6941cada41 | (Jonathan Worthington)++ | 2 files
Improve NFA memory performance.

We only need 32-bit arrays, not 64-bit ones; we'll never have an NFA with billions of states! Even with that, the `memset` of the
  `done` array turned out to account for a ghastly number of CPU cyles.
Since in most cases we get just in the single digits of things set to `done`, it's cheaper to use an array for that and do lookups in it.
There are probably some further wins to be had in this area, but in the meantime this gets 5% of the CPU cycles off the compilation of CORE.setting.		 15:40
[Coke] Nice. 15:49
15:52 lizmat joined 16:20 domidumont joined 16:21 zakharyas joined
nine "we'll never have an 16:45
NFA with billions of states!" famous last words ;)
Geth MoarVM: 86b70a2736 | (Jonathan Worthington)++ | src/core/interp.c
Only log decont value when we did a decont.
 16:49
nwc10 jnthn: twice now during parallel nqp tests: 16:58
MoarVM panic: Internal error: invalid thread ID -1094795586 in GC work passt/nqp/076-capture.t .................... Dubious, test returned 17 (wstat 4352, 0x1100)No subtests run
thank your irssi
newlines - om nom nom
but reliably passes when run alone 16:59
jnthn Urgh, wonder what's caused that
Home time now though, so will investigate tomorrow.
nwc10 "me too" but I'm also wondering "why can't I replicate this and give you a better backtrace"
hope there's no congestion on your commute :-) 17:00
jnthn The biggest congestion risk is having to walk past the pub :)
nwc10 oh, that's sort of like taking the children from here to the granparents
250m can take 30 minutes, as there is a playground midway
jnthn :-) 17:01
jnthn wanders home for dinner
17:03 AlexDani` joined 17:35 committable6 joined, bisectable6 joined, greppable6 joined, evalable6 joined, coverable6 joined, unicodable6 joined, benchable6 joined, statisfiable6 joined 18:10 evanm joined 19:01 dogbert2 joined
dogbert2 oops, SEGV when running t/spec/S15-nfg/many-threads.t 19:05
trying a few more times the error is now "Invalid owner in item added to GC worklist" 19:07
timotimo sounds like you had GC debug on there? 19:09
dogbert2 :) 19:10
timotimo: gist.github.com/dogbert17/8be88015...1d5dbe5b7c
timotimo oh, temp roots, eh?
dogbert2 I had the nursery down quite a bit as well 19:11
timotimo should be able to figure out what temp root it was 19:12
going up until you see that you're in a MVMROOT 19:13
and of course you'd have to count backwards from the top of the temp root stack
dogbert2 perhaps something for rr?
timotimo shouldn't be needed, but it could help 19:14
i just finished a nodelay + blocking run 19:17
dogbert2 where are those 'temps' which should be added to the worklist? Are they hidden in the tc?
timotimo one failed test in S14-roles/mixin and one test failed + one todo passed in repl
they are visible in the tc d)
:)
MVMROOT manages them for you, but you can also blah_temp_push and blah_temp_pop 19:18
dogbert2 num_temproots = 4, mark_temproots = 0, alloc_temproots = 16, temproots = 0x9f09cf0, 19:19
timotimo okay that sounds simple
there ought to be a loop there that goes through the temp roots
from that you should be able to see which of these roots was b0rked
dogbert2 242 if (worklist) { 19:20
243 for (i = 0; i < num_roots; i++)
244 if (!is_stack_frame(tc, temproots[i]))
245 MVM_gc_worklist_add(tc, worklist, temproots[i]);
246 } 19:21
timotimo right, so i should be the variable that's interesting 19:22
dogbert2 i = 1
timotimo ok, so the second from the top
so we can go up the stack and see what MVMROOTs are there 19:23
dogbert2 (gdb) p temproots[1]
$3 = (MVMCollectable **) 0xb56fdc94
what now
timotimo more interesting is what piece of the code added it 19:24
but you can print **temproots[1]
dogbert2 {sc_forward_u = {forwarder = 0x832ead0, sc = {sc_idx = 60112, idx = 2098}, sci = 0x832ead0, st = 0x832ead0}, owner = 260, flags = 0, size = 0} 19:25
timotimo owner being 260 is weird
dogbert2 the other three have owner = 1 19:26
size being zero feels a bit strange as well 19:29
dogbert2 tries valgrind 19:30
timotimo size can be 0 if it's an STable 19:32
dogbert2 o.O
timotimo you can tell by the flags
dogbert2 reload the gist and look at the bottom
timotimo aha, that's interesting 19:34
let me have a look
dogbert2 ++timotimo
timotimo huh, that's weird
dogbert2 ran it again, same warning (Conditional jump or move depends on uninitialised value(s)) 19:38
timotimo right
maybe things'll be a tiny bit clearer with disabled jit? 19:41
running it a hundred times and not getting the crash now :\ 19:42
ah, found one. but it's not the same as yours
jnthn returns rather damp
timotimo oh no :(
jnthn Dry, said the forecast.
timotimo something moist fell on you
jnthn Just rain. 19:43
timotimo so, jnthn, anything change about stack frames identifying themselves as on the stack?
jnthn There's a macro that should be being used for that everywhere
timotimo because we get valgrind complaining about uninitialized values there
jnthn It sets frame->header.flags in allocate_frame 19:44
To zero
timotimo is_stack_frame in roots.c additionally checks for ->owner == 0
dogbert2 was supposed to be cloudy with a bit of rain today but alas the sun shone instead
timotimo i.e. it doesn't use the macro
jnthn timotimo: ohh
timotimo i'll go fix it :) 19:45
jnthn timotimo: It probably should ;)
I'm somewhat surprised I managed to get through all nqp test, Rakudo test, and Rakudo spectest with this :)
github.com/MoarVM/MoarVM/blob/mast...ame.c#L228 fwiw :) 19:46
timotimo the macro is safe if we're not sure if it's actually a frame at all?
i expect so
jnthn Yeah, it just checks if flags are 0 19:49
timotimo okay, collectable from fromspace accessed, i.e. something's not being rooted now 19:51
oh, that happens always now, eh? 19:52
can't help but think i must have messed up the fix since it crashes every program now :D 19:55
jnthn Do you have GC debug mode on?
(And could it be that it also is making a bad assumption?) 19:56
timotimo set to 2, i just set it down to 1 to see if basic things are non-explosive
still explosive with just level 1
Geth MoarVM: a354389f55 | (Jimmy Zhuo)++ | src/strings/ops.c
small optimazation to string_equal, remove repeated checks
 19:58
timotimo anyway, even with it set to 0 i get the corruption detection, just a bit later 20:05
i.e. the wording is different 20:06
jnthn Hmm 20:07
22:41 hoelzro_ joined, jnthn_ joined 22:44 ilbot3 joined 22:47 eater joined 23:14 lizmat 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!