01:56 lee_ joined, lizmat joined, rurban joined, moritz joined, brother joined, bcode joined, colomon_ joined, _sri joined, [Coke] joined, synopsebot joined, ggoebel111118 joined, woolfy1 joined, dalek joined, cognominal joined, jnap joined, itz__ joined 01:58 ashleydev joined, timotimo joined, tokuhirom joined, harrow joined, cxreg joined, camelia joined, japhb joined, flussence joined, TimToady joined, japhb_ joined 02:06 BinGOs joined, masak_grr joined, diakopter joined, nwc10 joined, krunen joined, vendethiel joined, xiaomiao joined, jnthn joined, hoelzro joined, FROGGS joined 02:08 ingy joined, sergot joined, betterworld joined, retupmoca joined, lue joined 02:20 ChanServ joined 02:48 avar joined 06:42 nebuchadnezzar joined
sergot o/ 06:47
07:25 zakharyas joined 07:52 teodozjan joined 08:13 brrt joined
brrt o/ #moarvm 08:13
nwc10 \o 08:14
brrt jnthn++ for jit windows build fixes
nwc10 brrt: I tried to build the JIT with ASAN. The first error is in NQP: paste.scsys.co.uk/408001 08:15
2 byte read beyond a 2 byte allocation
brrt that's weird
huh, that seems to be logging error 08:16
the next one is in inline, it seems 08:17
or not, i should ask jnthn about the lexical types array 08:18
oh, i see what's wrong
dalek arVM/moar-jit: ca71858 | (Bart Wiegmans)++ | src/jit/graph.c:
Add takeclosure
 08:25
08:45 teodozjan joined
brrt nwc10++ for running with asan :-) 08:49
it looks very much like an off-by-one 08:50
and.. either it comes from me reading the wrong value for the idx or it comes from inline giving the wrong index or allocating a word too small 09:02
i'm going to hope and try and see if it is the first :-)
09:28 brrt joined
brrt \o #moarvm 09:28
jnthn heh, takeclosure was as easy as hoped :) 09:37
brrt yes 09:51
my spidey sense is suspicious of a potential bug wrt inlining 09:52
consider the following frames: A -> B -> C -> D
inliner inlines C -> D to C'
C' now refers to lexicals in A (2 out) 09:53
inliner then inlines (at a later time) A -> B
to A'
so C' will refer to ? <- A' <- C'
or must inlining always make leaves? 09:58
leafs
also, i thought that it maybe would be better to stash the current frame (upon entry) in the 4th non-volatile register rather than the in-args buffer 10:05
because getting the current frame is a much more frequent operation than getting reading input args
and this should simplify many things
(much code, i mean)
jnthn The inliner simply refuses to inline anything with free lexicals. 10:08
So you won't inline something that refers to a 2-out thing 10:09
dalek arVM/moar-jit: fe014aa | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
Try to fix nwc10++ ASAN barf

