00:42 synopsebot6 joined 01:07 lizmat joined 01:25 geekosaur joined, vendethiel joined 02:48 ilbot3 joined 04:05 vendethiel joined 05:14 vendethiel joined 05:20 synopsebot6 joined 05:23 synopsebot6 joined 06:32 vendethiel joined 07:00 domidumont joined 07:05 domidumont joined 07:55 TimToady joined 08:22 FROGGS joined
FROGGS nwc10: hi, do you have any insights about this one? github.com/MoarVM/MoarVM/issues/34...-199805720 08:23
jnthn: can we alter the expression in the string here? github.com/MoarVM/MoarVM/blob/mast...oots.c#L31 08:28
because it warns like:
src/gc/roots.c: In function ‘MVM_gc_root_add_permanent’:
src/gc/roots.c:31:51: warning: trigraph ??> ignored, use -trigraphs to enable [-Wtrigraphs]
08:33 zakharyas joined 08:35 zakharyas joined 09:13 vendethiel joined
jnthn moarning o/ 10:01
lol trigraphs!
10:04 vendethiel joined
FROGGS *g* 10:05
such a strange thing
jnthn: can we alter that string? or what meaning has <??> there? 10:06
dalek arVM: e5702e0 | jnthn++ | src/gc/roots.c:
Escape ?s to avoid accidentally trigraphing.
 10:07
jnthn FROGGS: TIL C lets you escape ? because of the trigraphs thing :)
moritz trigraphs are C's Texas operators, right?
jnthn Yeah. I think from the "keep Austin weird" part of Texas. :P 10:08
moritz wonders if staying in Texas' capital for too long can give you Austism
10:10 mojca joined
nwc10 FROGGS: as to that compiler going SEGV - er, I don't know better than "it's gcc going SEGV - that's a gcc bug" 10:11
to *try* to work round it, one usually tries changing the compiler flags (eg dropping the optimiser)
jnthn That whole ticket is really odd 10:12
nwc10 assuming that it's a debian gcc (as in raspbrian) possibly better to report the bug (with pre-processed source code) to debian rather than direct to the gcc folks
I'm in the UK
(most) hardware is in Vienna
so I can't try to replicate it
"this week"
10:39 zakharyas joined 12:11 colomon joined
timotimo my particles "benchmark" actually spends 4.16% of its time inside floor, which isn't jitted because we don't have floor_n 12:28
postcircumfix:<[ ]> (both the ASSIGN-POS and the AT-POS versions) aren't jitted either, but that's because of param_rp_o 12:30
i don't really understand what's going on there, as AT-POS is only 2.38% and ASSIGN-POS is only 1.02%, but the corresponding postcircumfixes are 17.15% and 10.02% 12:31
all it does is directly invoke that method
and those methods are even jitted
lizmat timotimo: I think it's because AT-POS is one of a list of candidates with named parameters ? 12:32
timotimo well, the actual candidates are pointed out in the profile 12:33
so i thought it's already using those exact candidates
lizmat example ?
timotimo you mean the code i'm talking about?
or the profile file? 12:34
lizmat the actual candidate that you see taking 17% ?
timotimo it's postcircumfix:<[ ]>( \SELF, int $pos) is raw { SELF.AT-POS($pos) } 12:35
lizmat perhaps the \SELF ?
timotimo it has 4,867,763 invocations and takes 3416.02ms all in all (but 2998.79ms without what the AT-POS takes)
lizmat is this in an array ? 12:37
timotimo well, the param_rp_o is the one that extracts the SELF
lizmat or a List ?
timotimo it's a native num array 12:38
there's also some accesses to a native num CArray
lizmat ah, native num
are you sure it actually hits the multi method AT-POS(numarray:D: int $idx) is raw { 12:39
?
timotimo let's see 12:40
lizmat also, I'm wondering whether it is the :D on the numarray, that may be the reason ?
timotimo i can try compiling without the :D
it does hit that exact candidate
but as i said, the AT-POS itself is jitted and only takes a tiny amount of time itself 12:43
doesn't seem to make a difference at all 12:47
removing the :D
i really don't know what you use in assembly to turn a double into an int 12:54
lizmat neither 12:55
the days that I could hand-code 8086 assembly are long gone 12:56
timotimo i'm just betting on brrt reading the log and building what i need :D
it'll only be a tiny win, though :(
i'm surprised the floor method doesn't get completely inlined
:\ 12:58
floor is implemented like this:
unbox the num to check "isnanorinf"
unbox the num, floor it to a floored num
coerce the floored num to a big integer
to be fair, there's no reason i'm giving the compiler or runtime to know i'm only dealing with non-big integers 12:59
sorry, not "to a floored num" 13:01
and the next step after the floor is going to be to unbox again :| 13:09
13:18 vendethiel joined
dalek arVM: df13f01 | jnthn++ | src/io/sync (2 files):
Mark thread blocked for GC when doing sync reads.

Otherwise, one thread blocked on I/O can cause all other threads to block when they need to do their next GC run until the read returns.		 13:18
Heuristic branch merge: pushed 91 commits to MoarVM/even-moar-jit by bdw 13:37
13:39 brrt joined
brrt \o 13:39
timotimo: whaddayaneed 13:40
:-P
timotimo floor_n and probably also ceil_n?
brrt oh, right
timotimo though i have no clue how good that'll be for my code
it'll only lift a routine from spesh'd to jitted, and that routine only accounts for a small part of my run time anyway 13:41
like, a really small part
brrt the 'coerce double to int' is 'cvttsd2si'
timotimo oh, i could have guessed that 13:42
hm. but how do we handle really big doubles here?
oh, we have fromnum_I 13:43
right, so floor_n actually does coerce num to num
brrt aye 13:44
not sure what 'tsd' stands for 13:45
timotimo "thousand"
brrt pretty sure the 'd' is for double :-)
timotimo oh, floor wouldn't get jitted, because we lack jitting for coerce_nI anyway
brrt convert with truncation scalar dobule-pression floating point value to signed doubleword integer 13:46
13:46 vendethiel joined, dalek joined
brrt which becomes a signed quadword if used on quadword operands 13:48
so
(what's coerce_nI?) 13:49
annoying, is what it is
timotimo it can be turned into a jit-friendly op like the other big int ops already have been 13:50
brrt i'd assume so, yes 13:53
timotimo well, i know it can
because i'm doing it right now
just replaced MVMObject *result with result_type and return the result
brrt at some point in the indefinete future, we should start seeing all the function calls as performance drains, in the JIT, at least
timotimo so if you want you can already write the support code fro that :)
brrt :-)
timotimo yeah
brrt (don't write a JIT for a highly dynamic language, then, brrt) 13:54
timotimo heh.
dalek arVM: 29997a1 | timotimo++ | src/ (3 files):
make MVM_bigint_from_num jit-friendly
 13:57
timotimo adding the coerce_nI to the graph.c was easy, but we're still lacking the floor_n and ceil_n in the jit :) 14:00
so i can't test it easily
and i have no clue if the nqp test suite tests coerce_nI at all 14:02
brrt now, wait a minut 14:03
we're talking about coerce_nI right?
coerce_In is already jitted, but it is not using the xmm0 return address for its value 14:04
oh, nm, it is alright
timotimo sorry, yeah, num to Int
brrt :-) 14:06
dalek arVM: 651b6c1 | timotimo++ | src/jit/graph.c:
jit coerce_nI as a call to bigint_from_num
brrt you're just seconds before me
but, no, sorry 14:07
that's wrong
coerce_nI has 3 arguments, second is type, third is num
(competitive speed coding :-o) 14:09
competitive collabarative speed coding
14:10 cognominal joined, BinGOs joined
brrt very net reliability 14:11
14:18 mst joined
dalek arVM: b16fdca | brrt++ | src/jit/graph.c:
MVM_bigint_from_num takes a type argument
 14:18
