03:00 lizmat joined 04:23 Peter_R joined 06:29 brrt joined
brrt \o 06:35
brrt has a cold, apparantly
07:01 Ven joined
nebuchadnezzar o/ 07:12
masak brrt: get well soon! 07:18
07:18 brrt joined 07:30 FROGGS joined
FROGGS morning nebuchadnezzar 07:33
you got my messages?
07:49 zakharyas joined
nebuchadnezzar FROGGS: hi, I got your message and I thank you 07:54
FROGGS: I think I'll integrate the patches on 2015.05 I'm preparing
FROGGS \o/
that's awesome!
if it wasn't that unlikely that dyncall/libuv has trouble with mips(el)/s390x/sparc/hurd I'd attempt that too 07:56
nebuchadnezzar++
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
with Configure probing
08:05 brrt joined
FROGGS nwc10: yeah :S 08:07
though, I would not mind getting into dyncall and porting that/supporting the devs
since dyncall only has two devs, and a better bus number would certainly help both groups 08:08
brrt masak: thanks :-) 08:09
09:00 lizmat joined 09:04 brrt joined 09:50 Ven joined
jnthn hopes brrt++'s cold gets better just in time :) 10:23
FROGGS :P 10:38
FROGGS recommends www.youtube.com/watch?v=fsfln3czVHM - James Darren (Vic Fontaine) - Just In Time 10:52
11:25 brrt joined
brrt \o 11:35
jnthn: are you online?
hmm, seems i need a restart 11:39
bbiab
11:54 brrt joined
brrt back 11:54
jnthn brrt: Yes, but teaching 12:41
So only sorta half here :)
brrt ah, ok
jnthn But ask stuff and I'll asnwer async if needed :)
brrt well, i'll bother you later today then, if there's any chance you'll be here
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
today, i feel like that is a bit ambitious maybe
jnthn Well, dynasm is perhaps going to be the critical dependency in all of thos 12:43
*this
brrt yes, that's true
jnthn I mean, I imagine with the current JIT code-base you could do some tweaks that make simple use of the dynasm changes
brrt hmm yes. i've considerd that one too 12:44
'what would be the minimum change that would conform to what i've promised'
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
brrt but i have no dynasm changes yet. although it would be a good 'test', i guess 12:46
FROGGS brrt: would it help to explain what dynasm changes is this about to a n00b? 12:47
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
jnthn Otherwise you'll end up without a tree thingy but no decent way to test it, I fear.
brrt well, you could test a tree thingy using only the lower register set
jnthn True :)
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. :)
brrt yes, i agree
jnthn anything else? :) 12:54
brrt not at the moment. and i'll bother you again if i find the need 13:00
:-)
jnthn ok :) 13:01
have fun! ;)
And get well soon :) 13:02
brrt thanks :-)
13:26 lizmat joined 13:28 Ven joined
brrt afk for a bit 13:52
15:00 FROGGS joined 15:36 Ven joined
TimToady jnthn: mentioned it on #perl6, but I guess the stats are really more moarvm specific: gist.github.com/TimToady/fe858b303f9d033365d9 15:37
1st column is # of frames traversed searching, and 2nd column is average # of frames traversed per lookup
(compiling the setting)
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
jnthn The QAST -> MAST stage is muchly guilty 15:39
Does that number incorporate the cache?
TimToady yes
jnthn wow
I suspect I could get rid of some of the QAST -> MAST ones
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.
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
FROGGS TimToady: how do we get rid of $*ACTIONS?
TimToady it should be associated with the current language as a method lookup, probably 15:41
FROGGS ahh
TimToady but we by following such direct pointers to caching frames, we could skip all the frames that don't declare a dynvar 15:42
FROGGS so like a spiderweb all inner frame would have a linked list of dynvar-declaring frames? 15:44
inner frames*
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
but you always just copy to the innermost cache on reference
15:45 FROGGS[mobile] joined 15:46 JimmyZ_ joined
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
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
Sigh, ww
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 15:56
jnthn Not sure it saves hashing much, but it can make comparison cheaper 16:12
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:19
FROGGS[mobile] jnthn: are there problems (design wise) with TimToady++'s proposal? 16:30
thinking of osr and such
TimToady as long as any abstract level can maintain a pointer to its correct cache, I don't see a problem 16:51
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
(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:52
which we can know it won't be overridden if we only skip frames that don't declare new dynvars 16:55
would be interesting to figure out what percentage of frames actually do declare new dynvars...
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 16:59
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:00
since the nearest cache's dynamic scope might be exited over and over, losing the cache entry 17:01
so I'd argue that some intermediate cache should also be populated
populating all intermediate caches is proably overkill
just populating one "halfway" down the chain of caches will tend to tighten up the misses over time 17:02
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:03
japhb likes the idea of a self-tightening cache 17:04
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
it's the other dynvars that might not share the same usage pattern
and might keep clearing their cache at just the wrong level, in the worst case 17:06
doubtless PhDs have been earned over this sort of stuff :)
PerlJam throw a fibonacci sequence in there and you're probably good ;) 17:07
TimToady ayup 17:08
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:10
17:30 prammer joined
timotimo jnthn: does that seem feasible? 17:52
jnthn timotimo: What TimToady is suggesting? I need to think it through some more. 17:53
timotimo no, what my wish is :)
jnthn Oh
That's a SMOP :)
It just didn't hit top of my list yet.
(Been worring about spesh bugs, conc bugs, etc.) 17:54
But I guess it's not too much work
timotimo it is high on my list that's sorted by "frustration divided by assumed work it'd take to fix"
jnthn ah, ok :)
timotimo but i haven't been able to make headway
jnthn Yeah, was gonna say, you did a good chunk of the work, no?
ooh, nearly 8pm and I didn't dinner yet
timotimo a tiny chunk :)
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:56
jnthn :) 17:57
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 :)
So I'll get to it sometime soonish :) 17:58
In the meantime...pub food calls :)
o/
timotimo thanks :) 18:02
19:56 brrt joined
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
brrt :-P 20:04
oh, i have an idea wrt to codegen 20:10
i can make a specific instruction matching a subset of the IR tree an object
literally, a tile object
that tile object can contain a function pointer to a void (*emit)(MVMThreadContext *tc, dasm_State **Dst, MVMJitTile *tile); 20:11
20:12 FROGGS joined
jnthn back 20:13
20:14 brrt joined
brrt \o 20:14
jnthn o/ brrt
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 github.com/MoarVM/dynasm ?
brrt yes, that's the plan 20:17
and when that works i'll try to get it accepted upstream
jnthn +1
Guess that's best done towards the end of the project, when the changes have been exercised some :) 20:18
22:38 LLamaRider joined 22:50 vendethiel joined
nebuchadnezzar .tell FROGGS I integrated your 2 patches, my package is waiting approval of my mentor dod++ 22:57
erf, no yoleaux here 22:58
FROGGS[mobile]: I integrated your 2 patches, my package is waiting approval of my mentor dod++

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!