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

Powered by Cro and the Raku® Programming Language.

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

Thank you!