00:05 deep-book-gk_ joined 00:07 deep-book-gk_ left 01:52 ilbot3 joined 02:16 geekosaur joined 02:19 nwc10_ joined, moritz_ joined 03:05 AlexDani` joined 03:27 AlexDani` joined 04:56 deep-book-gk_ joined 04:57 deep-book-gk_ left 05:44 AlexDani` joined 06:01 brrt joined
brrt good * #moarvm 06:06
06:28 Ven joined
brrt i've found a few bugs in the allocator still, but not the smoking gun 06:39
06:39 AlexDani` joined 06:40 domidumont joined 06:47 domidumont joined
brrt also! 06:50
www.evanmiller.org/why-im-learning-perl-6.html
pretty high praise
"The code base is well-written, well-organized, well-documented, and well-tested; little things, like functions having the right size and variables having good names, make it a pleasure to read." 06:52
y'all++ :-D
06:53 Ven_ joined 07:13 brrt joined
samcv hey brrt 07:18
brrt hey, mac has decided to reset my computer 07:19
07:24 brrt joined
brrt ohai samcv 07:25
samcv brrt, did they notify you first?
brrt the mac? 07:26
like five seconds in advance
samcv :P
rude
brrt, glad to read that fine praise! 07:27
brrt :-D
i'm going to copy that everywhere :-D 07:38
08:01 zakharyas joined
AlexDaniel lizmat: ? something to mention in next p6weekly for sure :) 08:22
ah, you've seen it already, nvm
jnthn morning o/ 08:48
brrt morning jnthn
jnthn Nice article :) 08:52
jnthn is usually so busy working on the things that need improving that he often forgets we have some good stuff too :P 08:53
08:59 robertle joined
jnthn There's lots of stuff I'd like to work on based on the CORE.setting compile profile, but I think they're out of scope for my branch, so I figure I'll get it merged 09:08
Want to look into the --profile regression first
grr, valgrind makes it work o.O 09:12
09:21 evalable6 joined 09:24 bisectable6 joined, unicodable6 joined 09:28 camelia joined
nwc10 jnthn: ASAN? (as it has a multithreaded hammer) 09:41
dogbert17 perl6-gdb might be an alternative 09:48
that's what I used yesterday 09:50
jnthn was right again, valgrind does hide the problem 09:52
Geth MoarVM/spesh-worker: 836da8faf6 | (Jonathan Worthington)++ | src/profiler/instrument.c
Clear argument guards on starting profiling.

Otherwise they'll end up pointing to bogus spesh candidates.		 09:53
MoarVM/spesh-worker: 9a6b5d835e | (Jonathan Worthington)++ | 4 files
Update profiling to cope with spesh changes.

