00:00 travis-ci joined
travis-ci MoarVM build failed. Elizabeth Mattijsen 'Remove dependency on autodie' 00:00
travis-ci.org/MoarVM/MoarVM/builds/293879305 github.com/MoarVM/MoarVM/compare/2...c3211c5c00
00:00 travis-ci left
timotimo lizmat: getrusage is trivial to jit, as it's just a c function call 00:02
not exactly sure how to properly measure all this 00:19
Geth MoarVM: 89565bf51e | (Timo Paulssen)++ | src/jit/graph.c
jit for getrusage
 00:26
timotimo lizmat: it does jit the full getrusage-total sub now 00:28
let me know how much this is worth :)
Zoffix \o/
timotimo it's a very small sub anyway 00:35
not sure if that means it's worth more or less :) 00:36
sadly the first argument for that method is still being ketp alive by deopt requirements 00:50
and the setting of $*DISPATCHER still happens - well, if the dispatcher it takes is non-null 00:51
i wonder if we should ever do logging and such for takedispatcher 00:55
logging and guarding
MasterDuke what is takedispatcher? 00:57
timotimo it takes the tc's currently active dispatcher and nulls it iirc 00:58
MasterDuke what's the point of that? 00:59
timotimo well, there's also a setdispatcher op
(and a setdispatcherfor op, too) 01:00
MasterDuke ah
timotimo i won't pretend i know how the dispatcher dance works :)
01:04 evalable6 joined 01:12 committable6 joined 01:56 ilbot3 joined 02:13 travis-ci joined
travis-ci MoarVM build passed. Timo Paulssen 'jit for getrusage' 02:13
travis-ci.org/MoarVM/MoarVM/builds/293947445 github.com/MoarVM/MoarVM/compare/9...565bf51e43
02:13 travis-ci left 04:14 evalable6 joined 05:26 evalable6 joined
Geth MoarVM: 0468d95a12 | (Samantha McVey)++ | src/6model/reprs/MVMIter.c
Handle unsigned types to switch in MVM_iter()

Fixes "Unknown lexical type encountered while building context iterator" error when MVM_iter() tries to handle unsigned integers.		 07:42
MoarVM: eb8acff6f3 | niner++ (committed using GitHub Web editor) | src/6model/reprs/MVMIter.c
Merge pull request #733 from samcv/MVMIter

Handle unsigned types to switch in MVM_iter()
08:37 evalable6 joined 08:57 evalable6 joined
Geth MoarVM: 8b53b1ebbd | (Nick Logan)++ | 3rdparty/libuv
Bump libuv to ver. 1.15.0
 09:28
MoarVM: 60e56edb93 | (Nick Logan)++ | src/io/fileops.c
Use uv_fs_copyfile
MoarVM: cb785db9e0 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | 2 files
Merge pull request #719 from ugexe/uv_fs_copyfile

Use uv_fs_copyfile API
MoarVM: 66ba242887 | (Daniel Green)++ | src/6model/sc.c
Convert realloc plus memset 0 to recalloc
 09:29
MoarVM: 7b7a8d14f8 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/6model/sc.c
Merge pull request #712 from MasterDuke17/convert_realloc_plus_memset_0_to_recalloc

Convert realloc plus memset 0 to recalloc
09:29 travis-ci joined
travis-ci MoarVM build canceled. Jimmy Zhuo 'Merge pull request #719 from ugexe/uv_fs_copyfile 09:29
travis-ci.org/MoarVM/MoarVM/builds/294059317 github.com/MoarVM/MoarVM/compare/e...785db9e006
09:29 travis-ci left
Geth MoarVM: 900178b52c | MasterDuke17++ | src/core/fixedsizealloc.c
Support FSA_SIZE_DEBUG in MVM_fixed_size_realloc
 09:30
MoarVM: abea56319f | MasterDuke17++ | src/core/fixedsizealloc.c
Also do FSA_SIZE_DEBUG for *realloc_at_safepoint
MoarVM: 590dd2e303 | (Jimmy Zhuo)++ (committed using GitHub Web editor) | src/core/fixedsizealloc.c
Merge pull request #711 from MasterDuke17/support_FSA_SIZE_DEBUG_in_MVM_fixed_size_realloc

