# IRC log for #moarvm, 2016-11-24

All times shown according to UTC.

Time Nick Message
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
06:57 domidumont joined #moarvm
07:03 domidumont joined #moarvm
08:19 domidumont joined #moarvm
08:40 zakharyas joined #moarvm
09:31 vendethiel- joined #moarvm
10:17 xtt joined #moarvm
11:19 mtj_ joined #moarvm
11:52 vendethiel joined #moarvm
12:54 viki A gdb breakpoint is placed at the start of the line, right? So when it breaks the line hasn't been executed yet?
12:58 viki I guess I can try out with a small program first.
13:01 viki And the answer is: yes, before the line runs.
13:06 viki I don't follow the p *ia output tho... it gives "\$7 = {used = 1, alloc = 32, sign = 0, dp = 0x2da28e0}" so what's the value of the number? is it 1?
13:10 jnthn I'd guess it's in dp?
13:10 jnthn I suspect that's where the digits are represented
13:10 viki Ah
13:29 viki How big a number can fit into MVMnum64? Can 8.9E-308 fit?
13:29 jnthn It's just an IEEE double
13:30 jnthn See table in https://en.wikipedia.org/wiki/IEEE_754-1985
13:30 viki aha
13:30 jnthn So, looks like "no"
13:30 jnthn It's just out of range
13:31 jnthn Oh but
13:31 viki So then nqp::div_In(Int \$l, Int \$r) op is not working right on MoarVM?
13:31 viki r: use nqp; say nqp::div_In(1, 2**1024)
13:31 camelia rakudo-moar 6e7782: OUTPUT«0␤»
13:31 camelia ..rakudo-jvm 76b061: OUTPUT«6.0E-309␤»
13:32 jnthn The range in that table does not factor in denormals
13:32 viki r: use nqp; say nqp::div_n(1, 2**1024)
13:32 camelia rakudo-moar 6e7782: OUTPUT«This type cannot unbox to a native number: P6opaque, Int␤  in block <unit> at <tmp> line 1␤␤»
13:32 camelia ..rakudo-jvm 76b061: OUTPUT«This type cannot unbox to a native number␤  in block <unit> at <tmp> line 1␤␤»
13:33 viki r: use nqp; say nqp::div_n(1e0, 2e0**1024)
13:33 camelia rakudo-moar 6e7782, rakudo-jvm 76b061: OUTPUT«0␤»
13:34 jnthn In double precision:
13:34 jnthn The positive and negative numbers closest to zero (represented by the denormalized value with all 0s in the Exp field and the binary value 1 in the Fraction field) are
13:34 jnthn ±2−1074 ≈ ±4.94066×10−324
13:34 jnthn From the page I linked
13:35 jnthn So it'd seem it is representable as denormal?
13:35 viki hmm
13:37 brrt joined #moarvm
13:37 viki sounds fancy pants :)
14:03 viki Well, I think I fixed at least half a bug :D
14:03 jnthn :)
14:09 timotimo jnthn: got an idea why turning the types of some of Attribute's BOOTSTRAPATTRs from int into int8 gives us segfaults when trying to gc_mark P6opaque objects?
14:10 jnthn No idea
14:11 jnthn nqp: say(int8.^name)
14:11 camelia nqp-moarvm: OUTPUT«Confused at line 2, near "say(int8.^"␤   at gen/moar/stage2/NQPHLL.nqp:625  (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:panic)␤ from gen/moar/stage2/NQP.nqp:908  (/home/camelia/rakudo-m-inst-2/share/nqp/lib/nqp.moarvm:comp_unit)␤ from gen/moar…»
14:11 jnthn nqp: say(int8.HOW.name(int8))
14:11 camelia nqp-moarvm: OUTPUT«int8␤»
14:11 jnthn Hm, it exists
14:11 timotimo does it sound worthwhile to go through the bootstrap and make things less wasteful?
14:11 jnthn Well, BOOTSTRAPATTR only gets used a handful of times
14:12 jnthn The heap analyzer suggests things like Parameter are far more costly
14:12 timotimo right
14:12 timotimo however
14:12 timotimo i wasn't changing BOOTSTRAPATTR, i was changing Attribute :)
14:12 jnthn Ah
14:12 jnthn No idea why it'd be so explosive. Worth fixing.
14:13 timotimo though it could be easier to just change things that already use Attribute rather than BOOTSTRAPATTR
14:14 timotimo is it actually enough to change the things inside BOOTSTRAP.nqp? there's at least two cases where we rely on the layout of a specific p6opaque
14:15 timotimo (those are both in rakudo's container_ops)
14:48 timotimo jnthn: do you know if turning MVMArrayBody into a union instead of struct prevents me from taking its address with prefix:<&>?
14:48 jnthn Uhhh...why would you do that? :)
14:49 timotimo maybe i want to store arrays with not-so-many-elements inside the array body directly :)
14:49 timotimo arrays with just two or three int64 items are rather common apparently during rakudo compilation
14:52 viki Well, my first PR against master sent: https://github.com/MoarVM/MoarVM/pull/442
14:52 viki I don't 100% understand the code involved, but it fixes 3 tickets...
14:55 nine /win/win 13
14:55 timotimo that's a win/win situation
14:55 timotimo catch 13!
14:56 timotimo oh, btw, jnthn: in one of the whateverable bots i've got a valgrind log of a free-use-free_again situation inside some workloop stuff
14:56 jnthn workloop?
14:57 timotimo eventloop*
14:57 timotimo concblockingqueue_poll frees the thing, then the same function uses the thing, and then the same function tries to free it again
14:58 jnthn o.O
14:58 timotimo yup-the-yup
14:58 timotimo This is Rakudo version 2016.11-44-gf928a20 built on MoarVM version 2016.11-20-g0f7277a
14:58 jnthn Ugh. Was gonna say, e998e2e5b0933 went in Nov 1st
15:00 jnthn And is in that territory
15:01 timotimo it does free directly, though. not via the gc it seems like
15:02 timotimo https://gist.github.com/timo/063a86b2b01a259f9488e6d06c57014d - have a look-see for yourself if you like
15:04 jnthn Will in a bit; need branecells for \$dayjob design task at the moment :)
15:06 timotimo sure
15:12 timotimo so ... is some piece of work being put into the concblockingqueue twice?
15:12 timotimo or maybe an item is put into two concblockingqueues at the same time and both free it individually
15:19 timotimo during compilation i see a crapton of i64 arrays being deserialized that have two-digit numbers in them
15:19 timotimo i wish it were a bit easier to figure out what they are for
15:19 diakopter lengths of somethings?
15:20 timotimo oh hey diakopter
15:20 diakopter are they deterministic
15:20 diakopter in value
15:20 diakopter heyyyyyyy
15:20 timotimo um, i haven't checked
15:21 timotimo i think it might be interesting to have smaller int arrays available in nqp
15:21 timotimo for example, i imagine the numbers that are involved in statelists aren't going to go beyond 32bits
15:21 timotimo er, statelists?
15:22 timotimo i mean NFAs
15:24 diakopter heh yeah
15:25 diakopter but I think at runtime they're in C arrays anyway
15:25 timotimo except they live two lives at the same time
15:25 timotimo every NFA gets serialized as its native NFA form, and then on top of that a whole bunch of NQPArrays
15:25 diakopter maybe the arrays are profile counters
15:26 timotimo how do you mean?
15:26 diakopter the values; is a profiler running
15:27 timotimo these are values that are being deserialized from a serialized blob
15:27 timotimo it'd be quite terrible if we wrote profiler data into compiled blobs
15:28 diakopter stranger things have happened, lol
15:28 timotimo it's been so long since i last touched underlying metamodel stuff ... now i don't quite know how i would create an 8bit or 16bit int MVMArray with only nqp ops
15:28 diakopter but yeah I agree it's far-fetched
15:36 timotimo seems easier than i thought; at least to fake it :D
15:37 timotimo just newtype with knowhow and 'MVMArray', and compose it with the right arguments in the composition hash
15:40 timotimo but clearly that's not good enough for the long term
15:41 diakopter I bet such a type is already instantiated globally
15:42 timotimo inside nqp?
15:42 diakopter in moar, yeah
15:43 diakopter ohh nqp ops
15:43 diakopter yeah I bet it's accessible from the HLL
15:43 timotimo i can verify that
15:44 diakopter registered or such
15:45 timotimo i don't really want to install more slots in the hll struct and add more ops to get these things :\
15:45 timotimo anyway
15:45 timotimo throughout the build of nqp, we never build any mvmarrays with sizes other than 8 bytes per slot
15:46 diakopter oh
15:47 timotimo the first time we get different sizes (and also the first time we see unsigned rather than just signed) is in building the core setting
15:49 timotimo https://gist.github.com/timo/fbd1ccb77a5b067c51ae7117b23f931d - what do you think of this, diakopter?
15:50 timotimo how does it believe it's MVMArrayBody when i'm clearly taking its address with the & operator?
15:50 diakopter struct layout fail?
15:50 diakopter no idea
15:50 diakopter sec
15:51 timotimo could be i don't understand unions
15:59 FROGGS joined #moarvm
16:00 FROGGS o/
16:00 timotimo yo FROGGS
16:17 brrt good * #moarvm
16:17 timotimo yo brrt
16:23 timotimo diakopter: there would be great memory savings (and Grammar.moar size savings probably) from fixing up the branch i started a long time ago to save NFAs only as the NFA, rather than the NFA and the list of states ...
16:25 timotimo if you're interested, i can point you in the right direction
16:32 brrt memory savings ftw
16:32 brrt i'd forgottten what i was  doing, but i recall now
16:33 brrt i need to change the tile structure a bit
16:33 brrt the template-less tile thingy
16:33 brrt i wonder if there is  a way in which I can do that and not immediately break the expr jit
16:33 brrt i.e. the existing allocator
16:58 timotimo Grammar.moar is about 3.6 megs in size :)
16:58 timotimo that's too much :)
17:01 brrt waaay to much
17:03 timotimo did i say i wanted to build something that'll build a graphical representation of what's in the serialized blob in a .moar file? %)
17:35 vendethiel joined #moarvm
18:07 domidumont joined #moarvm
18:16 cygx joined #moarvm
18:19 cygx timotimo: re your gist, cf https://irclog.perlgeek.de/perl6/2016-11-24#i_13622070
18:20 timotimo oooooh
18:20 timotimo fantastic!
18:20 timotimo and i thought i was already too generous with parenthesis in my macros
18:26 dalek MoarVM/mvmarray_in_situ_storage: f35da54 | timotimo++ | src/ (4 files):
18:26 dalek MoarVM/mvmarray_in_situ_storage: initial draft of how mvmarray could store data in-situ
18:26 dalek MoarVM/mvmarray_in_situ_storage: review: https://github.com/MoarVM/MoarVM/commit/f35da546a7
18:26 timotimo (pushing this so i can reach it from my laptop)
19:05 jnthn timotimo: Hmm
19:06 vendethiel- joined #moarvm
19:06 jnthn timotimo: That...is very likely going to be incompatible with my vmarray plans to deal with thread safety
19:06 jnthn (Which boil down to VMArray becoming 1 pointer big, and pointing to a fixed size buffer that starts with a header indicating its size, elems, and start)
19:11 * FROGGS .oO( Talk early, talk often )
19:12 * jnthn shoulda paid more attention earlier to the union question...
19:29 domidumont joined #moarvm
19:47 domidumont joined #moarvm
19:51 timotimo oh, i see
19:52 timotimo well, that pointer could also point directly after itself :P
19:52 timotimo but we don't really have variable-sized objects that'd allow for that
20:08 Ven joined #moarvm
20:22 Ven joined #moarvm
21:01 zakharyas joined #moarvm
21:11 Ven joined #moarvm
21:22 Ven_ joined #moarvm
21:32 timotimo jnthn: do you think it'd be worth it to take \$why out of a few things inside BOOTSTRAP?
21:36 Ven joined #moarvm
21:39 timotimo sorry. \$!why, of course
21:39 timotimo i'm not sure how big the overhead would be for that, i.e. if it'd be worth the trade
21:42 timotimo well, at least Parameter's \$!flags can become 32bit instead of 64bit, as we only use 25 bits of it so far
21:43 timotimo given a perl6 -e '' fetches about 6900 Parameter objects, that is at least a few kilobytes of space theoretically won
21:43 timotimo unless of course it's thrown out again by alignment constraints, but it should be fine
21:53 jnthn Hm, if there's a pointer after it, it probably aligns to an 8-byte boundary...
21:54 timotimo these objects are pointers all the way down
21:54 timotimo until you reach flags
21:55 timotimo anything speak against putting rw, onlystar, and yada into a single flags field for Routine?
21:55 timotimo (yes, routine isn't really hot, but still ...)
21:58 jnthn Not really, just needs the work to do it
21:58 timotimo good
21:58 jnthn We have quite a few routines too (every sub, method)
21:58 timotimo right, but my primary optimization target is perl6 -e '' ;)
21:58 * timotimo tries the BOOTSTRAP changes with the jvm backend
22:08 Ven joined #moarvm
22:11 timotimo aha, the jvm dies with "cannot use reference attribute as native attribute" when building the core setting
22:11 timotimo trying without my changes to verify
22:16 timotimo of course it works now
22:22 jnthn You'll have to change everything - including ops written in Java and probably also C - to fix this up, I suspect
22:23 timotimo hm, do we have similar problems on moar?
22:23 timotimo (this isn't about making these flags a single flag field, just about moving them to the end and giving them a smaller size)
22:23 jnthn Yes, potentially
22:24 jnthn We have C structures shadowing some P6opaques
22:24 timotimo i thought it's only ContainerDescriptor and that one other thing
22:24 timotimo Rakudo_Scalar
22:27 jnthn I thougth there was something about returning too
22:31 timotimo hum. are you refering to actual .c files?
22:33 timotimo because if so, i really only see those two
22:33 timotimo maybe whatever you're remembering got moved to moar recently-ish?
22:45 timotimo can't fold \$!onlystar into \$flags because it's part of the invocation protocol
22:59 timotimo every avenue i explore for making things better results in frustration ;(
23:01 timotimo i was really positive and enthusiastic about the container descriptor sharing ... until it b0rked
23:11 jnthn I fear we've had quite a lot of the easy wins by now... :S
23:16 timotimo i thought i could maybe share [ord1, ord2] lists generated when we build the nfa for enumcharlist
23:16 timotimo but it turns out there's only like 30 all in all in the entirety of rakudo's grammar
23:16 timotimo oh, hm. a lot more inside rakudo's core setting
23:17 timotimo and the ord1 almost perfectly predicts the ord2
23:20 timotimo aha, i missed a bunch of creations that i should also log
23:38 timotimo m: say .&uniname for 91, 123
23:38 camelia rakudo-moar 64343d: OUTPUT«LEFT SQUARE BRACKET␤LEFT CURLY BRACKET␤»
23:38 timotimo i don't think we have to match those with ignorecase %)