00:13 lizmat joined 00:57 lizmat joined 04:28 vendethiel joined 05:00 FROGGS joined 06:00 FROGGS joined 07:04 nebuchadnezzar joined 07:14 FROGGS joined 07:32 Ven joined 07:36 lizmat joined 07:48 oetiker_ joined, zakharyas joined 07:51 oetiker joined 07:56 brrt joined 08:50 JimmyZ_ joined
brrt hey, about the JIT... something I was looking into yesterday; how to define the registers in a machine-indepndent way 09:43
hmm
never mind
jnthn Make it work on one machine first :)
brrt yeah, exactly that :-) 09:44
i think the important abstraction is probably the idea of register classes
10:21 FROGGS joined 10:32 JimmyZ__ joined 11:34 Ven joined 11:47 JimmyZ_ joined 11:48 Ven joined 12:25 Ven joined
brrt oh, there is a pretty nice circularity, for you (and me) to ponder 12:40
see, there's the issue of representing stores to locals
if you regard the moarvm opcodes literally, they form statements 12:41
e.g. add is r0 = r1 + r2
the expression tree 'expressifies' the calculation; it just says 'the value of r0 is calculated by (add r1 r2)' 12:43
the assignment is implicit, left out
for correctness, they have to be added somewhere
(the assignments, that is) 12:44
actually, that's not true; they can be left out of the tree altogether, and have the value-management layer insert stores as needed
*however* and this is where i'm probably thinking ahead further than is proper 12:45
ideally you do represent them in the tree, because then the instruction-selector can take them into account
i.e. if r0 equals r1, the best way to compile it is: add [address-of-r0], r2 12:46
jnthn Well, to me it's more like "there are points where the assignment to the real register is demanded" 12:47
brrt (timotimo added that to the current JIT some time ago)
getting to it
jnthn Where by real I mean the VM callframe
brrt :-)
right, that thing :-)
timotimo did i break something? 12:48
brrt no, you made something
timotimo ooooh
brrt well, there is that matter
timotimo i don't remember that at all! ;)
oh, right, having add directly add into a memory location 12:49
i remember that
i have no idea if it was worth anything at all, though
brrt the circularity is that you want to store values, at latest, when you run out of registers to hold them 12:50
however, you only know how much registers you need after tiling (or perhaps during tiling)
similar arguments apply to full spills induced by e.g. function calls 12:51
jnthn Why is it a circularity? I see the stores we place becuase of deopt/calls/barriers as "constraints" 12:52
You can introduce extra stores ahead of the constraints if you need to for spilling 12:53
And when you hit the constraint point you can know you already spilled
And if not, you'd better spill here. 12:54
brrt the circularity is that you want to use the store information during tiling, but you might add stores after tiling, during register allocation, or (at earliest) during tiling
because only during tiling do you know how much registers you're using
jnthn ah
brrt but i agree on the constraints 12:55
hmmm
jnthn I note that the spills you do for CPU register allocation could be handled in The Usual Way by spilling to the C stack, however, 'cus you know that by the time it really matters where they are you'll have done a real store.
brrt yes 12:56
that is true
that's probably a good strategy, albeit a bit complex 12:59
jnthn Less complex than the problem you're already facing? :) 13:00
brrt a bit :-) 13:02
ok, rephrased that way
the question is then to add stores (and loads) to the tree in a way that is compatible with restraints 13:03
eh, constraints :-)
jnthn *nod* 13:04
brrt gives you the possibility for both having and eating cake
jnthn I think we will want to handle deopts in the same tail-y way as write barriers too, fwiw.
brrt aye
13:04 Ven joined
jnthn So if you never deopt or hit a write barrier, then you'll never branch off the "main" code 13:05
brrt invokish and throwish nicely translate themselves to node types, fwiw :-)
jnthn Which is great for cache locality and branch prediction and so on.
brrt nods 13:06
jnthn My hope in this is that we'll reach a point where simple integer loops working with native integer arrays and doing math ops will basically be able to run and run without needing to every write back to the MoarVM registers :) 13:07
*ever
brrt yever
eh
braino
yes
jnthn 'cus we'll have re-written the array accesses in to primitive things too. 13:08
timotimo oh, i didn't merge profile_native_calls yet
jnthn Of course, we still have to do the "must we GC" backbranch check.
That's another of those taily things I guess.
brrt i think you'll argue for tailing them to
too
hmmm
jnthn Yeah, in fact your only non-tail ones are C function calls :) 13:09
timotimo i don't think anything speaks against profile_native_calls
brrt ok, i have to scribble this stuff down somewhere
JimmyZ_ 's hope is that the point class benchmark is as fast as luajit( speaking of one's hope) šŸ˜Š 13:18
[Coke] Will the first version of brrt's new jit work on 64bit os x? 13:22
jnthn [Coke]: I don't see why not, in so far as it should work everywhere the current JIT is. In practice, it's easy to make a platformo when working at this level. 13:23
[Coke] sweeeeeeet.
thanks, groovy moar devs.
13:26 Ven joined
brrt [Coke]: yes, OS X just uses the POSIX ABI, so everything should just work 13:27
i'll guarantee we're nowhere near luajit soon :-)
i need a whole lot more summers for that ^^ 13:28
timotimo :S
brrt well, what did you expect? :-) 13:32
luajit is really *blazingly* fast
... consider that luajit was written when lua was a mature language; perl6 has yet to have it's first release 13:33
JimmyZ_ agrees 13:34
jnthn wow, 200g of chilis is a larger amount than I realized... 13:37
uh, ww
JimmyZ_ šŸ˜Š 13:39
timotimo don't put them all in your mouth at the same time :) 13:45
jnthn My mouth isn't actually big enough for that amount :P
timotimo :) 13:46
brrt the difficulty probably lies with the chemical contents rather than the quantity 13:50
timotimo well, there are people who have built up a significant tolerance for spicy food 13:52
and as far as i know, jnthn likes spicy food
i eat spicy food so rarely that even mildly fiery food gives me a hard time :|
jnthn My tolerance is relatively high, yeah. 13:53
I think so far I've only been served one dish that was just too hot to really enjoy eating.
13:53 FROGGS_ joined
jnthn I cooked one that came close to that too, but thankfully it landed just on the "pleasantly extremely spicy" side :) 13:55
(A friend grew naga jolokia at home, and gave me a couple of cook with :))
[Coke] just found this wonderful spicy relish called wickles that he's putting on everything these days. 13:57
timotimo i'm convinced that the way spicyness is experienced by people who enjoy spicy food must be severely different from the way i experience it >_> 13:59
JimmyZ_ eats spicy food too 14:00
jnthn timotimo: It's even more complex than that; there's different natures of spicy. 14:01
timotimo i haven't been able to distinguish/notice yet
jnthn It's most noticeable in Sichuanese food compared to Indian food; the spices in the former actually numb the mouth, whereas the latter don't. 14:02
JimmyZ_ there are different spicy food in different province of china. 14:04
jnthn JimmyZ_: Oh, indeed; I was just calling Sichuanese out as one that had a notably different nature of spicy :)
JimmyZ_ sichuanese food is one of provinces
yeah.
jnthn I like it, but it's certainly different. 14:05
JimmyZ_ little is ok
jnthn A good mapo tofu doesn't need more than a little :P
JimmyZ_ little spicy I meanšŸ˜Š
jnthn Oh man. It's touching 40C here today. That's nuts. 14:10
brrt :-o 14:12
it's only 25C here
jnthn Yeah, it'll be more like that tomorrow. 14:13
timotimo we'll be almost reaching 35 again today 14:15
actually, that peak is right around now
brrt didn't we discuss a few weeks ago how prague (assuming that's where you are) didn't get that hot
timotimo tonight there'll be some rain, which is nice
jnthn brrt: Yes; this is somewhat unusual from the climate charts I've seen. 14:16
14:18 lizmat joined
dalek arVM: 499d4c2 | timotimo++ | / (12 files):
add special support for nativecallinvoke to profiler
 14:31