Support FSA_SIZE_DEBUG in MVM_fixed_size_realloc*
09:46 travis-ci joined
travis-ci MoarVM build passed. Jimmy Zhuo 'Merge pull request #711 from MasterDuke17/support_FSA_SIZE_DEBUG_in_MVM_fixed_size_realloc 09:46
travis-ci.org/MoarVM/MoarVM/builds/294059576 github.com/MoarVM/MoarVM/compare/7...0dd2e30382
09:46 travis-ci left
AlexDaniel squashable6: next 09:52
squashable6 AlexDaniel, āš šŸ• Next SQUASHathon in 6 days and ā‰ˆ0 hours (2017-11-04 UTC-12āŒUTC+14). See github.com/rakudo/rakudo/wiki/Mont...Squash-Day
09:57 greppable6 joined 10:33 patrickz joined
lizmat hmmm... it looks like adding an nqp::getpid to the mainline of ThreadPoolScheduler, fixes GH #1202 for me 11:21
dogbert17 jnthn: the SEGV in lizmat's example seems to happen here, github.com/MoarVM/MoarVM/blob/mast...on.c#L2901 11:43
(gdb) p sc->body 11:49
$2 = (MVMSerializationContextBody *) 0x0
lizmat that's not a lot of body 11:50
dogbert17 very similar to yesterdays problem, github.com/MoarVM/MoarVM/blob/mast...on.c#L2746 11:52
jnthn Should probably audit all of the acquires 11:54
dogbert17 perhaps an MVMROOT around github.com/MoarVM/MoarVM/blob/mast...on.c#L2875 might do the trick ?
jnthn dogbert17: Yes 11:55
dogbert17 hmm, I might try to do a PR, perhaps adding one on 2813 as well 11:56
unless jnthn is already fixing them ofc :) 11:58
jnthn No, reviewing some cro stuff at the moment, and lunch is about to be ready :) 12:01
dogbert17 ok, I'll give it a shot then
samcv did i get pinged here? 12:02
hm maybe i didn't and just saw wrong 12:03
dogbert17 hi samcv, shouldn't you be sleeping at this time?
samcv yes
maybe it looked like i was mentioned in #perl6 12:05
dogbert17 does your computer have a high beep? 12:10
Geth MoarVM: dogbert17++ created pull request #739:
Add two more missing MVMROOTs around managed mutex acquire		 12:29
13:17 MasterDuke joined 13:30 xi- joined
Geth MoarVM: 82273161ce | (Stefan Seifert)++ | 6 files
JIT compile native calls with up to 3 UTF-8 string arguments

Strings are unboxed and the resulting pointers stored in the scratch space on the stack so both the actual C call and the MVM_free call afterwards can access them. The scratch space is 0x40=64 bytes large and we already need 8 bytes for the native function's return value, leaving us with space for 7 string pointers.		 13:43
MoarVM: 57f6315d77 | (Stefan Seifert)++ | src/core/nativecall.c
Don't try to JIT compile native calls with rw arguments
MoarVM: 0edfd0c7ba | (Stefan Seifert)++ | 10 files
JIT compile native calls with integer rw arguments

Passing a pointer to an integer instead of the integer itself to the native function is easy. Getting the changed value back to the HLL code is the hard part. Since the native function writes to the register that's passed in the args buffer, the HLL code needs to read the value back from the args buffer. That's what the new getarg_* ops are for.
nine These give me a 9.214/8.608 = 7 % speedup for csv-ip5xs-20 13:48
MasterDuke nice 13:54
Geth MoarVM: f66d7aa240 | (Jan-Olof Hendig)++ | src/6model/serialization.c
Add two more missing MVMROOTs around managed mutex acquire

The mutex acquire may GC block and thus trigger GC, moving objects.
MoarVM: 5a31123afe | niner++ (committed using GitHub Web editor) | src/6model/serialization.c
Merge pull request #739 from dogbert17/add-missing-mvmroots

Add two more missing MVMROOTs around managed mutex acquire
dogbert17 nine++ 13:59
Geth MoarVM: 3a4321783d | (Stefan Seifert)++ | 3 files
Treat NULL strings correctly in JIT compiled native subs
 14:50