When an inlined frame refers to the outer frame, we should still get the lexical types from the outer frame (of course :-)). Note that the actual code path seems not to have been tested.		 10:10
brrt ok, great
we may fix that one day
but not today
:-)
jnthn yeah, that's a hard one :) 10:11
brrt i'll be riding train the next few hours, and won't have my computer with me, so i'll likely be offline for most of the weekend 10:12
nwc10 brrt: your fix has got past that point
brrt \o/
jnthn brrt: OK. Have a nice weekend. 10:15
nwc10 brrt: if you hang on about 60 seconds I can tell you waht the NQP tests did
All tests successful. 10:16
brrt \o/
:-D
nwc10 jnthn: NQP tests don't run in parallel. Somewhere I have a patch to fix that
brrt thanks nwc10++
nwc10 so, obviously, run aware before Rakudo blows up...
jnthn Much safer than running unaware... 10:17
nwc10 OK, we're into stage parse 10:18
yes, naughty fingrs
brrt nb 10:19
i expect a getlex for an object to blow up one day or other
with sigtrap
why? i put a breakpoint instruction in the auto-viv code
somehow it hasn't been executed yet 10:20
you all have a nice weekend as well :-)
(and i promise i'll backlog :-))
10:20 brrt left
jnthn o/ 10:24
nwc10 got past setting
got past sanity tests, into spectests
This is MoarVM version 2014.06-158-gfe014aa 10:25
I did check. I am surprised.
timotimo check what? surprised at what? 10:27
nwc10 that I am running a JIT-enabled MoarVM built with ASAN, and it is still going
jnthn You did build with --enable-jit? :) Though I think you must have, otherwise you'd never have seen the other error in the JIT. :)
nwc10 I'm pretty sure I'm building using the same command from shell history as last time 10:28
timotimo oh, neato
is it too soon to be asking for performance comparisons? 10:29
nwc10 I'm not the right person to ask for that even when it is.
timotimo jnthn: when you said you'd like to add a "did invoke?" to "may invoke" opcodes like decont and smart_*, would that turn into logging and then a guard?
also, the other day i wondered if jitting will enable branch prediction to make a much bigger difference in execution times 10:32
jnthn timotimo: No, don't think that maeks sense.
Yes, JITting should help the branch predictor a lot.
timotimo if a branching instruction is in the interpreter loop, it'd have the same "branch predictor slot" for every single occurence of that opcode 10:33
as opposed to one slot per occurence after jitting
that's pretty cool
oh, whether or not decont will invoke depends entirely on a container spec?
jnthn Right 10:34
timotimo like a boolification_spec, and i guess also numification_spec?
jnthn I suspect we'll be able to have spesh turn some deconts into cheap things, though.
timotimo i don't recall anything about a stringification spec
jnthn There isn't a spec for numification/stringification
timotimo OK
jnthn That's just case analysis in the op
nwc10 t/spec/S03-metaops/hyper.rakudo.moar hits 10:35
t/spec/S03-metaops/hyper.rakudo.moar hits trace/breakpoint trap
t/spec/S17-supply/classify.t t/spec/S17-supply/categorize.t are in their current usual state of sin 10:36
t/spec/S32-io/IO-Socket-Async.t fails randomly
lizmat nwc10: are you talking about categorize that I broke yesterday, or something else ? 10:38
nwc10 I don't know. 10:47
someone did something? as they pass now 11:08
(I updated stuff and reran)
lizmat ok, then the S17-supply tests failing were my fault for removing the paused functionality from Supply.new 11:11
11:19 teodozjan_ joined
jnthn On supplies, RxJS has got github.com/Reactive-Extensions/RxJ...clusive.js which is like migrate but different :) Wonder if we might want that one in our collection of supply-of-supply handlers too :) 11:21
nwc10 jnthn: if you really want to go ASAN squeaky clean, there's still one barf left, with the fixed size allocator disabled: paste.scsys.co.uk/408019 11:48
jnthn nwc10: Yeah, aware of that one; didn't get to the bottom of it yet. 11:49
12:14 jnap joined 12:18 cognominal joined
timotimo ah, actually we have a fetch_never_invokes flag that we can use 12:38
jnthn timotimo: I think we hang a spesh function off the spec. 12:40
timotimo do we already have an op that's basically "set the target object register to this object's position + a pointer? 12:41
jnthn Actually for a Scalar it's just a P6opaque with an attribute.
timotimo in that case we don't even need a special instruction yet
jnthn So it's just going to spesh like an attribute access does.
timotimo aye, i just found vm/moar/.../container.c
that'd be perfect
do you see any stumbling blocks i should be aware of?
jnthn For fetch? No, not really. 12:42
timotimo otherwise i could probably get to it right now
do we ever do store_unchecked on containers yet?
it says in the corresponding comment that an optimizer could emit that if it knows stuff
jnthn Yeah, we do 12:46
In parameter handling
timotimo ah, nice. 12:47
the signature for the spesh function for container specs ... should it be the same as for repr ops? as in, should it take an STable as second argument? 12:48
jnthn Sounds sane
timotimo ah, REPR_data might contain the offset for some kind of container "in the future" 12:49
garden work & 12:52
teodozjan_ hi again, what does mean: Unhandled exception: ctxlexpad needs an MVMContext? 12:58
jnthn Means something tried to use the ctxlexpad op (which is for introspecting a lexpad) and failed for some reason 13:02
timotimo jnthn: the "deconted_type" is what is *inside* the container, while the "type" is the type of the container (i.E. the RakudoScalar that has the Container Spec attached to it), right? 13:09
jnthn Rajt
timotimo and i should only try to optimize the decont into a sp_p6oget_o if it's also FACT_CONCRETE? 13:10
jnthn yes 13:11
timotimo i was about to joyfully proclaim that "nqp still builds!", but i remembered nqp doesn't have Rakudo_Scalar and as such, it'd be very strange if the spesh for decont would break anything 13:18
jnthn :P 13:19
timotimo oh well, a segfault 13:27
wrong order of function pointers 13:34
jnthn: with my opt, only io-socket-async seems to fail :D 13:48
jnthn: how can i construct a bit of example code that ought to trigger my opt in spesh? 13:55
14:02 klaas-janstol joined 14:06 btyler joined
timotimo huh. why would SPESH_FACT_KNOWN_TYPE be set, but facts->type be 0x0? 14:34
oh yikes, bus error?! 14:37
and the stack trace i get looks b0rked 14:39
Spesh: unknown operand type 0 in codegen (op CJK COMPATIBILITY IDEOGRAPH-2F816) - wait what 14:40
jnthn timotimo: Well, any decont should... 14:42
timotimo: Look at how infix:<+> gets speshed if you call it with $a + $b for example 14:43
timotimo it should also be a case where decont doesn't simply turn into set 14:44
oh, but in this case it can't
jnthn right
'cus it actually needs to decont 14:45
timotimo it gets run a few times during setting compilation now that i check for FACT_FOO | FACT_BAR rather than FACT_FOO & FACT_BAR 14:46
i don't know what i did wrong :S 14:50
i suppose i'll push a diff 14:52
dalek arVM/spesh_decont_contspec: e9f379e | (Timo Paulssen)++ | src/ (3 files):
give ContainerSpec a spesh function, use it for decont.
 14:54
timotimo this branch exists in rakudo as well 14:55
jnthn: if you could have a look at what might be causing memory corruption or stack destruction or any other kind of mayhem ...
16:25 FROGGS joined 17:35 btyler_ joined 17:36 d4l3k_ joined
jnthn timotimo: Does that patch alone change anything? Or does it pair with a Rakudo one? 17:38
oh, duh, found it
(the Rakudo commit) 17:39
offsetof( Rakudo_Scalar, value );
It needs to be the offset of the data portion of the object
So, minus the header
17:51 woolfy joined
timotimo that'd explain something 18:04
jnthn: after subtracting offsetof( MVMObjectStooge, data ), it's giving me an "invalid utf8" error in stage parse :( 18:14
must be looking at bogus memory 18:16
18:18 brrt joined
brrt nwc10: ping 18:21
i noticed you caught a sigtrap
awesome
that is in tests, right? 18:22
wrt to 'invokish' ops 18:23
i have a plan, with the following reasons
timotimo brrt: i'm trying to turn deconts on Rakudo_Scalar into sp_p6oget_o so that the jit may have less trouble with rakudo cod! :)
brrt yes, i've seen that too, awesome :-)
timotimo except it's pretty b0rked 18:24
brrt timotimo++
well, you'll have to start somewhere
timotimo right; but i don't know where to continue looking; i can't get it to dump core any more ...
maybe you can have a look?
nwc10 brrt: yes, that's in one test, and it's the only difference in behaviour from master 18:25
brrt the sigtrap was expected, actually\ 18:26
i.e. i was hoping for /something/ to trigger it
nwc10 yes, IIRC you'd said it was the place holder for something
brrt you can (i'm not on a usable system right now) try if removing the following line makes it work: 18:27
github.com/MoarVM/MoarVM/blob/moar....dasc#L389
because if it works, that means the vivification also works :-) 18:28
timotimo, not on a usable (bulding) computer right now, sorry 18:29
timotimo fair enough
i thought maybe a look at the diff would be enlightening 18:30
brrt i'll do that, then :-)
timotimo i don't need to "allocate" a third operand to hold information on the offset, right?
in other cases, it'd turn the string literal into an offset i16, but in the case of decont -> sp_p6oget_o it used to have only 2 operands 18:31
brrt brb
jnthn o/ brrt 18:36
[Coke] everytime someone says brrt now I imagine someone is getting shocked. 18:38
brrt back 18:39
why do you imagine that? :-o
[Coke] onomatopoeia 18:40
japhb I could see that if his alias was bzzzt
brrt aha, ok :-) 18:41
i've heard other explanations, even
jnthn timotimo: Wait...do you allocate space for the extra operand? 18:45
ins->operands[2].lit_i16 = offsetof( Rakudo_Scalar, value ); 18:46
decont is only 2 operands big, so that's going to scribble on random memory when you assign to the [2]
brrt concurs 18:47
decont is dst, src iirc
jnthn There are other opts that allocate bigger spesh operand space to look at for inspiration 18:49
(uses MVM_spesh_alloc)
brrt wouldn't a sequence of spesh_alloc, memcpy(), assign work? 18:50
jnthn Yes
Though I may just write two assignments instead of messing with memcpy... :)
brrt memcpy ftw :-)) 18:51
jnthn I dunno if it's the same for you, but for me when I'm reading code and hit a memcpy (or malloc, or calloc, or memset) I find I'm looking carefully to see if it's doing the size calc correctly. 18:53
Whereas assignments I can read and be comfortable with immediately.
For any more than 2 things then yeah, memcpy for sure :)
brrt anyway, before this; my plan (for invokish ops); a): stash the cur_frame into a nonvolatile register upon entry, b): after returning from a invokish op, compare our 'old' frame* with the tc->cur_frame
well, i agree with that
strcpy is more complex even
if any invokish ops actually invoked, then the old frame* and the cur_frame* should be different 18:54
comparing them is a single instruction for the jit, and calling out is also pretty cheap
jnthn OK 18:55
falling out?
or did you really mean calling? :)
brrt yeah, that's what i mean
:-)
rurban in a register? shouldn't that be better on the stack?
brrt some registers are non-volatile (actually, about half of them are) 18:56
rurban you'll never who globbers that register (any sunfunction)
jnthn Were you going to keep cur_frame around for other reasons anyway?
brrt variables that you use really often are best put in one of these
rurban subfunction or external fun
brrt rurban - amd x64 ABI (or windows x64 ABI) specifies it quite clearly, fortunately :-) 18:57
jnthn non-volatile = callee saves, no?
brrt yes
rurban I'm sceptical 18:58
brrt very bluntly, callee-save registers are preferred for variables that remain live throughout multiple basic blocks, and caller-saved registers for within basic blocks
rurban ok, if it works 18:59
brrt i understand :-)
jnthn Well, if it's what the ABI specs... :P
brrt (your scepticism, i mean)
rurban I was more used to i386 those times, and then we put everything on the stack
brrt but i first noticed the pressence of these registers (and how many of them there are) when i accidently clobbered one 19:00
msdn.microsoft.com/en-us/library/9z1stfyw.aspx is a good resource (for win64)
rurban rbi is typically used for that, right? if it's free
brrt you mean rdi? or rsi? 19:01
rdi and rsi are somewhat annoying as windows makes them callee-save and posix makes them caller-save 19:02
i could pretend they are caller-save on windows, too, simply by optionally saving-and-restoring them
rbx is also callee-save, and i used it for the pointer to the 'moar registers'
rurban I meant rbp with -fomit-frame-pointer 19:05
brrt oh, i see :-)
rurban for -O3, this would be free
brrt you can omit the frame base pointer? oh
]i use it in the JIT, though 19:06
rurban yes, counter everything from rsp only
count
brrt i see
if you know always exactly how large the stack frame will be, you can do that
interesting
rurban In my potion jit have to keep rbp, because coros need it. Other than that, I could use rbp for something better 19:07
brrt jnthn - i take the frame pointer many times in the code, and having it in a register makes such ops cheaper 19:08
rurban the main problem is fast stack switching with coros/threads
brrt hmm, why? 19:09
jnthn brrt: Yes, I noticed tc->cur_frame equivalent showing up a few times :)
rurban see e.g. github.com/perl11/potion/blob/mast...e/callcc.c I need rsp and rbp there 19:10
brrt right :-) so these can be eliminated then 19:12
that code makes me ponder the relative benefits of AT&T vs Intel syntax for ASM :-) 19:13
rurban I could use a faster stack layout -fomit-frame-pointer but would need a seperate yield (stack filler) then 19:14
japhb
.oO( "You should always use ... Whatever I Learned First! Whatever I Learned First FTW!" )
brrt i actually learned AT&T syntax first, but now i find Intel syntax slightly easier to read 19:15
rurban So I just compile this .o (using %rbp) with -fno-omit-frame-pointer to be on the safe side. 19:16
japhb I've learned a lot of assembly languages, and x86 Intel syntax is probably the only one I can still do without having to think hard. 19:18
brrt :-)
brrt off 19:19
jnthn o/
nwc10 brrt: wait a mo?
./perl6-m t/spec/S03-metaops/hyper.rakudo.moar 19:20
without the int 3
[is running...]
eh? still hits Trace/breakpoint trap
confused. Please don't let me detain you further, if you want to go 19:21
brrt hmmm...
do you happen to have lua installed?
:-)
brrt looks for other sources of breakpoints 19:22
nwc10 found one in src/jit/emit_posix_x64.
brrt well, that explains 19:23
nwc10 Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
brrt you probably don't have lua and lua bitop installed
lua -e 'require("bit")' says?
nwc10 lua: (command line):1: module 'bit' not found:
plus a backtrace
so, you're correct
brrt bitop.luajit.org/ :-) 19:24
nwc10 OK
I don't think I can get that fixed up in a hurry
I'm not root on the fast x86_64 machine I'm testing on 19:25
and I'm too tired (And supposed to be packing) to figure out how to do it locally and ship the fixes up
brrt very well, it can wait i guess :-) 19:26
it's been a long day
thanks for your help, anyway
jnthn Long train journey?
brrt 3 hours 44 minutes
long, for the netherlands anyway
nwc10 brrt: no problem. (a) What you're is very impressive (b) I think you deserve a weekend off
what you're doing 19:27
see, I'm too tired to type correctly
timotimo jnthn: should i free the previous MVMSpeshOperands? i think the spesh memory blocks are all freed en bloque, so i don't have to free anything myself
jnthn Yeah, I'm used to 4-hour-and-a-bit trips to Stockholm, so 3:44 doesn't feel too bad.
timotimo: No, you don't have to free anything.
brrt thanks, see you after the weekend :-) 19:28
jnthn nice weekend o/
timotimo well, now that i properly do the thing with the memory it doesn't crash any more
brrt you too o/
timotimo so that's a good start
brrt: enjoy your weekend!
dalek arVM/spesh_decont_contspec: 0fb638b | (Timo Paulssen)++ | src/ (2 files):
+ comment, - debug print.
 19:32
timotimo spectests are clean, yay 19:42
dalek arVM: e9f379e | (Timo Paulssen)++ | src/ (3 files):
give ContainerSpec a spesh function, use it for decont.
 19:45
arVM: 0fb638b | (Timo Paulssen)++ | src/ (2 files):
+ comment, - debug print.
jnthn I think this weekend I'm going to finally tackle Moar's strings. 20:14
Because the string-related benchmarks are just awful.
nwc10 is your weekend 2 days or 3? 20:15
I'm trying to assess how crazy you are.
jnthn 2 20:16
nwc10 OK. very crazy :-)
good luck
FROGGS ohh :o) 20:17
jnthn oh timo? 20:18
src\spesh\optimize.c(262) : warning C4090: 'initializing' : different 'const' qualifiers
src\spesh\optimize.c(267) : error C2275: 'MVMSpeshFacts' : illegal use of this type as an expression
FROGGS I think it is with beetlejuice, you have to say it several times to summon him 20:23
jnthn m: say 'timo' x 1000
camelia rakudo-moar 87dcd1: OUTPUT«timotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimo…»
dalek arVM: 645e0ef | jnthn++ | src/spesh/optimize.c:
Fix MSVC build.
 20:24
japhb jnthn, do you want a perl6-bench commitbit so you can add more benchmarks yourself? 20:25
jnthn japhb: Sure, can do
japhb OK, hold on ...
Done. 20:26
jnthn thanks.
japhb np
(Shoulda done it sooner, honestly, but for some reason I got the impression you were less interested before.) 20:27
Anyone else I should add while I'm here? timo already has one. 20:28
nwc10 All tests successful.
(ASAN, Linux)
japhb nwc10, do you use perl6-bench?
nwc10 no
japhb OK, fair enough. 20:29
jnthn japhb: Well, others were happily producing graphs for me taht told me enough. But I wanted to look at how far we improved over the last year.
And that needed a bit more fiddling. Especially to do it on Windows. :)
japhb FWIW, I'm currently fiddling with a small `analyze` refactor to make it less annoying to add history plots (history text table already works, history html table is coming soon, but it seems like everyone -- me included -- wants arewefastyet style plots) 20:30
One of the odd things I noticed in doing a history table that included perl5 v5.{18.0,18.1,18.2,20.0} is that perl5 seems to have slowed down a few percent in the last year+. Makes me curious as to why, or if it was just an artifact of something going on with my testing box at the time 20:32
20:34 cognominal joined
jnthn japhb: I wasn't really expecting the 5 vs 6 perf thing to be attacked from both directions, but... :P 20:46
timotimo jnthn: sorry for making msvc unhappy ... again 20:47
jnthn yes, it was rather upset about the Rakudo patch too :P 20:48
FROGGS can't we add some C89 rules to gcc as well?
timotimo -fpedantic?
FROGGS I-f no idea... 20:49
jnthn No -fing clue... 20:50
dalek arVM: 1bd2d3a | jnthn++ | / (6 files):
Make various spesh things available publicly.

Since extops and container specs may participate in spesh also, and so need some graph manipulation APIs.		 20:53
[Coke] many of clang warnings seem to be of const or unsigned warnings. 20:56
timotimo was i using non-public things in the rakudo patch? :o 20:59
jnthn yes :) 21:00
timotimo d'oh 21:01
gcc didn't care at all
japhb FROGGS, Are you referring to --std=c89 ? 21:06
FROGGS japhb: I think so, yes
21:28 dalek joined 22:30 jnap 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!