14:22 timotimo joined 14:25 zakharyas joined 14:29 travis-ci joined
travis-ci MoarVM build failed. Bart Wiegmans 'MVM_bigint_from_num takes a type argument' 14:29
travis-ci.org/MoarVM/MoarVM/builds/117978123 github.com/MoarVM/MoarVM/compare/6...6fdca7e50e
14:29 travis-ci left
timotimo .. uh oh? 14:29
damn, yeah 14:30
i totally wronged that implementation
brrt wait, what 14:31
broken build?
timotimo well, you fixed it
brrt not sure i did
(i only noticed becuase i spent some time on making the same mistake though :-))
yep, it's broken
timotimo ah, syntax error 14:32
missing a }
brrt yep 14:33
dalek arVM: 82535c3 | brrt++ | src/jit/graph.c:
Typo fix!
brrt sorry about that :-)
timotimo clearly the nqp test suite didn't test coerce_nI :) 14:34
brrt well, i dunno. i often get weird things where i though i thought i built something and then apparantly didn't build it 14:35
not enough attention being paid, clearly
dalek arVM: 0e285c8 | jnthn++ | src/ (4 files):
Fix missing inclusion of frames in heap snapshots.
 14:40
14:46 travis-ci joined
travis-ci MoarVM build passed. Bart Wiegmans 'Typo fix!' 14:47
travis-ci.org/MoarVM/MoarVM/builds/117984759 github.com/MoarVM/MoarVM/compare/b...535c304507
14:47 travis-ci left 14:58 travis-ci joined
travis-ci MoarVM build passed. jnthn 'Fix missing inclusion of frames in heap snapshots.' 14:58
travis-ci.org/MoarVM/MoarVM/builds/117986633 github.com/MoarVM/MoarVM/compare/8...285c839525
14:58 travis-ci left 15:14 brrt joined 15:39 lucasb joined 16:03 brrt joined 16:07 zakharyas joined
jnthn heh, these snapshots would be a lot more useful if NQP set debug type names :) 16:09
16:12 brrt joined
dalek arVM: fcad1c5 | jnthn++ | src/6model/bootstrap.c:
Set debug_name in a few more places.