jnthn Left a commnet on dogbert17++'s PR; it's correct, but we need one more MVMROOT in one of those places 14:55
dogbert17 MVMROOT(tc, st, { // jnthn, like this ? 15:30
MVMROOT(tc, sc, {
MVM_reentrantmutex_lock(tc, (MVMReentrantMutex *)sc->body->mutex);
});
jnthn yes
dogbert17 should I make a new PR considering the previous one has already been merged? 15:31
dogbert17 spectesting 15:37
Geth MoarVM: dogbert17++ created pull request #740:
Add another MVMROOT around managed mutex acquire. jnthn++		 15:44
MoarVM/master: 4 commits pushed by (Stefan Seifert)++ 15:52
nine jnthn: did I remember the reason correctly? github.com/MoarVM/MoarVM/commit/76...596b21ef22
15:53 evalable6 joined, zakharyas joined
jnthn nine: Yes, that's a sensible thing to do for the time being :) 15:56
15:57 zakharyas joined
nine So the obvious next step is to fix spesh. Which sounds like the effort will consist of 80 % learning about spesh followed by the other 80 % of actually working on a fix 15:57
I'm actually a bit surprised that the :noinline version is faster. I'd have guessed that call overhead is much larger than the benefits of JIT compilation 16:00
jnthn Good news is that it'll be a LOT less nasty than it used to be
We used to not even include inlined things into the spesh graph in any "proper" way at all 16:01
I fixed all of that over the summer (TPF++)
16:01 zakharyas joined
jnthn So getting inlinee facts in place, and propagating facts from the inliner to the inlinee, should work out nicely 16:02
Or at least, without all the pain it would have done if attempting it some months ago
If you want a warm-up task, another interesting job would be to try moving the inlined code to the point of the invocation it replaced
I think timotimo++ tried it and ran into some issues though 16:03
I don't recall any details
nine jnthn: may I infer from that that the code is currently appended and the call replaced by a jump?
jnthn But figuring that out would probably be a good education in inlining, and also have a useful result along the way
Yeah, we append the inlines at the end
Which was easy 16:04
I *think* deopt doesn't depend on that in any way, though
timotimo i don't remember why exactly things broke either 16:06
Geth MoarVM: 9ee680f052 | (Jan-Olof Hendig)++ | src/6model/serialization.c
Add another MVMROOT around managed mutex acquire. jnthn++
MoarVM: ad2d6fb0dd | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/serialization.c
Merge pull request #740 from dogbert17/add-another-missing-mvmroot

Add another MVMROOT around managed mutex acquire. jnthn++
timotimo i don't think i pushed my branch that tried to put inlines in the place it's called
Geth MoarVM/inline_in_place: 94aa824a67 | (Timo Paulssen)++ | 2 files
WIP on putting inlined blocks between their caller and its succ

currently prevents more than one inline from happening per graph, and also seems to create wrong code in some way.		 16:07
timotimo there it is
jnthn Well, with most things spesh, it's mostly a case of being stubborn enough to figure out why the odd bustage :)
timotimo it's true 16:08
lizmat jnthn nine ok to bump Moar ?
timotimo this branch was before the graph properly got re-ssa'd after an inline
nine lizmat: sure
lizmat ok, will do in a mo
16:09 zakharyas joined
Geth MoarVM: ugexe++ created pull request #741:
Add MVMROOT around more reentrantmutex acquires		 16:09
ugexe nine: MVMCompUnit object does not need to be MVMROOTd right? 16:10
oh maybe it does 16:11
nine ugexe: I don't know of any exceptions. It's all just objects to the GC
Geth MoarVM/inline_in_place: 37fbba5578 | (Timo Paulssen)++ (committed by Stefan Seifert) | 2 files
WIP on putting inlined blocks between their caller and its succ

currently prevents more than one inline from happening per graph, and also seems to create wrong code in some way.		 16:12
lizmat holds off bumping Moar for a bit
nine timotimo: rebased on master ^^^
ugexe i read a comment saying that it didn't "move"
and 20ish lines under that it MVMROOTs a MVMCompUnit :)
16:30 zakharyas joined
nine timotimo: why is it preventing more than one inline per graph? 16:50
timotimo i think it's because it doesn't know where one starts and the next ends 16:51
i.e. on the first step you're guaranteed that the first bb with "is_inlined" is what you're working on
nine timotimo: looks like it breaks on nested inlines
timotimo could very well be
MasterDuke while a bunch of jitting commits are going in, anyone have a comment on github.com/MoarVM/MoarVM/pull/729? 16:52
nine Seems odd that annotate_inline_start_end is happending after the merging. Wouldn't this be trivial to do before actually inlining?
lizmat MasterDuke: that's above my pay scale, hope that jnthn timotimo nine can vet that 16:53
Zoffix FWIW, there's also github.com/MoarVM/MoarVM/pull/734 awaiting a merge 16:54
nine Looks sane to me, but have to leave for dinner now
lizmat MasterDuke: what was wrong with #730 ?
16:55 domidumont joined
MasterDuke lizmat: OBE, nine just did the same thing a couple commits ago 16:55
lizmat ah, ok :-)
Geth MoarVM: ugexe++ created pull request #742:
Add more missing MVMROOTs		 17:01
17:02 domidumont joined
timotimo MasterDuke: you put "used to cause n bails" in the PR, but it'd be more interesting to see how many of the frames that used to bail still bail because of some other op 17:03
MasterDuke timotimo: you know, i'd meant to calculate that and then got distracted 17:04
timotimo i can imagine :)
i tend to grep bail, sort | uniq -c | sort -rn 17:05
and then diff the results
MasterDuke almost exactly what i do
timotimo OK
MasterDuke i think i have a couple minutes now, let me give it a go... 17:06
17:10 xi- joined
MasterDuke i do `sort | uniq -c | sort -rn` so many times, i really should have an alias or function or something for it 17:12
timotimo yeah, me too 17:16
Geth MoarVM: 5e8be59d32 | MasterDuke17++ | 4 files
JIT the getexcategory op

