01:21 zakharyas joined 01:48 ilbot3 joined 03:50 mtj_ joined 05:13 domidumont joined 05:18 domidumont joined 05:41 brrt joined
brrt good * #moarvm 05:49
nwc10 good *, brrt 05:50
brrt i'm stuck on a design choice again 05:52
the basic underlying issue is that i'd like the register allocator to be able to insert tiles (code) that refers to live range keys, rather than hard-coded registers 05:55
as that would allow the actual registers to be assigned in a single register assignment step
nwc10 I don't know enough to be helpful here
brrt (and failing to do so would mean that the tile insertion step would have to wait until after the register assignment step, which means that it requires another buffer, and, yada yada yada) 05:56
nwc10 you can tell "me" sutff, but I'm about as effective as a teddy bear
brrt heh
teddy bears are definitely useful
05:57 domidumont joined
brrt anyway, maybe if i just put it out here, then someone maybe has a better idea 05:57
(sidenote: I have a feeling that throughout this process, the chain from 'i need this feature' and 'this needs to be implemented' is… long, and convoluted) 06:00
because the design question is: - store tree node + order position in the tile, vs. store the node 'opcode' 06:01
the node = the position of the refered thing, e.g. 1,17, the node 'opcode' is the refered thing itself, e.g. IF, DO, ADD, etc. 06:05
take it as a given that we need the opcode itself in later stages, because we need to know where the IFs are that yield different 'value paths' and hence need resolving 06:06
(like PHI nodes)
however, we only want to do that for the 'postorder' IF nodes 06:08
which, ironically, do nothing otherwise
the 'inorder' IF nodes represent labels and jumps etc
but are not relevant from the perspective of the register allocator
so the question is, what labeling do we use for the inorder/preorder tiles to distinguish them from postorder tiles 06:11
(why cant it just be a flag?)
my information-preserving instincts say: store both the node position and the tree-order position 06:16
the counterpoint: that is both difficult to deal with (which tree-order position is postorder, exactly) 06:17
and redundant, because if (as is my plan) at tile generation time you already perform all necessary node extraction, then you don't need the exact node position anymore 06:18
not having the node means that you have to store the 'self' node in the 'values' tile array instead 06:20
that is okay… but… ugly
furthermore, you still need the 'opcode' itself 06:21
i think that conceptually, opcode + self node in values is cleaner than self-node + order position, because it removes all tree order considerations 06:24
that means that the opcode for synthetic ops still needs to be synthetic, but because it doesn't refer to anything anymore, why not
(one of the problems of an earlier approach was that using e.g. -1 as a sentinel value conflicted with repeated access into the array using it as an offset 06:25
okay, i'm decently happy about that conclusion 06:27
06:43 brrt joined
nine wrl: github.com/niner/Inline-Perl6/blob...r/Perl6.xs embeds a moarvm and Perl 6 in Perl 5. It's a bit hacky, but not as bad as I expected it to turn out. 06:49
brrt: so you're gonna go with opcode + self? 06:52
brrt i think so yeah, that eliminates all references to the tree at that point….. 06:53
hang on :-(
we do kind of need, or rather, want, the default storage location
07:51 btyler joined 07:54 andrzejku joined
andrzejku hello 07:54
brrt hi andrzejku 07:57
andrzejku I come here to help you
brrt (hope i spelled that right)
well, that's great
andrzejku yeah
brrt how would you like to help
andrzejku who is scrum master? 07:58
brrt, 08:00
brrt we… are an open source project. we don't have a scrum master
andrzejku oh okay
brrt, who is team leader than?
brrt i was not under the impression that anyone was 08:01
jnthn is a very active contributor, and some might say he's the 'architect'
project leader, i could agree with 08:02
team leader, I probably wouldn't think he'd agree with
andrzejku oh okay
brrt maybe it is better if you could tell me (us) what you are looking for 08:03
psch andrzejku: is there a specific question you'd want to ask a hypothetical team leader?
andrzejku yep
I am looking for position for me
brrt okay, there are plenty of things to do, really
what are some things that you'd be interested in? 08:04
have you seen our issue tracker on github?
andrzejku ye there plenty bugs
brrt right :-)
so maybe the easiest thing to start with would be to pick something that seems tractable
and if you need any help or advice, just ask 08:05
andrzejku w8 i will back soon [kid] 08:06
brrt this is irc, there is an expectation of asynchrony
andrzejku: this is a good issue to start with i think 08:10
stmuk_ jnthn: last comment on github.com/tadzik/panda/issues/324 looks interesting! (in case you haven't seen it) 08:12
hmm the BSD reproduce works on Bay Trail which doesn't have HLE AFAIK (?) - I suspect its not supported in the BSD libraries 08:52
08:55 andrzejku joined
andrzejku brrt, stmuk_ thnks 08:56
09:11 brrt1 joined
jnthn stmuk_: I'd kinda like it to turn out to be Moar's fault because then we can actually do something about it then... 09:37
stmuk_: I had a hard time seeing where our locking code could be wrong in this instance, alas. I'll dig some more. 09:38
stmuk_ jnthn: if you need a shell accn on FreeBSD (where the prob is more easily reproduced than Linux) give me a shout 09:42
andrzejku some bad things happened during my nqp build 09:45
it looks for generated nqp's files but they weren't copied to expected path
I should do cp ./lib/MAST/* ./share/nqp/lib/MAST/ 09:46
and it looks there no --backend prefix anymore 09:47
timotimo at the moment all our parts still expect everything to be installed with the same --prefix 09:48
mst has a few patches in the works to make it properly separate the three things
stmuk_ timotimo: I think mst has his own patches to fix that .. see the YAPC::EU talk
snap :) 09:49
timotimo i discussed it with him on irc, too :)
really looking forward to getting his cleanups for the build system mainlined
andrzejku also one test failed t/moar/05-decoder.t .................... Lookup by name of unknown REPR: Decoder
timotimo that probably means your moarvm is too old for this nqp 09:50
though that makes me wonder why it'd go through Configure.pl without complaining about the version
andrzejku no it is not the last commit were Date: Wed Sep 28 14:40:39 2016 +0200
by Johathan 09:51
timotimo well, that's strange
what does ls src/6model/reprs/Decoder.* give you in the moarvm checkout? 09:52
.c, .h, and .o?
andrzejku yeah
exactly 09:53
timotimo the only thing i could imagine is that you have more than one moarvm in your system and for some reason the "make test" is using the wrong one
jnthn stmuk_: Will do, thanks. There's a few more things I can try locally first.
andrzejku timotimo, yeah it is possible
timotimo cat ./nqp-m in your nqp, it'll tell you the path it's using for the moar binary; and also check out cat (which nqp-m) to see what it's actually using from your path? 09:55
andrzejku the path is proper 09:56
wait I will check something 09:57
ok it runs command 09:58
prove -r --exec "./nqp-m" t/nqp t/hll t/qregex t/p5regex t/qast t/moar t/serialization t/nativecall
and the file got proper path 09:59
timotimo if you have the newest moarvm code, and you've built and installed it successfully, i don't see how it could complain about the Decode repr missing :| 10:00
andrzejku timotimo, wait let me check it manually x)
timotimo unless you've got a nqp-j that it's running and for some reason it runs the moar tests by accident 10:01
which would be quite astounding
andrzejku timotimo, hey what's nqp.moarvm? 10:11
brrt1 it's the executable bytecode for the NQP compiler 10:13
timotimo well, it's just the "main" file
andrzejku and this? --target=mbc --output=NQPP5QRegex.moarvm gen/moar/stage2/NQPP5QRegex.nqp 10:15
timotimo that's our support for perl5 regexes
(non-complete support)
andrzejku moar nqp.moarvm 10:19
should be the same as perl6 interpreter
brrt no. 10:21
but it's complicated :-)
andrzejku brrt, maybe on another hand what I am trying to do ;D 10:22
timotimo well, nqp isn't perl6 for starts
andrzejku I want to run decoder test
using moar
timotimo moar nqp.moarvm blah blah should be the same as nqp-m blah blah 10:23
andrzejku yeah I know
brb 10:24
11:42 andrzejku joined 12:07 andrzejku joined 12:46 andrzejku joined 13:15 andrzejku joined 13:55 andrzejku joined 14:12 andrzejku joined 14:53 diakopter joined 14:54 nwc10 joined 15:47 brrt joined 16:08 domidumont joined
timotimo jnthn: would it make any sense to give the fixed size alloc one lock per size class instead of a global lock? 16:19
jnthn Not sure...I think they'd still contend heavily 16:20
On promoted frames, for example
timotimo i know that when i tried to multithread my cellular automaton i got a very big amount of overhead for invocation, i believe 16:21
jnthn What we really want is to introduce thread-local pages and a scheme for handing them back to the global one if they empty 16:22
timotimo ah
that'd be nice, yeah
otherwise i was considering committing epic tight-cohesion sin by building a "lock the allocator for allocating *two* things" function 16:23
because right now we're doing lock+unlock+lock+unlock when we allocate the environment + the frame
jnthn *nod*
timotimo i'm not sure if it's likely that something snatches the lock in between those two operations from another thread 16:24
and i don't know how costly exactly it is to unlock and immediately lock again; like, is there a memory fence involved?
jnthn For locking surely yes
timotimo probably not; there might even be HLE (that doesn't crash)
ok, for locking. so it could be worthwhile to have either a allocate-two-things-please, or maybe a separate "lock", "allocate", "unlock" functions 16:27
jnthn Sure, but it'd be better still to fix up the thread local thing :)
timotimo but in the long run, thread-local pages sounds like a necessity
17:34 andrzejku joined 17:44 FROGGS joined 19:10 Ven_ joined 20:25 Ven_ joined 20:46 Ven_ joined 20:55 Util joined 21:01 Ven_ joined