| timotimo | jnthn: would you accept a fact "visible at a deopt point" that we would put on versions of registers that are current whenever a deopt annotation is hit? | 00:27 | |
| (and then i'd also introduce a "transferrable_facts" mask that would prevent this fact from being propagated by "set" instructions ... or something to that effect) | |||
| one thing that annoys me a bit is that we still have to have data in redundant registers, even if they could safely be omitted | 00:28 | ||
|
01:11
kjs_ joined
02:48
ilbot3 joined
02:50
JimmyZ joined
02:58
zakharyas joined
03:22
JimmyZ joined
04:59
JimmyZ joined
|
|||
| dalek | arVM/longlit: c697119 | TimToady++ | src/6model/reprs/NFA.c: add debugging to NFA runner |
08:50 | |
|
08:56
kjs_ joined,
kjs_ left
09:02
woolfy joined,
lizmat joined
09:10
woolfy left
09:33
FROGGS[mobile] joined
09:51
lizmat joined
10:28
woolfy joined
10:43
FROGGS joined
|
|||
| jnthn | timotimo: As far as I can tell, the trick with bumping usage over de-opt boundaries is already sufficient to let us delete writes that won't be needed beyond the point. | 11:52 | |
| timotimo | hm, ok, so if i have something like | 11:57 | |
| opthatwrites r5(10) | |||
| set r20(3) r5(10) | |||
| i can turn that into opthatwrites r20(3) if and only if r5(10) only has one usage and that is the set | |||
| jnthn | Correct. | ||
| That'll nail a lot of cases. | 11:58 | ||
| Since a lot of sets are "chains" that eventually write to a more persistent location. | |||
| timotimo | i'll be car-ing a lot today, i'll see if i can get something whipped up tonight | 12:00 | |
| have you seen what our sink code specializes to in many cases? | 12:01 | ||
| jnthn | Not recently | ||
| Though I know I rewrote the sink code generation a while back to it should stand a chance of specializing away in many cases. | |||
| timotimo | if i understand correctly, we definitely get a sp findmeth with a cache, but the "can" invocation is "left behind" | ||
| jnthn | oh... | 12:02 | |
| But...we should in general have a good clue what the type of the thing we're sinking is. Odd. | |||
| timotimo | i should find a specific spot where this happens before i bother you with it any more, i guess | 12:03 | |
| nqp::push($rpa, $!nextiter) if $!nextiter.defined; | 12:06 | ||
| seems like we try to sink there | |||
| jnthn | Interesting :) | 12:07 | |
| timotimo | that's Parcel of List | ||
| oh | |||
| it could be trying to sink the else-part of the if branch | |||
| ah, yes, it sinks the return value of the if | 12:08 | ||
| which is either what push_o returns (is that the list or the first argument?) or the wval the else-branch gives (which i believe is Nil) | 12:09 | ||
| another instance where we don't get rid of the sink is in ListIter's reify; the very first unless ... { } block gets sink'd | 12:11 | ||
| so maybe it's a thing in general that branches don't sink very happily yet | 12:14 | ||
| doing something like constant folding across PHI could be interesting | 12:33 | ||
| jnthn | We don't do much with our PHIs yet... | 12:34 | |
| timotimo | yup | 12:37 | |
| if we have a PHI where on one side we have a known constant argument and on the other we have an unknown argument we could in theory move the operation before the PHI and have only one side of it constant folded | 12:38 | ||
|
12:45
btyler joined,
woolfy joined
13:29
zakharyas joined
15:29
woolfy left
16:39
vendethiel joined
17:46
hoelzro joined
17:51
FROGGS_ joined
18:18
tgt joined
18:23
woolfy joined
18:35
lizmat joined
19:28
brrt joined
|
|||
| brrt | \o | 19:31 | |
| long story short | |||
| i want to create a static binary for perl6-m | |||
| why? static binaries are the future with regard to deployments / devops; also a static binary should play well into a process isolation system | 19:32 | ||
| but.. what i find is that moar is started with any number of libpaths and a single .moarvm binary. so i think we'd need to 'collapse' that somehow | 19:35 | ||
| jnthn | Not to mention that you need a solution for the ext ops which are dyn linked | ||
| brrt | hmm | 19:37 | |
| that, too | |||
| didn't think of that | |||
| japhb | And the future of deployments is actually the present: containers | 19:44 | |
| I believe someone had built a docker container with r-m in it .... | 19:45 | ||
| btyler | containers are awesome, but (imo) require a lot more commitment/learning than plopping an executable blob somewhere | 19:51 | |
| brrt | containers are more awesome with static binaries :-) | 19:52 | |
| btyler | I'd be happy to put together a r-m dockerfile if there isn't one floating around | ||
| I think it's telling how much positive reaction golang got RE being able to just toss a single executable around to deploy | 19:53 | ||
| brrt | my point is that - with containers and all - people are rather not in the business of figuring out all dependencies and making them match nicely | ||
| btyler | totally | ||
|
20:27
kjs_ joined
|
|||
| brrt | anyway.. what i wanted to know is, is there any way to determine without evaluating anything which modules and libraries a moarvm bytecode file requires? | 20:33 | |
| i have a sneaking suspicion the answer is going to be 'no' | 20:34 | ||
| jnthn | 'no' | 21:04 | |
| brrt | :-) | 21:05 | |
| why not | |||
| jnthn | Well, in no small part 'cus you can't do the same at Perl 6 level... :P | ||
| brrt | hmm | 21:06 | |
| so that invalidates a static perl6 fakeexcutable, no? | 21:07 | ||
| jnthn | It's not that Perl 6 itself is unpredictable/non-static in what it needs | 21:08 | |
| It's that Perl 6 module loading in general is | |||
| So you could still make a manifest of stuff to bundle | |||
| brrt | ok, clear enough | 21:09 | |
| :-) i suppose the rakudo makefile knows about what is needed | 21:10 | ||
| jnthn | You could even implement a mechanism such that loadbytecode instructions first consult the stuff you've got bundled. | ||
| brrt | hmm. that should be simple, considering that loadbytecode pre-consults the loaded bytecode hashtable | 21:13 | |
| TimToady | note that official modules are supposed to be immutable, so are static once given a permanent identity | 21:15 | |
| so maybe we should warn if you make a fakecutable out of something that isn't locked down | 21:17 | ||
| brrt | as far as i'm concerned, i only want to make a perl6-binary | ||
| not having fakecutables for user stuff is perfectly acceptable | 21:18 | ||
| jnthn | But also nice if we can :) | ||
| brrt | agreed | ||
| might also help with startup time | 21:19 | ||
| TimToady | as soon as you've checked something into git, it has a sort of permanent identity | ||
| brrt | oh, we already have a MVM_cu_from_bytes | ||
| TimToady | so maybe that could be a temporary expedient for user files | ||
| jnthn | brrt: Yes, I designed it that way to try and make such cleverness possible :) | 21:20 | |
| brrt | excellent | 21:22 | |
| brrt afk | 23:04 | ||
|
23:04
brrt left
23:08
colomon joined
|
|||