So we get better output in the heap snapshot viewer.		 16:36
FROGGS jnthn: is there a screenshot available that shows how that snapshot viewer looks like? 16:37
jnthn not yet :) 16:39
Will share some more stuff on it soon 16:40
16:45 ggoebel16 joined
dalek arVM: 7425902 | jnthn++ | src/profiler/heapsnapshot.c:
Factor more allocations into frame size.
 16:50
17:05 vendethiel joined
dalek arVM: d663972 | jnthn++ | src/6model/ (44 files):
Add REPR API for getting unmanaged size.

That is, the amount of memory a REPR has behind it that is not under the direct management of the GC.		 17:14
arVM: a6fa12b | jnthn++ | src/profiler/heapsnapshot.c:
Factor in unmanaged size to heap snapshot.

Though nothing is actually implementing the API yet.
arVM: 4e1817e | jnthn++ | src/6model/reprs/MVMArray.c:
Implement unmanaged_size for VMArray REPR.
 17:15
arVM: b0482df | jnthn++ | src/6model/reprs/MVMArray.c:
Add a missing `static`.
 17:24
arVM: 19ccc86 | jnthn++ | src/6model/reprs/MVMString.c:
Implement unmanaged_size for VMString REPR.
arVM: df9f8b8 | jnthn++ | src/6model/reprs/NFA.c:
Implement unmanaged_size for NFA REPR.
 17:36
17:59 domidumont joined 18:05 pochi joined
dalek arVM: 30bad8d | jnthn++ | src/profiler/heapsnapshot.c:
Fix use-after-realloc bug in heap snapshot taking.
 18:06
jnthn Here's a session with the heap analyzer so far, on a Rakudo heap snapshot: gist.github.com/jnthn/35fb78323d715dda93fc 18:08
The numbers are still underestimates in places, because unmanaged_size needs implementing on some more REPRs 18:10
The analysis app itself is here: github.com/jnthn/p6-app-moarvm-heapanalyzer 18:11
dinner break now :) 18:17
moritz what's the moarop_mapper? 18:28
jnthn github.com/perl6/nqp/blob/master/s...T.nqp#L331 18:50
diakopter yeah that's on me 18:51
I was thinking: .oO( surely we won't ever have a thousand of these ) 18:52
we could have it return an array of pre-processed args instead of a curried code object, maybe it'd be smaller 18:54
I mean. I think that was me.
18:55 ilmari joined
diakopter 74,000 NQPArrays with average size around 100 bytes 18:56
18:56 mojca joined
diakopter seems small 18:56
32 bytes per bootint; seems high 18:57
I guess a bunch of pointers for 64-bit memory /o\ 18:58
.oO( surely many of these metaobject pointers could be compressed to use only 8 bits or something
 18:59
)
OR, all these counter/index integers could be native ints 19:01
19:15 camelia joined 19:19 retupmoca joined 19:20 arnsholt joined, dalek joined 19:52 FROGGS joined 20:33 colomon joined
dalek arVM: 8d6e8ed | timotimo++ | src/6model/reprs/P6bigint.c:
unmanaged_size for P6bigint (if it IS_BIG)
 21:17
21:38 colomon joined 21:43 geekosaur joined 21:46 zakharyas joined
dalek arVM: 0d25193 | jnthn++ | src/profiler/heapsnapshot.c:
Fix regression in emitting references.
 21:56
timotimo jnthn: anything good we can do for/with gen2-roots? 21:58
jnthn timotimo: Yeah, I need to include those still, I think 22:03
Will get there
In the meantime, something awesome
I just added a couple of new features to the heap snapshot analyzer 22:04
And...it just explained our EVAL leak!
timotimo well, the gen2 roots are just things in the gen2 that point at the nursery, right?
so we'll end up seeing them from a full collection anyway
i just mean we might want to analyze them individually (well, as a set of roots, really)
jnthn timotimo: We should include them in so far as they tell us about some things that are *only* alive because we didn't do a full collection yet 22:05
But I want to think about that a little more :)
This is awesome
gist.github.com/jnthn/f67379ff234861729f34
timotimo well, really we want to have some stats like "this root holds X things in total, Y of those are only reachable by this root" 22:06
oh, we hold a list of all SCs we are compiling and we're not dropping those references?
jnthn We're meant to pop SCs from that when we're done compiling them, yes. :)
Apparently we don't 22:07
I...would not have guessed that :)
timotimo right. it's something we already do, but apparently we do wrong
so, very well done :)
jnthn 'night, #moarvm 22:38
22:43 vendethiel joined 23:41 geekosaur 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!