00:54 jnap1 joined, odc joined 01:11 odc joined 01:17 FROGGS_ joined 02:25 xiaomiao joined 03:25 vendethiel joined 03:35 btyler joined 05:38 vendethiel joined 05:53 woolfy joined 07:09 FROGGS joined, zakharyas joined 07:57 brrt joined
brrt hi #moarvm :-) 07:58
FROGGS hi brrt
brrt hi FROGGS 08:07
i figured out what i did wrong wrt to string indexing 08:11
when in doubt, draw pointer diagrams :-) 08:18
hmm..... i'm wondering if a generalized 'access node' is another case of overzealous generalisation from my part 08:21
kind of looks like the latter 08:24
oh, .tell jnthn that i can get (from dynasm) all the offsets of the basic blocks 08:30
so that should help dealing with invocations 08:31
i also wonder if it is worth it to keep CU arround 08:41
long story short, i may need to up the complexity of the jit graph 08:42
(i still hope to extend the complexity of the jit graph to one day do full codegen) 08:43
jnthn morning o/ 09:21
Turns out flight + cold = earache :/
nwc10 but your flight flew, and at roughly the right time?
jnthn Yeah, though it coulda been an hour late and I'd still make my connection.
But it was early. 09:22
nwc10 good
jnthn So, even more time here in Stockholm airport.
nwc10 ours was 2 hours late yesterday. But we were happy that it flew at all
jnthn ugh
but yeah.
nwc10 yes, but the ETA on info kept changing, and one round of "please wait" lasted for 15 minutes on the departure board
ultimately problem seemed to be that it's all very well having a plane, but you need a crew with enough hours remaining to fly it 09:23
jnthn ah, yes.
nwc10 pleasing discovery - at one point when I looked at the departure board, of the flights, 18 were easyJet, 16 were norwegian.com
I hope Ryanair and easyJet are worried. 09:24
jnthn Norwegian are really quite good compared to those two. :)
nwc10 the vikings are coming.
I've not yet had a chance to fly with them. I'm hoping that their route network expands in directions that are useful to me
jnthn As a temporary viking, I find their current route network quite useful :) 09:25
brrt morning jnthn 09:27
jnthn o/ brrt 09:30
What jiteth we today? :)
brrt wval
nwc10 jnthn: because I was on the wrong end of massive amounts of bufferbloat and other stupid, I left t/spec/S17-promise/allof.t
brrt or, at least, we jitteth that this morning :-)
nwc10 running under valgrind, in a loop, until it hit a problem
24 hours later it still has not :-( 09:31
[OK, there's a sleep 30 in the loop too]
jnthn Aww 09:33
But it sometimes fails with ASAN?
Curious...
dalek arVM/moar-jit: 11899f4 | (Bart Wiegmans)++ | src/jit/emit_x64.dasc:
Lookup strings at runtime if necessary
 09:34
arVM/moar-jit: a12a375 | (Bart Wiegmans)++ | / (8 files):
Added support for wval, fix bug in sp_p6oget_*
brrt i was busy adding support for a 'deep access' then it hit me that many of these are condtiional
it also occurs to me that i might want different interpreter variables into scope at different times 09:35
jnthn + if (!(obj->header.flags & MVM_CF_SECOND_GEN) || 1)
um... :)
brrt i've removed that 09:37
(In the next commit :-))
i had to hit that path to test it, no? :-)
jnthn yeah, just saw that :)
jnthn suspects the write barrier might want factoring out, fwiw 09:39
(as in, maybe use a dynasm macro for it)
Also that wval can have the same gen2 trick done as the string. :) 09:40
brrt++ # progress
brrt oh, thats true (the wval thing) 09:42
i'm not sure how to insert code into a dynasm macro 09:43
nwc10 jnthn: seemed to be 100% reliable SEGV with ASAN
jnthn brrt: C code?
I think || 09:44
brrt dynasm code, i.e. the pushes of TMP1 and TMP2
jnthn no, I meant a dynasm macro
Not a C one
brrt basically, the push TMP1, pop TMP2; is only necessary in the context where TMP1, TMP2 mean anything 09:45
so ideally i'd 'insert that' into the macro
but i don't know if that is possible
jnthn ah, I see...
Yeah, that's trickier.
brrt another option is to simple create a macro check_wb that returns a 0 or 1 to a specified register 09:52
and then do the jump part in between 09:53
(or perhaps directly to flags)
and.. i really should find some way to number-or-name jit code segments 09:54
because i'm already creating many different segments and i've only got the chance to inspect the latest
btw, am i wrong in supposing that getwhere is (on asm level) just set 09:55
i.e. copying a pointer to an integer field, the CPU doesn't make a difference :-) 09:56
jnthn Sounds reasonable :)
Right
timotimo brrt: are you already targeting any specific piece of nqp code? or just following your instincts? 09:57
brrt timotimo, in fact i'm running foo.nqp, and looking at the log where it bails 09:58
jnthn helpfully suggested to make a script that counts the bailout lines
timotimo aye
brrt and i will, it's just that working on the asm level of specific ops is rather addicting 09:59
timotimo :)
so when you're running foo.nqp, you also get lots of attempts to jit stuff from inside the nqp compiler itself? :)
brrt and eqaddr is identical to eq_i afaik 10:00
yes
timotimo when you get the data, i'd be interested to see it :)
brrt on the bailout points? 10:01
timotimo yes
brrt ok, if there is n>1 people of interest in it, it becomes higher priority :-)
timotimo it should also tell us, what callsites/methods/subs it's looking to jit, right? 10:02
brrt it works on the op level
timotimo then it could also say "bailed out at instruction N of M" so we can have something like a percentage of implementation
brrt and i haven't figured out how to translate between speshgraph and high-level-subs correctly yet
timotimo hold on, i'll have a look at that
brrt that... would be ideal, yes
timotimo append_str(tc, &ds, g->sf->body.name);
append_str(tc, &ds, g->sf->body.cuuid); 10:03
these pieces would be what you'd want to output
dalek arVM/osr: 154a2dc | jonathan++ | / (8 files):
Add osrpoint opcode for hot loop detection.
 10:10
arVM/osr: 5bbad46 | jonathan++ | / (5 files):
Trigger OSR; just stub the procedure for now.
jnthn bbl, or maybe at home...depends how long security etc takes. 10:11
&
timotimo good luck, jnthn :)
10:23 FROGGS joined 10:26 carlin joined
brrt ok, that will help 10:47
timotimo++ :-)
dalek arVM/osr: 42d571b | jonathan++ | src/spesh/osr.c:
Start sketching out OSR handling.
 11:17
12:20 woolfy joined, lizmat joined 12:38 brrt joined 12:48 jnap joined 13:14 LLamaRider joined
brrt hmm, i think getlex together with MVM_frame_vivify_lexical are being weird 13:27
that is to say, being weird wrt to inlining 13:35
timotimo we can already jit getlex? 13:40
brrt no, not yet 13:41
i'm looking at getlex right now
and i'm seeing weird-ish behavior in vivication
i.e.
timotimo hm, ok 13:42
getlex will probably make a whole class of things jitable :)
brrt getlex checks the spesh_cands' lexical_types array for finding out if the lexical ought to be an object
brrt thinks invocation is really the 'tricky bit' :-)
timotimo we'll be happiest with inlined things rather than invoked things, though :) 13:43
brrt true enough
but at any rate, it only checks that array if it exists, otherwise it uses the static frames lexical type array
anyway, i thought i had the luminous idea of moving that check up to frame invocation time, i.e. add a field 'effective lexical types' 13:45
however.... MVM_frame_vivify_lexical only ever looks at the static frame lexical type array
(is this making any sense?)
so why bother looking at the spesh cand's lexical type array anyway, if it isn't used? 13:46
is this a speshbug?
what is more
timotimo i didn't look deeply at lexicals at all yet
brrt hmm
can i create a 'not an issue but it seems questionable' thing at github?] 13:47
or better mail jnthn directly
timotimo issues are for everything, really
brrt ok, i'll put it up there then
:-)
thanks
timotimo the only occasion where i looked at lexicals was when i was trying to build the "turn lexicals into locals" optimization 13:48
i succeeded for nqp (after lots of help from jnthn) and ended up having to let jnthn do/finish it for rakudo itself
brrt if we could do that for all possible code i'd be so happy :-) 13:50
timotimo impossible, sadly 13:51
but we can be good at lexicals, too
13:52 btyler joined
brrt true 13:59
but we can be better yet
jnthn home 14:01
brrt: Feel free to create an issue ont he questionable code; sounds like something I should look at
nwc10 jnthn: did past jnthn remember future jnthn, and re-prime the beer fridge?
brrt is doing so
:-)
jnthn nwc10: I *think* so... 14:02
brrt jnthn - if you could just look-and-advice github.com/MoarVM/MoarVM/issues/107
i think i know how to fix it (if you agree it's weird / broken)
jnthn nwc10: Confirmed. The fridge can supply a choice of 4 different styles of beer this evening. :) 14:10
However, I'm full of cold, so should probably go easy on it...
Can't believe I went all winter/spring without really having a cold, then get one in summer. :/ 14:11
brrt wishes jnthn speedy recovery :-) 14:24
timotimo too
brrt also, don't be too surprised. there are over 90 different cold viruses, and infection with any one of them has more to do with exposure to them than with heat or cold 14:25
i.e. regular travel is a sure way to acquire a new one :-)
jnthn Yeah 14:26
jnthn hopes next week's potential travel doesn't actually happen
brrt where does your potential travel go to? 14:29
jnthn Norway 14:36
(Which is a nice place to go, just wouldn't mind being at home more than 2 days. :)) 14:38
brrt: I don't immediately see a problem in MVM_frame_vivify_lexical 14:40
brrt: It does this:
if (idx < f->static_info->body.num_lexicals) {
Which sees if it's a non-inlined lexical
brrt uhuh
ok, what's the meaning of the spesh_cand->lexical_type array then :-) 14:41
jnthn If it's an inlined one, then the "else if (f->spesh_cand) {" comes into play
Well, we could find the *flags* from the spesh_cand->lexical_type array.
uh, wait
We can't
We're not after the typehere
*type
We already know it's an object
We're after the static environment flags 14:42
flags = f->static_info->body.static_env_flags;
static_env = f->static_info->body.static_env;
The flags indicate if we vivify an object and if it's a state var.
The static_env provides the thing to vivify from.
brrt ok, thats right
so this is all ok? :_) 14:43
:-)
jnthn We could in theory compute merged flags and static env.
But I didn't do that in the end
One thing that is worth noting is that the flags and static env never actually change
Meaning from a JIT point of view you could actually resolve all of this statically.
brrt oh... yes 14:44
hmmmm
brrt makes a note of that
jnthn Though arguably you could ask me to make a spesh op and do the identification of this opt at that point :)
brrt wait, i'm looking at how the lexical type array is constructed 14:45
and more importantly
if i have access to that at jit-level
because that'd mean moving the check to jit level and removing it from the emitted level 14:46
jnthn Yes, you can get at it. 14:48
brrt i do indeed
ok, great 14:49
that simplifies things
oh, did you know that (using dynasm / asm) you can use a interupt for setting a breakpoint? 14:53
jnthn No? :) 14:54
Sounds useful
brrt it is useful 14:55
i didn't know either
i used to add a idiv r9 or something to trigger a floating-point exception 14:56
(which distinguishes it from a segfault)
but not anymore
what, a segfault that isn't in generated code 15:01
what is the world coming to
jnthn broken code-gen, apparently :P 15:02
brrt hmmm 15:03
is it usual for lexical_types to be 0
?
oh... wait
i see
ahum
wrong static frame 15:04
jnthn :) 15:05
brrt ok, no crash, but value isn't right either 15:11
15:28 woolfy left
hoelzro if MoarVM is crashing on some weird piece of code, is it easy to dump a human-readable version of the currently executing frame's bytecode to assist in debugging? 15:28
FROGGS hoelzro: moar --dump 15:29
hoelzro thanks FROGGS 15:30
FROGGS for that you perhaps want to 'cat /path/to/perl6-m' to get the --libpath flags etc
15:32 lizmat joined
hoelzro hmm 15:36
well, I can try and look at the output later (I have to ask early, because no one's here when I'm actually working on stuff =/), but here's the buggy code in case someone knows what's wrong right away:
gist.github.com/hoelzro/540f92e81823e5e89c8e 15:37
moritz hoelzro: [] is Array, not Array of Str 15:50
hoelzro hmm
I see
moritz (avoid typed arrays)
hoelzro tweaks and tries
huh 15:51
well, that solves that, I guess 15:52
thanks moritz
brrt getlex works again :-)
dalek arVM/moar-jit: 97ff5e0 | (Bart Wiegmans)++ | / (5 files):
Add getlex support. Object getlex isn't tested yet.
 16:03
timotimo and how hard is bindlex now? :) 16:04
brrt not hard at all
bindlex is much simpler
timotimo neato
brrt but i'm off for dinner
timotimo bon appetit
brrt bye!
17:00 lizmat joined
dalek arVM/moar-jit: 0e0ea79 | (Bart Wiegmans)++ | / (5 files):
Bindlex also works.
 17:02
17:26 carlin joined
timotimo i'm kinda sad we need OSR for almost all the benchmarks in the perl6-bench suite 17:27
and the bigger benchmarks are probably "too big" for the jit as of yet
18:02 FROGGS joined
FROGGS o/ 18:03
what was OSR again? 18:05
ahh, On-Stack-Replacement 18:06
stackoverflow.com/questions/9105505...eplacement 18:09
( this link is better stackoverflow.com/a/9105846 )
18:47 FROGGS joined, carlin joined, lizmat joined, btyler joined, jnap joined, vendethiel joined, xiaomiao joined, cognominal joined, colomon joined, woosley joined, oetiker joined, hoelzro joined, dalek joined, lue joined, jnthn joined, camelia joined, rurban_ joined, flussence joined, harrow joined, avar joined, japhb_ joined, tadzik joined, japhb joined, bcode joined, Util joined, ashleydev joined, krunen joined, daxim joined, betterworld joined, _sri joined, synopsebot joined, sergot joined, masak joined, cxreg joined, nwc10 joined, lee__ joined, brother joined, ingy joined, ChanServ joined, [Coke] joined, BinGOs joined, moritz joined 18:48 [Coke] joined 18:51 LLamaRid1r joined 18:58 donaldh joined 19:19 ggoebel111116 joined 19:23 nebuchadnezzar joined 20:05 brrt joined
brrt timotimo: ain't nuttin's too big for jit in due course 20:15
jnthn
.oO( must...not...make...your mom joke... )
 20:16
brrt lol 20:18
FROGGS hehe 20:20
that is where one can see that jnthn is damn young :o)
FROGGS .oO( When I was your age Pluto was a planet! )
brrt when i was my age pluto was a planet! 20:22
brrt is off again for a bit 20:23
dalek arVM/osr: e38be93 | jnthn++ | / (5 files):
Add sp_osrfinalize spesh op.

Used to handle logging runs through the loop, and will trigger the final optimization afterwards.		 20:39
arVM/osr: 76958c3 | jnthn++ | src/ (5 files):
Convey "are we doing OSR" deeper into spesh.
arVM/osr: c4d4ce6 | jnthn++ | src/spesh/log.c:
Handle osrpoint in spesh logging setup.

If we are doing OSR, turn it into sp_osrfinalize; otherwise, toss it.		 21:11
arVM/osr: af345ed | jnthn++ | src/ (6 files):
First pass at making OSR work.

Handles the basic cases, though doesn't always work out yet, and does not yet handle the inlining case.
jnthn Ugh...headache :/ 21:28
Well, enough for today.
japhb_ Feel better soon, jnthn! 21:33
jnthn Hopefully.
At least it's nothing serious.
japhb_ Definitely.
Do you have a second before sleep? 21:34
jnthn Sure
japhb_ Is there anything you'd like me to add or change about perl6-bench to help you with the MoarVM (or general Rakudo optimization) work?
I'm doing things that I *assume* are useful, but ... it would be nice to have a few of your top wishlist items on my list for when I get hack time. 21:35
jnthn At this point, I'd mostly like to see better benchmark coverage.
For example, I'm told Rat performance is sucky, but there's no benchmarks exercising it.
japhb_ What areas are most important?
Last hack day I was adding more minibenchmarks (the ones of 5-100 lines, rather than the micros, which are 1-4 lines) 21:36
OK, Rat, I assume more string stuff.
jnthn Also, while we've made a lot of progress on various of the benchmarks, forest fire is still horribly slow in Rakudo.
I guess it's not an easy thing, but any microbenchmarks that can be extracted from it that might explain why would be great.
japhb_ I've only got the one parsing example (JSON). Would you mind if I made one with your weather data code from your "What can you do now in Perl 6?" slides?
OK, I'll see what I can do for that. 21:37
jnthn Parsing could be good, yes. Another one is just some simple regex matching ones.
Also, some basic file I/O ones.
japhb_ By "simple regex matching ones" you mean stuff like non-matching substrings in long strings, near-matches, multiple matches, that sort of thing? 21:38
jnthn Well, and just simple "blahblahblah42blahblah" ~~ /\d+/ style things.
japhb_ Yeah, gotcha. 21:39
Any intuitions of things that might be especially both important and slow-prone? (My gut is to really test things like '(' ~ ')' and % ',' and such) 21:40
Can I use the weather data parser? 21:41
jnthn Well, backtracking is worth exercising a bit, for sure.
'cus grammars with rules/tokens don't really do that 21:42
And a lot of what's driven optimizing the grammar engine has been parsing grammars.
japhb_ Does spesh ever try to re-optimize after de-optimizing? Meaning, could a certain evil type pattern cause it to re-attempt spesh and then go back to unoptimized over and over? 21:43
OK, backtracking, got it.
jnthn It doesn't re-do the spesh, but it will use the optimized code again next time.
But deopt isn't especially costly.
japhb_ What about TypeA xx 20, TypeB xx 20, TypeC xx 20, etc.?
jnthn You may be able to find something that makes it be
It won't generate infinite specializations. 21:44
If it sees the thing is megamorphic it just gives up.
japhb_ OK, good. OOC, what is the "megamorphic" limit?
jnthn There's some places doing polyvariant stuff would be desirable...
At present: 21:45
#define MVM_SPESH_LIMIT 4
oops
/* The number of specializations we'll allow per static frame. */
Though that could easily want to be more like 8 21:46
That's for argument-based variation.
Inside each of those the logging stuff wants no variance over 4 samples.
Since those are the things that can lead to deopt 21:47
For something like infix:<+>(Int, Int) then the 4 can easily be swallowed up by (scalar->Int, scalar->Int), (Int, Int), (Scalar->Int, Int), (Int, Scalar->Int)... 21:48
But that's all we can get, I guess. :)
japhb_ Oh, interesting. Yes, I see that.
jnthn (It does optimize away a bunch of decontainerizations that are not needed.)
japhb_ Makes me wonder if a future optimization area for the user-programmer is "Avoid scalar containers that you don't actually need for writeability" 21:50
jnthn I'm hoping the lexical nature of variables will allow some of that to be done by the Perl 6 optimizer.
I also expect many Scalar containers will be excellent candidates for escape analysis. 21:51
japhb_ OK, thanks, jnthn! Sleep well .... 21:55
21:56 brrt joined
jnthn Thanks :-) 21:57
'night, all o/ 21:58
brrt gnight 22:05
japhb_ : i'm actually quite interested in the benchmark suite 22:36
that will be a great help in identifiying jit compilation blockers'
timotimo well, mostly the nqp benchmarks so far :) 22:37
brrt should up his tooling a bit 22:39
22:39 vendethiel- joined
brrt hmm 22:40
i think i'm going to try and do sp_guardconc - and with that, deopt - either tonight or tomorrow
deopt, iirc, should be relatively easy 22:41
22:52 lizmat joined 23:12 tadzik joined 23:16 brrt left 23:24 brrt 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!