arVM: b0e6608 | timotimo++ | src/profiler/profile.c:
fix output of profiler wrt. native function names
arVM: 08fe286 | timotimo++ | / (13 files):
Merge remote-tracking branch 'origin/profile_native_calls'

This gives us entries for functions called inside native libraries for the profiler and lets us more accurately measure the overhead NativeCall has.
timotimo i wonder why Ops.p6 wasn't checked in at all so far 15:09
was that on purpose?
15:20 JimmyZ_ joined 15:58 rudi_s joined 16:02 Ven joined 16:42 lizmat joined 17:30 lizmat joined 17:48 lizmat joined 18:13 lizmat joined 18:30 lizmat joined 18:40 brrt joined
brrt ugh, i almost understood how to implement tiling today 18:52
i've forgot again
had.. something something to do with state transfers during inorder traversal 18:56
18:58 colomon joined
brrt and state resolution during postorder traversal 19:00
19:11 colomon joined 19:12 colomon joined
brrt oh, i see 19:38
bbiab 19:44
19:56 brrt joined
jnthn For anyone curious about the fate of some of the 200g of chillies mentioned earlier today - they went into making a very satisfying vegetable curry :) 19:59
brrt hmmm, sounds nice
jnthn It was, depite me misreading the recipe and doing tablespoons instead of teaspoons of a bunch of the spices. :) 20:00
brrt lol
maybe the teaspoons were too conservative
jnthn Yeah, for my tastes they certainly were.
I'd not really tone it down much at all if I was making it just for me again. 20:01
Soon I'll be cooking for my wife also, though, and then I'll probably have to follow the recipe. :)
(Her tolerance is a good bit lower than mine....so far ;))
While I'd love to hack on stuff here, I probably should try and get the $dayjob course exercises off my plate... 20:03
Or further off the plate... 20:04
brrt :-) 20:05
btw, i finally got it
jnthn The tiling thing?
brrt had to spend some time in the library, but, yes
you'll like to hear that i'll have to write another preprocessor :-)
fortunately, i can probably reuse the sexpr parser 20:06
jnthn What is it with compiler writers and writing compilers... :P
brrt it's a habit 20:07
just can't stop :-) 20:12
jnthn :-)
20:15 vendethiel joined 20:31 colomon joined 20:43 colomon joined 20:50 colomon joined 21:18 lizmat joined 21:31 lizmat joined 21:36 lizmat joined 21:43 Peter_R joined 21:56 colomon joined 22:01 vendethiel joined
timotimo wow, more preprocessors %) 22:27
with new source data, as well?
22:42 TEttinger joined 23:47 dalek joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!