It should wait for the spesh thread to finish its work, otherwise it will end up with confusion (and segfualts) when instrumented code gets installed underneath the spesh worker thread.
jnthn That seems to make things better.
timotimo perl6-gdb-m or maybe even rr ;) 09:54
also, mornin'
dogbert17 morning timotimo
jnthn++, that was a quick fix 09:55
jnthn Righty, time for a blocking + nodelay run of things, then I think I'll get this merged 09:58
There's still a good amount of time before the next release
So the various huge changes this branch brings can get a good workout. 09:59
(The GC orchestration stuff I did yesterday is also a huge change.)
dogbert17 any ideas as to where the current performance loss might be hiding? 10:00
jnthn Various. We're collecting a good bit more info than we were but not really using it fully yet, would be one reason, though the profiles don't show that collection up as being much of a cost. 10:02
Another could be we always have multiple threads now, so the single-thread optimizations went away. 10:03
Again, hard to see that in the profiling data.
Though it could be there inside the FSA
Yet another is that perhaps we're doing less well on certain optimizations for some reason 10:04
dogbert17 you did fix some long standing bugs, perhaps they affected reliability positively but performance negatively ? 10:05
dogbert17 tries to get ahead of nwc10 by doing a spectest with ASAN :) 10:06
jnthn That also possible, yes 10:07
Alright, looks OK 10:08
Will merge then continue hunting improvemnets 10:09
timotimo when the log buffer is full, we just stop logging, right?
jnthn Won't do an immediate bump of MOAR_REVISION so only those who choose to live right on the edge will get it
timotimo: We have a quota of buffers 10:10
timotimo: When we run out, we stop logging
timotimo: Until the spesh worker is done with one and lets us log some more
timotimo right
jnthn Otherwise we could end up nomming a lot of memory 10:11
timotimo it's not problematic to lose any logged data, right?
of course
10:11 AlexDani` joined
jnthn Not really 10:11
If something's hot it'll get called and log stuff eventually 10:12
timotimo right 10:13
jnthn What you notice in CORE.setting is there are points where the spesh worker thread goes a whole second or two with no new data, which implies nearly everything we're running has been specialized :) 10:14
Or at least, everything hot 10:15
Since hot frames will be filling the buffer with entries and hot loops with OSR entries.
timotimo aye 10:16
do we now keep osrpoints that have not been used around in frames btw?
or is there still some design needed to make that work?
jnthn For now we kick them all out
timotimo right 10:17
jnthn There's no easy option on that, I don't think
Since a spesh'd frame doesn't log
timotimo hm, right
loop detection and all that
jnthn Wow, 193 commits in my branch o.O 10:18
Merge testeds and spectested 10:19
Geth?
:) 10:20
Pushed the merge, anyway :)
Odd it didn't report it
timotimo busy bee jnthn bringing us that very special optimization honey
brrt \o/ 10:21
Geth MoarVM: 17e53807a7 | (Jonathan Worthington)++ | 2 files
Avoid many array searches for SC code refs.

This showed up hot in profiling. It turns out that we weren't even checking if the code ref had a cached SC index, and even if we had been we'd still get a miss because we didn't set the SC on the code object before adding it, meaning the index was never cached. Cuts the number of times we need to take the loop to just 40% of the cases it used to need to in CORE.setting compilation, which cuts about 5% off stage MAST.		 10:49
lizmat wee! :-) 10:52
timotimo *neat* 10:56
10:57 ZofBot joined
timotimo i think i'll install telemeh spots for "finished a log" which will tell both the thread object and the address of the log object, and also for the spesh worker when it grabs that log object 11:14
Geth MoarVM: 975a67ee28 | (Jonathan Worthington)++ | 3 files
JIT param_sp and param_sn.
 11:17
jnthn Righty, lunch and another callgrind run to have fresher data 11:18
dogbert17 jnthn: unless I have done something wrong there's a spectest fail in t/spec/S04-declarations/constant.t. "Cannot invoke this object (REPR: Null; VMNull)" 11:58
timotimo there was just a commit about constants in rakudo 11:59
dogbert17 aha
ok 72 - Can match a exported constant regex
Cannot invoke this object (REPR: Null; VMNull)
in sub at /home/dogbert/repos/rakudo/t/spec/packages/ExportConstant.pm6 (ExportConstant) line 3
in block <unit> at t/spec/S04-declarations/constant.rakudo.moar line 386
jnthn I suspect that was a revert done earlier today 12:01
Without reverting a test
fwiw, want a bit of a break from spesh work, so decided to work on shrinking MVMFrame some :) 12:02
brrt that is probably going to be worthwhile 12:04
timotimo i pushed two commits just now, geth seems unhappy 12:06
Geth MoarVM: f5d52c587f | (Timo Paulssen)++ | src/main.c
inability to open telemeh log shall not be fatal
 12:08
MoarVM: 30f92a01e6 | (Timo Paulssen)++ | src/spesh/worker.c
output spesh worker info on telemetry channel
timotimo hey look
oh no 12:19
the cat is sitting between my keyboard and screens :D 12:21
jnthn They probably offer a nice warming service with the added bonus of distracting a human for attention. 12:23
timotimo actually, my desk is cluttered (fall-out from moving, still :( ) and she's sitting right in front of the keyboard, a good 30cm away from the screens 12:24
now the telemetry log shows when quota runs out and then when the worker thread re-enables logging for a thread 12:26
essentially letting you see how much time is spent non-logging 12:27
gist.github.com/timo/9fc680c461b04...c3a919e8b7 - looks like this 12:28
stmuk gcc 7.1 is noisy 12:34
12:37 Geth joined
Geth MoarVM: 2f89bd12c5 | (Jonathan Worthington)++ | 2 files
Eliminate all reads of frame effective_handlers.

We can cheaply and easily determine what they are by checking if we have a spesh candidate or not. This will create a very small added cost where we need them, which is when an exception is thrown.		 12:38
MoarVM: c0ac26668d | (Jonathan Worthington)++ | 4 files
Eliminate effective_handlers field in MVMFrame.

All the writes to it can go away, some of which were on hot paths.
MoarVM: 3b6c397d97 | (Jonathan Worthington)++ | 2 files
Move static inline to the only file using it.
jnthn 8 (or 4 on 32-bit) bytes down
timotimo neat. we do have many frames.
Geth MoarVM: c969852553 | (Jonathan Worthington)++ | src/core/exceptions.c
Correct pluralo.
 12:43
12:49 zakharyas joined 12:52 lucasb joined
Geth MoarVM: b04678bc6d | (Jonathan Worthington)++ | 6 files
Eliminate many readers of ->effective_bytecode.

These are all easily handled by simply checking if we've a spesh candidate.		 13:16
MoarVM: 992990345d | (Jonathan Worthington)++ | src/core/frame.c
Remove an unrequired test.

If we have JIT code, we'll be running JIT code.
MoarVM: 4357c00547 | (Jonathan Worthington)++ | 2 files
Account for jitcode in effective bytecode check.
MoarVM: 3d5c545346 | (Jonathan Worthington)++ | src/core/frame.c
Prepare invoke for eliminating effective_bytecode.
 13:20
jnthn I "just" need to update deopt.c now in order to be able to eliminate effective_bytecode
But first, language class :) 13:21
bbiab 13:22
timotimo ... object oriented speaking ... 13:23
13:26 jsimonet joined
jsimonet Hello, I think I saw a type on moarvm website (www.moarvm.org/) "Synchronous I/O reimplemented, lifting limtations". 13:28
typo*
timotimo mhh lime-tations 13:29
probably some kind of târte?
brrt hey, thanks 13:32
14:03 AlexDaniel joined
jnthn Ah, and I need to replace that with this 2017.07 release text anyway :) 14:46
jsimonet++ for noticing though :)
jsimonet :)
jnthn Well, now I know how to say "deopt je nejkomplikovan?jši"... :) 14:50
jnthn tries to sort out the effective_bytecode removal there too
Geth MoarVM: paulsmith++ created pull request #618:
Fix typo in comment		 14:54
MoarVM: 11f195d9f5 | (Paul Smith)++ (committed using GitHub Web editor) | src/core/oplist
Fix typo in comment
 15:06
MoarVM: 49ed81f0a1 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/oplist
Merge pull request #618 from paulsmith/patch-1

Fix typo in comment
MoarVM: 7455420dbd | (Jonathan Worthington)++ | src/spesh/deopt.c
Make deopt no longer require effective_bytecode.

Which makes it rather clearer anyway.		 15:10
jnthn Phew :)
Geth MoarVM: d6d7d5eb71 | (Jonathan Worthington)++ | 4 files
Eliminate effective_bytecode.

Saves another 8 (64-bit) or 4 (32-bit) bytes in MVMFrame, and some assignments on the invoke hot path.		 15:22
jnthn That's 16 (or 8 on 32-bit) bytes saved off every MVMFrame. 15:23
15:25 brrt joined
timotimo the cache rejoices 15:26
15:32 nebuchadnezzar joined 15:42 brrt joined
Geth MoarVM/frame-extras: 9a33eeb8aa | (Jonathan Worthington)++ | 10 files
Add function to encapsulate special return setup.

Which will ease refactoring how it is handled/stored.		 15:58
16:24 brrt joined 16:26 robertle joined 16:37 colomon joined
Geth MoarVM/frame-extras: 3be41bc41c | (Jonathan Worthington)++ | 12 files
Move special return into a frame extras.

This is allocated and hung off a frame on-demand to store things that relatively few frames have. A couple of further items will move to this structure later; for now this saves 3 pointers per MVMFrame (so 24 bytes per frame on 64-bit platforms).		 16:54
16:59 Ven joined
jnthn Tomorrow, a couple more things move into there, saving another 16 bytes 17:03
Or 8 if you're on 32 bit
17:22 Ven joined
timotimo hm, so reini's thread model is basically "the owner of an object doesn't have to lock if it wants to do changes to it, but it has to check for a work queue constantly"? 17:29
and on every access to any object you first have to check who the owner is, too 17:31
i'm not entirely convinced that's better than letting the user handle the locking based on what needs it and what doesn't 17:34
jnthn I suspect its properties also fall under the "false sense of security" I've mentioned before: effectively, that the atomicity is on smaller things than the transactions that you typically care for. 17:46
The start { while @a { process(@a.pop) } } for ^4 example being the classic example: a model that lets you safely ask how many elemnets you have and safely pop doesn't make that code safe 17:47
timotimo right 17:49
i imagine you'd still write lock-based code for that
where while a thread is waiting to acquire a lock would i guess block on its work queue? 17:50
and, er, when the lock gets freed all other threads get a wake-up for that?
there must be a way to make this efficient
anyway, will be AFK for a cinema evening with friends :)
17:53 domidumont joined 18:08 domidumont joined 18:19 FROGGS joined 18:22 brrt joined
nine timotimo: actually it's my thread model and it relies on writes being done only by the owning thread, i.e. you send it the task to execute the write. The effective lock is the one on the task queue. And yes, it doesn't actually give you guarantees about reading consistent states. 18:27
But hey, it was my first attempt :)
jnthn timotimo: You want something along the lines of what the concurrent queue uses 18:34
(condvar for the wake-up) 18:35
Geth_ moarvm.org: 4a6510293e | jnthn++ | 2 files
Update site for 2017.07 release.

And some more general updates to the homepage text.		 19:11
moarvm.org: 5904b51079 | jnthn++ | roadmap.html
Update roadmap also.

We completed some things.		 19:15
19:53 dogbert2 joined
dogbert2 Profiled a program which runs 10-15 percent slower with spesh-worker and compared it with a profile where I used the Camelia version. 19:55
The only obvious difference I saw was the following, the Camelia version did 5 OSR while spesh-worker only did 3. 19:57
[Coke] COMPLEAT ALL THE THINGS 20:22
jnthn dogbert2: Any chance you could callgrind the two also?
How did the inlining rate and percentage specialized compare? 20:23
dogbert2 percentage specialized frames: Camelia 100%, spesh-worker 99.99% 20:26
no JIT compiled frames since I'm on a 32 bit VM 20:27
20:27 colomon_ joined
dogbert2 also regarding the OSR's: camelia had 2 deopts while shesh-worker had 0 20:28
jnthn Yeah, in theory spesh-worker has more data to go on in most cases and so can do less deopting 20:39
Did you find the inlining rate? It's on the overview page 20:41
dogbert2 Camelia: Inlining eliminated the need to create 25326140 call frames (that's 40.33%). spesh-worker Inlining eliminated the need to create 25325704 call frames (that's 40.33%). 20:43
jnthn Gosh, they're close 20:47
And top routines and their percentage times are similar?
20:49 colomon joined
dogbert2 jnthn: here are the callgrind results: gist.github.com/dogbert17/6bb3eeb5...c7ab6f31a7 20:54
20:56 colomon joined
dogbert2 the percentages (top ten in the --profile output) are more or less the same 21:04
jnthn Yeah, that's quite revealing. Thanks. 21:05
nine almost half a million get_attribute more? 21:11
jnthn Yeah, also a lot of multi-dispatch cache lookups 21:14
nine So either the stronger validation of code objects is too strong or some missing facts? 21:15
jnthn More like, we were playing waaay fast and loose with aliasing before
And now we're a lot tighter on it, so much so that it probably cuts out a bunch of useful opts 21:16
I expected to have to deal with that; we already do collect some data about it that now needs to be put to good use
In the longer run we'll want some more sophisticated alias analysis also
Which is also an escape analysis pre-req, which would allow for cutting out a ton of GC work. 21:20
21:38 colomon joined
samcv someone i talk to on irc linked me that evanmiller article unprompted and asked if i'd seen it :) is perl 6 popular yet? 22:02
:p
heh 22:03
jnthn :) 22:23
sleep & 22:31
22:46 AlexDani` joined 23:59 sivoais 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!