Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-16

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
03:00 lizmat joined #moarvm
04:23 Peter_R joined #moarvm
06:29 brrt joined #moarvm
06:35 brrt \o
06:35 * brrt has a cold, apparantly
07:01 Ven joined #moarvm
07:12 nebuchadnezzar o/
07:18 masak brrt: get well soon!
07:18 brrt joined #moarvm
07:30 FROGGS joined #moarvm
07:33 FROGGS morning nebuchadnezzar
07:33 FROGGS you got my messages?
07:49 zakharyas joined #moarvm
07:54 nebuchadnezzar FROGGS: hi, I got your message and I thank you
07:54 nebuchadnezzar FROGGS: I think I'll integrate the patches on 2015.05 I'm preparing
07:54 FROGGS \o/
07:54 FROGGS that's awesome!
07:56 FROGGS if it wasn't that unlikely that dyncall/libuv has trouble with mips(el)/s390x/sparc/hurd I'd attempt that too
07:56 FROGGS nebuchadnezzar++
08:02 nwc10 I have a suspicion/fear that the way to go for portability is to be able to use either dyncall or libffi (or whatever the oterh one is called) to implement Nativecall
08:02 nwc10 with Configure probing
08:05 brrt joined #moarvm
08:07 FROGGS nwc10: yeah :S
08:07 FROGGS though, I would not mind getting into dyncall and porting that/supporting the devs
08:08 FROGGS since dyncall only has two devs, and a better bus number would certainly help both groups
08:09 brrt masak: thanks :-)
09:00 lizmat joined #moarvm
09:04 brrt joined #moarvm
09:50 Ven joined #moarvm
10:23 * jnthn hopes brrt++'s cold gets better just in time :)
10:38 FROGGS :P
10:52 * FROGGS recommends https://www.youtube.com/watch?v=fsfln3czVHM - James Darren (Vic Fontaine) - Just In Time
11:25 brrt joined #moarvm
11:35 brrt \o
11:35 brrt jnthn: are you online?
11:39 brrt hmm, seems i need a restart
11:39 brrt bbiab
11:54 brrt joined #moarvm
11:54 * brrt back
12:41 jnthn brrt: Yes, but teaching
12:41 jnthn So only sorta half here :)
12:41 brrt ah, ok
12:41 jnthn But ask stuff and I'll asnwer async if needed :)
12:41 brrt well, i'll bother you later today then, if there's any chance you'll be here
12:42 brrt i was wondering if you could point me in a direction to start. I want to make a prototype tree-matching code generator, and i want to patch dynasm, and i wanted to do that in the coming two weeks
12:42 brrt today, i feel like that is a bit ambitious maybe
12:43 jnthn Well, dynasm is perhaps going to be the critical dependency in all of thos
12:43 jnthn *this
12:43 brrt yes, that's true
12:43 jnthn I mean, I imagine with the current JIT code-base you could do some tweaks that make simple use of the dynasm changes
12:44 brrt hmm yes. i've considerd that one too
12:44 brrt 'what would be the minimum change that would conform to what i've promised'
12:45 brrt and the answer would be - without a principled approach, a combinatorial explosion :-P
12:45 jnthn I wasn't suggesting you do etensive changes to the JIT we have now, just use your dynasm changes in a couple of places
12:46 brrt but i have no dynasm changes yet. although it would be a good 'test', i guess
12:47 FROGGS brrt: would it help to explain what dynasm changes is this about to a n00b?
12:49 jnthn brrt: Yes, I meant 1) work on dynasm changes, 2) do some minimal usage of them in the current JIT to prove the changes don't bust stuff that already work and at least stand a chance of working, 3) dig into the tree thingy
12:49 brrt right :-) ok. that's a good idea
12:49 jnthn Otherwise you'll end up without a tree thingy but no decent way to test it, I fear.
12:49 brrt well, you could test a tree thingy using only the lower register set
12:49 jnthn True :)
12:50 brrt ok, it's a good idea
12:50 jnthn The other thing about doing dynasm changes first is it gets the scary "hack on an unknwon codebase" phase out of the way early. :)
12:50 brrt yes, i agree
12:54 jnthn anything else? :)
13:00 brrt not at the moment. and i'll bother you again if i find the need
13:00 brrt :-)
13:01 jnthn ok :)
13:01 jnthn have fun! ;)
13:02 jnthn And get well soon :)
13:02 brrt thanks :-)
13:26 lizmat joined #moarvm
13:28 Ven joined #moarvm
13:52 * brrt afk for a bit
15:00 FROGGS joined #moarvm
15:36 Ven joined #moarvm
15:37 TimToady jnthn: mentioned it on #perl6, but I guess the stats are really more moarvm specific: https://gist.github.com/TimToady/fe858b303f9d033365d9
15:37 TimToady 1st column is # of frames traversed searching, and 2nd column is average # of frames traversed per lookup
15:37 TimToady (compiling the setting)
15:38 FROGGS TimToady: is it that horrible that it seems to be for me?
15:38 TimToady tl;dr the 1-per-frame cache is getting overwhelmed by the dynvar usage
15:39 jnthn The QAST -> MAST stage is muchly guilty
15:39 jnthn Does that number incorporate the cache?
15:39 TimToady yes
15:39 jnthn wow
15:39 jnthn I suspect I could get rid of some of the QAST -> MAST ones
15:40 TimToady well, there are bandaids, and then there are fixes; we could get rid of $*ACTIONS too, in fact we plan to
15:40 jnthn The QAST -> MAST ones are more out of convenience than genuine need, tbh.
15:40 TimToady but we really need a more direct link from the current frame to the nearest cache, which should probably be associated with the innermost frame that actually declares a dynvar
15:40 FROGGS TimToady: how do we get rid of $*ACTIONS?
15:41 TimToady it should be associated with the current language as a method lookup, probably
15:41 FROGGS ahh
15:42 TimToady but we by following such direct pointers to caching frames, we could skip all the frames that don't declare a dynvar
15:44 FROGGS so like a spiderweb all inner frame would have a linked list of dynvar-declaring frames?
15:44 FROGGS inner frames*
15:44 TimToady and we could probably make the caches authoritative, in the sense that when you run out of the chain of caches, you don't need to look in the lexpad, because the last cache always has the entry to begin with
15:44 TimToady but you always just copy to the innermost cache on reference
15:45 FROGGS[mobile] joined #moarvm
15:46 JimmyZ_ joined #moarvm
15:46 TimToady and well-cached lookups are usually just a single deref followed by a hash lookup
15:46 * JimmyZ_ wonders what is qtree and what it will improve
15:47 japhb .tell [ptc] Oh, I wasn't complaining about the general set of is-approx patches (dealing with very large or small numbers well is important to the use case), I was specifically saying that that particular commit seemed to have a couple bugs in it.
15:47 japhb Sigh, ww
15:56 TimToady beyond that, there are only 98 dynamic variables in use in the compiler, so maybe interning those names can save a lot of hashing too
16:12 jnthn Not sure it saves hashing much, but it can make comparison cheaper
16:19 timotimo jnthn: if i could make one wish, could you make code-gen for localref/local and lexicalref/lexical work properly and build the optimization support for that? that has me superstumped and i keep seeing fallout from the lex-to-loc optimization missing *all over the place*
16:30 FROGGS[mobile] jnthn: are there problems (design wise) with TimToady++'s proposal?
16:30 FROGGS[mobile] thinking of osr and such
16:51 TimToady as long as any abstract level can maintain a pointer to its correct cache, I don't see a problem
16:51 TimToady we already look for dynvars in inlines and such, so it's really just replacing the current one-entry cache with a pointer to a cache that we know won't be overridden between here and there
16:52 TimToady (we probably don't bother caching $/ and such, despite those being officially dynvars, since we're very likely to find one very soon in the standard frame search)
16:55 TimToady which we can know it won't be overridden if we only skip frames that don't declare new dynvars
16:55 TimToady would be interesting to figure out what percentage of frames actually do declare new dynvars...
16:59 TimToady though that number shouldn't affect the efficiency of a direct cache lookup; it's only on a cache miss that you have to search other caches, and the efficiency of that will depend on the number of chained caches, and on the nearby usage patterns of the particular variable, since that will tend to install cached entries in intermediate caches
17:00 TimToady it's arguable whether installing a new cache entry should go into only the nearest cache, or if any intermediate caches should be populated as well, if there's a long chain
17:01 TimToady since the nearest cache's dynamic scope might be exited over and over, losing the cache entry
17:01 TimToady so I'd argue that some intermediate cache should also be populated
17:01 TimToady populating all intermediate caches is proably overkill
17:02 TimToady just populating one "halfway" down the chain of caches will tend to tighten up the misses over time
17:03 TimToady so my gut feeling is the sweet spot is to populate two caches, the nearest/innerest one, and one intermediate one if the chain is longer than two or so
17:04 * japhb likes the idea of a self-tightening cache
17:05 TimToady otoh, picking the frames that declare dynvars will tend to be the correct spot to cache at least for the dynvars that were declared there
17:05 TimToady it's the other dynvars that might not share the same usage pattern
17:06 TimToady and might keep clearing their cache at just the wrong level, in the worst case
17:06 TimToady doubtless PhDs have been earned over this sort of stuff :)
17:07 PerlJam throw a fibonacci sequence in there and you're probably good  ;)
17:08 TimToady ayup
17:10 TimToady there actually was a good use for fibonacci sequences back in the day when sorting was done with a set of magtapes sized to a fibonacci number
17:30 prammer joined #moarvm
17:52 timotimo jnthn: does that seem feasible?
17:53 jnthn timotimo: What TimToady is suggesting? I need to think it through some more.
17:53 timotimo no, what my wish is :)
17:53 jnthn Oh
17:53 jnthn That's a SMOP :)
17:53 jnthn It just didn't hit top of my list yet.
17:54 jnthn (Been worring about spesh bugs, conc bugs, etc.)
17:54 jnthn But I guess it's not too much work
17:54 timotimo it is high on my list that's sorted by "frustration divided by assumed work it'd take to fix"
17:54 jnthn ah, ok :)
17:54 timotimo but i haven't been able to make headway
17:54 jnthn Yeah, was gonna say, you did a good chunk of the work, no?
17:54 jnthn ooh, nearly 8pm and I didn't dinner yet
17:54 timotimo a tiny chunk :)
17:56 timotimo it's in an nqp branch called mast_localref_3 (the _n is for number of times the branch has been rebased onto latest master, and it could be rebased again)
17:57 jnthn :)
17:57 jnthn Tomorrow I finish up the month's teaching, Thu I got another $dayjob task, and then Fri I'm back to Perl 6 hacking for most of the rest of June, it seems :)
17:58 jnthn So I'll get to it sometime soonish :)
17:58 jnthn In the meantime...pub food calls :)
17:58 jnthn o/
18:02 timotimo thanks :)
19:56 brrt joined #moarvm
20:03 brrt (jnthn++ and TimToady++ doing all the difficult perl6 opt work while /me gets to take credit ;-))
20:03 masak brrt++ # case in point :P
20:04 brrt :-P
20:10 brrt oh, i have an idea wrt to codegen
20:10 brrt i can make a specific instruction matching a subset of the IR tree an object
20:10 brrt literally, a tile object
20:11 brrt that tile object can contain a function pointer to a void (*emit)(MVMThreadContext *tc, dasm_State **Dst, MVMJitTile *tile);
20:12 FROGGS joined #moarvm
20:13 * jnthn back
20:14 brrt joined #moarvm
20:14 brrt \o
20:14 jnthn o/ brrt
20:16 brrt specifically, that saves me from having to replicate all of the x86 in enums and definitions, because it's implicit in the code executed in the emit function
20:16 jnthn brrt: I guess you'll be doing the dynasm work in https://github.com/MoarVM/dynasm ?
20:17 brrt yes, that's the plan
20:17 brrt and when that works i'll try to get it accepted upstream
20:17 jnthn +1
20:18 jnthn Guess that's best done towards the end of the project, when the changes have been exercised some :)
22:38 LLamaRider joined #moarvm
22:50 vendethiel joined #moarvm
22:57 nebuchadnezzar .tell FROGGS I integrated your 2 patches, my package is waiting approval of my mentor dod++
22:58 nebuchadnezzar erf, no yoleaux here
22:58 nebuchadnezzar FROGGS[mobile]: I integrated your 2 patches, my package is waiting approval of my mentor dod++

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary