|
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 | ||
| however.... | |||
| 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 | |
| hmmm | |||
| 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 | ||
| ;p | |||
| 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 | ||
| github.com/MoarVM/MoarVM/issues/293 | |||
| 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 | |||
| yeah? | |||
| 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
|
|||