Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-23

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:42 synopsebot6 joined #moarvm
01:07 lizmat joined #moarvm
01:25 geekosaur joined #moarvm
01:25 vendethiel joined #moarvm
02:48 ilbot3 joined #moarvm
02:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:05 vendethiel joined #moarvm
05:14 vendethiel joined #moarvm
05:20 synopsebot6 joined #moarvm
05:23 synopsebot6 joined #moarvm
06:32 vendethiel joined #moarvm
07:00 domidumont joined #moarvm
07:05 domidumont joined #moarvm
07:55 TimToady joined #moarvm
08:22 FROGGS joined #moarvm
08:23 FROGGS nwc10: hi, do you have any insights about this one? https://github.com/MoarVM/MoarVM/issues/346#issuecomment-199805720
08:28 FROGGS jnthn: can we alter the expression in the string here? https://github.com/MoarVM/MoarVM/blob/master/src/gc/roots.c#L31
08:28 FROGGS because it warns like:
08:28 FROGGS src/gc/roots.c: In function ‘MVM_gc_root_add_permanent’:
08:28 FROGGS src/gc/roots.c:31:51: warning: trigraph ??> ignored, use -trigraphs to enable [-Wtrigraphs]
08:33 zakharyas joined #moarvm
08:35 zakharyas joined #moarvm
09:13 vendethiel joined #moarvm
10:01 jnthn moarning o/
10:01 jnthn lol trigraphs!
10:04 vendethiel joined #moarvm
10:05 FROGGS *g*
10:05 FROGGS such a strange thing
10:06 FROGGS jnthn: can we alter that string? or what meaning has <??> there?
10:07 dalek MoarVM: e5702e0 | jnthn++ | src/gc/roots.c:
10:07 dalek MoarVM: Escape ?s to avoid accidentally trigraphing.
10:07 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e5702e02a7
10:07 jnthn FROGGS: TIL C lets you escape ? because of the trigraphs thing :)
10:07 moritz trigraphs are C's Texas operators, right?
10:08 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 #moarvm
10:11 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 nwc10 to *try* to work round it, one usually tries changing the compiler flags (eg dropping the optimiser)
10:12 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
10:12 nwc10 I'm in the UK
10:12 nwc10 (most) hardware is in Vienna
10:12 nwc10 so I can't try to replicate it
10:12 nwc10 "this week"
10:39 zakharyas joined #moarvm
12:11 colomon joined #moarvm
12:28 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:30 timotimo postcircumfix:<[ ]> (both the ASSIGN-POS and the AT-POS versions) aren't jitted either, but that's because of param_rp_o
12:31 timotimo 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 timotimo all it does is directly invoke that method
12:31 timotimo and those methods are even jitted
12:32 lizmat timotimo: I think it's because AT-POS is one of a list of candidates with named parameters ?
12:33 timotimo well, the actual candidates are pointed out in the profile
12:33 timotimo so i thought it's already using those exact candidates
12:33 lizmat example ?
12:33 timotimo you mean the code i'm talking about?
12:34 timotimo or the profile file?
12:34 lizmat the actual candidate that you see taking 17% ?
12:35 timotimo it's postcircumfix:<[ ]>( \SELF, int $pos) is raw { SELF.AT-POS($pos) }
12:35 lizmat perhaps the \SELF ?
12:35 timotimo it has 4,867,763 invocations and takes 3416.02ms all in all (but 2998.79ms without what the AT-POS takes)
12:37 lizmat is this in an array ?
12:37 timotimo well, the param_rp_o is the one that extracts the SELF
12:37 lizmat or a List ?
12:38 timotimo it's a native num array
12:38 timotimo there's also some accesses to a native num CArray
12:38 lizmat ah, native num
12:39 lizmat are you sure it actually hits the multi method AT-POS(numarray:D: int $idx) is raw {
12:39 lizmat ?
12:40 timotimo let's see
12:40 lizmat also, I'm wondering whether it is the :D on the numarray, that may be the reason ?
12:40 timotimo i can try compiling without the :D
12:40 timotimo it does hit that exact candidate
12:43 timotimo but as i said, the AT-POS itself is jitted and only takes a tiny amount of time itself
12:47 timotimo doesn't seem to make a difference at all
12:47 timotimo removing the :D
12:54 timotimo i really don't know what you use in assembly to turn a double into an int
12:55 * lizmat neither
12:56 lizmat 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
12:56 timotimo it'll only be a tiny win, though :(
12:56 timotimo i'm surprised the floor method doesn't get completely inlined
12:58 timotimo :\
12:58 timotimo floor is implemented like this:
12:58 timotimo unbox the num to check "isnanorinf"
12:58 timotimo unbox the num, floor it to a floored num
12:58 timotimo coerce the floored num to a big integer
12:59 timotimo to be fair, there's no reason i'm giving the compiler or runtime to know i'm only dealing with non-big integers
13:01 timotimo sorry, not "to a floored num"
13:09 timotimo and the next step after the floor is going to be to unbox again :|
13:18 vendethiel joined #moarvm
13:18 dalek MoarVM: df13f01 | jnthn++ | src/io/sync (2 files):
13:18 dalek MoarVM: Mark thread blocked for GC when doing sync reads.
13:18 dalek MoarVM:
13:18 dalek MoarVM: Otherwise, one thread blocked on I/O can cause all other threads to
13:18 dalek MoarVM: block when they need to do their next GC run until the read returns.
13:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/df13f01702
13:37 dalek Heuristic branch merge: pushed 91 commits to MoarVM/even-moar-jit by bdw
13:39 brrt joined #moarvm
13:39 brrt \o
13:40 brrt timotimo: whaddayaneed
13:40 brrt :-P
13:40 timotimo floor_n and probably also ceil_n?
13:40 brrt oh, right
13:40 timotimo though i have no clue how good that'll be for my code
13:41 timotimo 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 timotimo like, a really small part
13:41 brrt the 'coerce double to int' is 'cvttsd2si'
13:42 timotimo oh, i could have guessed that
13:42 timotimo hm. but how do we handle really big doubles here?
13:43 timotimo oh, we have fromnum_I
13:43 timotimo right, so floor_n actually does coerce num to num
13:44 brrt aye
13:45 brrt not sure what 'tsd' stands for
13:45 timotimo "thousand"
13:45 brrt pretty sure the 'd' is for double :-)
13:45 timotimo oh, floor wouldn't get jitted, because we lack jitting for coerce_nI anyway
13:46 brrt convert with truncation scalar dobule-pression floating point value to signed doubleword integer
13:46 vendethiel joined #moarvm
13:46 dalek joined #moarvm
13:48 brrt which becomes a signed quadword if used on quadword operands
13:48 brrt so
13:49 brrt (what's coerce_nI?)
13:49 brrt annoying, is what it is
13:50 timotimo it can be turned into a jit-friendly op like the other big int ops already have been
13:53 brrt i'd assume so, yes
13:53 timotimo well, i know it can
13:53 timotimo because i'm doing it right now
13:53 timotimo just replaced MVMObject *result with result_type and return the result
13:53 brrt at some point in the indefinete future, we should start seeing all the function calls as performance drains, in the JIT, at least
13:53 timotimo so if you want you can already write the support code fro that :)
13:53 brrt :-)
13:53 timotimo yeah
13:54 brrt (don't write a JIT for a highly dynamic language, then, brrt)
13:54 timotimo heh.
13:57 dalek MoarVM: 29997a1 | timotimo++ | src/ (3 files):
13:57 dalek MoarVM: make MVM_bigint_from_num jit-friendly
13:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/29997a1cf6
14:00 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 timotimo so i can't test it easily
14:02 timotimo and i have no clue if the nqp test suite tests coerce_nI at all
14:03 brrt now, wait a minut
14:03 brrt we're talking about coerce_nI right?
14:04 brrt coerce_In is already jitted, but it is not using the xmm0 return address for its value
14:04 brrt oh, nm, it is alright
14:04 timotimo sorry, yeah, num to Int
14:06 brrt :-)
14:06 dalek MoarVM: 651b6c1 | timotimo++ | src/jit/graph.c:
14:06 dalek MoarVM: jit coerce_nI as a call to bigint_from_num
14:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/651b6c1700
14:06 brrt you're just seconds before me
14:07 brrt but, no, sorry
14:07 brrt that's wrong
14:07 brrt coerce_nI has 3 arguments, second is type, third is num
14:09 brrt (competitive speed coding :-o)
14:09 brrt competitive collabarative speed coding
14:10 cognominal joined #moarvm
14:10 BinGOs joined #moarvm
14:11 brrt very net reliability
14:18 mst joined #moarvm
14:18 dalek MoarVM: b16fdca | brrt++ | src/jit/graph.c:
14:18 dalek MoarVM: MVM_bigint_from_num takes a type argument
14:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b16fdca7e5
14:22 timotimo joined #moarvm
14:25 zakharyas joined #moarvm
14:29 travis-ci joined #moarvm
14:29 travis-ci MoarVM build failed. Bart Wiegmans 'MVM_bigint_from_num takes a type argument'
14:29 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/117978123 https://github.com/MoarVM/MoarVM/compare/651b6c17006b...b16fdca7e50e
14:29 travis-ci left #moarvm
14:29 timotimo .. uh oh?
14:30 timotimo damn, yeah
14:30 timotimo i totally wronged that implementation
14:31 brrt wait, what
14:31 brrt broken build?
14:31 timotimo well, you fixed it
14:31 brrt not sure i did
14:31 brrt (i only noticed becuase i spent some time on making the same mistake though :-))
14:31 brrt yep, it's broken
14:32 timotimo ah, syntax error
14:32 timotimo missing a }
14:33 brrt yep
14:33 dalek MoarVM: 82535c3 | brrt++ | src/jit/graph.c:
14:33 dalek MoarVM: Typo fix!
14:33 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/82535c3045
14:33 brrt sorry about that :-)
14:34 timotimo clearly the nqp test suite didn't test coerce_nI :)
14:35 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 brrt not enough attention being paid, clearly
14:40 dalek MoarVM: 0e285c8 | jnthn++ | src/ (4 files):
14:40 dalek MoarVM: Fix missing inclusion of frames in heap snapshots.
14:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0e285c8395
14:46 travis-ci joined #moarvm
14:47 travis-ci MoarVM build passed. Bart Wiegmans 'Typo fix!'
14:47 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/117984759 https://github.com/MoarVM/MoarVM/compare/b16fdca7e50e...82535c304507
14:47 travis-ci left #moarvm
14:58 travis-ci joined #moarvm
14:58 travis-ci MoarVM build passed. jnthn 'Fix missing inclusion of frames in heap snapshots.'
14:58 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/117986633 https://github.com/MoarVM/MoarVM/compare/82535c304507...0e285c839525
14:58 travis-ci left #moarvm
15:14 brrt joined #moarvm
15:39 lucasb joined #moarvm
16:03 brrt joined #moarvm
16:07 zakharyas joined #moarvm
16:09 jnthn heh, these snapshots would be a lot more useful if NQP set debug type names :)
16:12 brrt joined #moarvm
16:36 dalek MoarVM: fcad1c5 | jnthn++ | src/6model/bootstrap.c:
16:36 dalek MoarVM: Set debug_name in a few more places.
16:36 dalek MoarVM:
16:36 dalek MoarVM: So we get better output in the heap snapshot viewer.
16:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fcad1c5c48
16:37 FROGGS jnthn: is there a screenshot available that shows how that snapshot viewer looks like?
16:39 jnthn not yet :)
16:40 jnthn Will share some more stuff on it soon
16:45 ggoebel16 joined #moarvm
16:50 dalek MoarVM: 7425902 | jnthn++ | src/profiler/heapsnapshot.c:
16:50 dalek MoarVM: Factor more allocations into frame size.
16:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7425902639
17:05 vendethiel joined #moarvm
17:14 dalek MoarVM: d663972 | jnthn++ | src/6model/ (44 files):
17:14 dalek MoarVM: Add REPR API for getting unmanaged size.
17:14 dalek MoarVM:
17:14 dalek MoarVM: That is, the amount of memory a REPR has behind it that is not under
17:14 dalek MoarVM: the direct management of the GC.
17:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d663972107
17:14 dalek MoarVM: a6fa12b | jnthn++ | src/profiler/heapsnapshot.c:
17:14 dalek MoarVM: Factor in unmanaged size to heap snapshot.
17:14 dalek MoarVM:
17:14 dalek MoarVM: Though nothing is actually implementing the API yet.
17:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a6fa12b32b
17:15 dalek MoarVM: 4e1817e | jnthn++ | src/6model/reprs/MVMArray.c:
17:15 dalek MoarVM: Implement unmanaged_size for VMArray REPR.
17:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4e1817e53b
17:24 dalek MoarVM: b0482df | jnthn++ | src/6model/reprs/MVMArray.c:
17:24 dalek MoarVM: Add a missing `static`.
17:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b0482df800
17:24 dalek MoarVM: 19ccc86 | jnthn++ | src/6model/reprs/MVMString.c:
17:24 dalek MoarVM: Implement unmanaged_size for VMString REPR.
17:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/19ccc866db
17:36 dalek MoarVM: df9f8b8 | jnthn++ | src/6model/reprs/NFA.c:
17:36 dalek MoarVM: Implement unmanaged_size for NFA REPR.
17:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/df9f8b8f4e
17:59 domidumont joined #moarvm
18:05 pochi joined #moarvm
18:06 dalek MoarVM: 30bad8d | jnthn++ | src/profiler/heapsnapshot.c:
18:06 dalek MoarVM: Fix use-after-realloc bug in heap snapshot taking.
18:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/30bad8daa8
18:08 jnthn Here's a session with the heap analyzer so far, on a Rakudo heap snapshot: https://gist.github.com/jnthn/35fb78323d715dda93fc
18:10 jnthn The numbers are still underestimates in places, because unmanaged_size needs implementing on some more REPRs
18:11 jnthn The analysis app itself is here: https://github.com/jnthn/p6-app-moarvm-heapanalyzer
18:17 jnthn dinner break now :)
18:28 moritz what's the moarop_mapper?
18:50 jnthn https://github.com/perl6/nqp/blob/master/src/vm/moar/QAST/QASTOperationsMAST.nqp#L331
18:51 diakopter yeah that's on me
18:52 diakopter I was thinking: .oO( surely we won't ever have a thousand of these )
18:54 diakopter we could have it return an array of pre-processed args instead of a curried code object, maybe it'd be smaller
18:54 diakopter I mean. I think that was me.
18:55 ilmari joined #moarvm
18:56 diakopter 74,000 NQPArrays with average size around 100 bytes
18:56 mojca joined #moarvm
18:56 diakopter seems small
18:57 diakopter 32 bytes per bootint; seems high
18:58 diakopter I guess a bunch of pointers for 64-bit memory /o\
18:59 diakopter .oO( surely many of these metaobject pointers could be compressed to use only 8 bits or something
18:59 diakopter )
19:01 diakopter OR, all these counter/index integers could be native ints
19:15 camelia joined #moarvm
19:19 retupmoca joined #moarvm
19:20 arnsholt joined #moarvm
19:20 dalek joined #moarvm
19:52 FROGGS joined #moarvm
20:33 colomon joined #moarvm
21:17 dalek MoarVM: 8d6e8ed | timotimo++ | src/6model/reprs/P6bigint.c:
21:17 dalek MoarVM: unmanaged_size for P6bigint (if it IS_BIG)
21:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8d6e8ed0e9
21:38 colomon joined #moarvm
21:43 geekosaur joined #moarvm
21:46 zakharyas joined #moarvm
21:56 dalek MoarVM: 0d25193 | jnthn++ | src/profiler/heapsnapshot.c:
21:56 dalek MoarVM: Fix regression in emitting references.
21:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0d25193926
21:58 timotimo jnthn: anything good we can do for/with gen2-roots?
22:03 jnthn timotimo: Yeah, I need to include those still, I think
22:03 jnthn Will get there
22:03 jnthn In the meantime, something awesome
22:04 jnthn I just added a couple of new features to the heap snapshot analyzer
22:04 jnthn And...it just explained our EVAL leak!
22:04 timotimo well, the gen2 roots are just things in the gen2 that point at the nursery, right?
22:04 timotimo so we'll end up seeing them from a full collection anyway
22:04 timotimo i just mean we might want to analyze them individually (well, as a set of roots, really)
22:05 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 jnthn But I want to think about that a little more :)
22:05 jnthn This is awesome
22:05 jnthn https://gist.github.com/jnthn/f67379ff234861729f34
22:06 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 timotimo oh, we hold a list of all SCs we are compiling and we're not dropping those references?
22:06 jnthn We're meant to pop SCs from that when we're done compiling them, yes. :)
22:07 jnthn Apparently we don't
22:07 jnthn I...would not have guessed that :)
22:07 timotimo right. it's something we already do, but apparently we do wrong
22:07 timotimo so, very well done :)
22:38 jnthn 'night, #moarvm
22:43 vendethiel joined #moarvm
23:41 geekosaur joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary