|
09:14
FROGGS joined
09:38
dalek joined
10:04
pyrimidi_ joined
13:50
mst joined,
mst_ joined
13:57
mst joined,
brrt joined
|
|||
| dalek | arVM: f47a6ce | jnthn++ | src/6model/reprs/MVMMultiCache.c: Remove not-exactly-right and unhelpful comment. |
14:07 | |
|
14:47
brrt joined
|
|||
| brrt | good * #moarvm | 14:53 | |
| timotimo | hey brrt | 14:55 | |
| brrt | hey timo | ||
| how are you | |||
| timotimo | i'm all right, i think | 14:56 | |
| i'm glad i had a bit of energy to start work on the split_bb_at function, but i'ven't been able to actully test it yet | |||
| brrt | hmmmm | 14:58 | |
| i have an idea | |||
| timotimo | oh? :) | ||
| brrt | put in test code that splits basic blocks at every 'say' op | ||
| they are basically never used | |||
| timotimo | that's not bad | 14:59 | |
| brrt | count on me for you daily evil hacks ;-) | ||
| timotimo | \o/ | ||
| brrt | if i ever start blogging again, i should have a sections 'madmens hacks' | 15:00 | |
| anyway | |||
| i will hopefully have time again to work on moarvm in some weeks | |||
| because, i am soon to be finished with my thesis | |||
| timotimo | \o/ | 15:01 | |
| with the exprjit, guardcontconc and friends will hopefully become quite a bit cheaper | |||
| brrt | some time, at least, because i'm starting my new job just afterwards | ||
| timotimo | because right now we have that as "check if it's concrete, call its .fetch and check the result against the provided type" | ||
| but i expect the .fetch (aka decont) could be quite a bit cheaper if it were spesh'd, too | 15:02 | ||
| brrt | well, i think the point of that is more that we should internalize the rakudo extensions | ||
| timotimo | i.e. if we were able to turn it into a sp_p6oget_o or sp_geto or what it's called | ||
| that, too | |||
| but i don't see how that directly interacts with what i mentioned? | |||
| brrt | i think... hmmm.. | 15:03 | |
| timotimo | also, after a guardcontconc (or whatever) we're likely to have a decont following it to use the actual value inside, so we'll end up deconting at least twice | ||
| brrt | right | ||
| so we should kill that bit where we have to decont in the guard | |||
| timotimo | hm, though, making the decont better relies on knowing the type, right? | ||
| brrt | i think so... | 15:04 | |
| timotimo | maybe that's also part of what's guarded for. so instead, we should replace the upcoming decont with just re-using the value we found when guarding? maybe? | ||
| timotimo checks the code again | |||
| brrt | this is another one of these areas where i don't really know | ||
| timotimo | this piece of perf report is so jumbled %) | 15:05 | |
| the asm is all over the place with regards to the original source code | |||
| brrt | we could possibly replace the sp_guardcontconc with a guard for the container, a decont, and a guard for the result | ||
| possibly one of the reasons why we didn't do that before was that we couldnt allocate a scratch register in spesh, and now we cna | 15:06 | ||
| *can | |||
| timotimo | what made me aware of this is this | ||
| i ran a random example code under perf record -g | |||
| and the instruction perf jumped to when i told it to annotate mvm_interp_run, was in "if (r.o && IS_CONCRETE(r.o) && STABLE(r.o) == want_v)" | |||
| brrt | unrelated thought: i realised that all technical projects have 3 phases, whcih are research, design, and development; no project can skip any of those phases;, most development methodologies either conciously or not tend to ignore one of them | 15:07 | |
| timotimo | that's in guardcontconc | ||
| brrt | uhuh..... (what does perf record -g do?) | 15:08 | |
| timotimo | same as perf record, but also records the stack above whatever got sampled | ||
| need it to get inclusive vs exclusive measurements | |||
| brrt | aha | 15:09 | |
| (for instance, 'waterfall' tends to ignore or minimize the research phase; while 'scrum' tends to focuso on development to the detriment of all else, substituting meetings for design) | 15:10 | ||
| psch | brrt: i think specifically for waterfall that's an artifact of how new and quickly-growing IT is | 15:12 | |
| brrt: as in, in traditional engineering projects, waterfall comes with a research phase | |||
| brrt | i tend to think that waterfall is kind of a strawman | ||
| timotimo | waterfall is meant to have the research phase in the beginning | ||
| where you run interviews with users and such | 15:13 | ||
| brrt | in traditional engineering projects, prototypes and mockups are par for the course | ||
| and macquettes etc | |||
| timotimo | i don't know what a macquette is | ||
| brrt | it is possibly a dutch word | ||
| timotimo | sounds a bit french :) | ||
| brrt | a small scale model | ||
| timotimo | ah | ||
| mockup :) | |||
| brrt | right | ||
| timotimo | well, it sounds like that at least? | ||
| brrt | yeah | 15:14 | |
| you get the point at least :-) | |||
| timotimo | aye | ||
| brrt | well, point is, there is nothing wrong with a 'waterfall' model /if/ a prototype has proven that the principle is sound | ||
| jnthn was part of a team doing scrum for some months, and can relate to the meetings/design thing | 15:15 | ||
| brrt | and neither is there anything wrong with agile, /if/ it manages to keep a proper place for research and design | ||
| timotimo | i wonder if the split_bb_at api should also take an extra BB and make sure that gets properly hooked up | ||
| jnthn | There's this notion of "ok, this task is bit, let's break it down" | 15:16 | |
| timotimo | rather than asking the consumer of the API to do that | ||
| brrt | what extra bb is that | ||
| timotimo | well, i split bbs because i want to turn the tail of the bb into two parts | ||
| brrt | yeah, i think it isn't quite obvious that this is a design thing to do | ||
| jnthn | But to me decomposition is one of the hardest things to get right. | ||
| timotimo | in my use case that's the original tail and a deopt bridge | ||
| brrt | uhuh | ||
| jnthn | And there's no way I can do it optimally in a meeting. | ||
| I don't even think it wants doing by a group. | |||
| psch | well, "design by comitee" is meme for a reason | 15:17 | |
| +t | |||
| brrt | could also explains why most engineers hate having to make estimates, because we're often asked to do this before we have even started the research phase | 15:18 | |
| jnthn | timotimo: I'd keep split_bb as just doing the splitting. Done one thing and do it well. :) | ||
| timotimo | mhm, right | ||
| brrt agrees | |||
| jnthn | *Do one... | ||
| timotimo | though i think i want to add a second function to do the splicing, then | ||
| jnthn | timotimo: Sure :) | 15:19 | |
| timotimo | it'd have to touch the forked bb to add an extra succ, and an extra child, as well as give the new bb its pred | ||
| we don't link from child to parent, at least | |||
| though maybe at some point we'll want to? | |||
| because succ vs parent isn't 1:1, right? | 15:20 | ||
| jnthn | child/parent are about the dominance tree | ||
| next/succ are about the CFG | |||
| timotimo | yeah | 15:21 | |
| is dominator tree only interesting for creating the SSA, though? | |||
| won't we want to sometimes ask the dominator tree what's what? | |||
| jnthn | Well, we use it as a traversal order for one | ||
| timotimo | that part i remember | ||
| jnthn | And I believe get some safety promises as a result | 15:22 | |
| rt.perl.org/Ticket/Display.html?id...8a78838a6d is some kind of MoarVM bug around call captures...ran out of energy to hunt it for now | 15:23 | ||
| Can reproduce it just by cloning the Perl6-Base64 module of ugexe and running the second test under perl6-valgrind-m | 15:24 | ||
| Will continue on it next week but if anyone fancies a bug hunt... :-) | 15:25 | ||
| bbiab | |||
|
15:49
domidumont joined
15:55
domidumont joined
16:10
domidumont joined
17:04
domidumont joined
17:59
rurban_ joined
19:51
domidumont joined
21:15
zakharyas joined
21:45
TimToady joined
|
|||