Create an MVM_get_exception_category function and call that in interp.c and graph.c.
Used to cause 15 BAILs when building the Rakudo core setting.		 17:41
MoarVM: e9067c7bdb | niner++ (committed using GitHub Web editor) | 4 files
Merge pull request #729 from MasterDuke17/jit_getexcategory

JIT the getexcategory op
ugexe 742 didn't stop 1202 either 17:44
should we be using fctnl + F_FULLFSYNC on OSX in place of fsync? sqlite and libuv do this fwiw. blog.httrack.com/blog/2013/11/15/ev...out-fsync/ 19:08
19:37 ggoebel joined 19:44 colomon joined
MasterDuke timotimo: ok, finally got a minute. jitting getexcategory removed the 15 bails it caused, but total only went down by 12 20:19
timotimo that's quite good 20:21
i'll go rest a little
samcv good * 21:56
jnthn o/ samcv 22:10
samcv hey jnthn so what do i need to learn about Buf
and how it's handled as an object on the MVM side
since i only know the code that's in rakudo 22:11
how do we store bufs in mvm and what things do we need added for working with Buf's
jnthn It's just a VMArray underneath
The "magic" that makes that happen is the "is repr('VMArray')" in Rakudo 22:12
samcv so it's a uint based vmarray?
jnthn Yup
That said
I've been pondering making Blob uses MultiDimArray
Not for multiple dimensions, but for the fixed size
samcv hm 22:13
Blob is fixed and Buf is unfixed?
jnthn Because if our I/O layers spit *those* out then we can shove 'em into Decoder and it won't have to do a defensive copy
Blob is immutable, Buf is mutable (in both content and size)
So Buf needs to be a growing thing underneath
Blob needn't
And would likely be better for us if it didn't 22:14
At the moment Decoder always does a defensive copy of the contents of the Blobs it is given
Since it can't know they won't mutate
samcv yeah
jnthn Which is a bit wasteful 22:15
Would probably help us catch up a bit with Perl 5 in the non-Unicode line-reading benchmarks :)
(We already win the Unicode one) 22:16
Well, utf-8 specifically
samcv decodng as ascii or what?
as binary?
timotimo no, decoding real utf8 22:17
oh, i might misunderstand
jnthn samcv: The for $fh.lines { } thing
samcv ok so where in our code is this?
so i can start reading 22:18
jnthn Which "it"? :)
timotimo he's called pennywise, jnthn 22:19
jnthn For the Blob/Buf stuff in Rakudo, src/core/Buf.pm
For VMArray/MultiDimArray, src/6model/reprs/VMArray.c and src/6model/reprs/MultiDimArray.c 22:20
For Decoder stuff, src/6model/reprs/Decoder.c (API to the outside world) and src/strings/decode_stream.c (impl)
samcv thanks :)
jnthn And the decoder impls are under src/strings/ 22:21
22:54 bisectable6 joined
samcv jnthn, is this accurate? github.com/rakudo/rakudo/issues/12...-340226255 23:21
replied to this
jnthn samcv: Just about to sleep, will check tomorrow 23:26
samcv ok
night
jnthn (Needs more thinking than I have brane left for) 23:27
'night o/
timotimo github.com/jnthn/p6-app-moarvm-hea...#L348-L409 - this is a thing i made and use 23:29

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!