Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-11

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

All times shown according to UTC.

Time Nick Message
01:56 lee_ joined #moarvm
01:56 lizmat joined #moarvm
01:56 rurban joined #moarvm
01:56 moritz joined #moarvm
01:56 brother joined #moarvm
01:56 bcode joined #moarvm
01:56 colomon_ joined #moarvm
01:56 _sri joined #moarvm
01:56 [Coke] joined #moarvm
01:56 synopsebot joined #moarvm
01:56 ggoebel111118 joined #moarvm
01:56 woolfy1 joined #moarvm
01:56 dalek joined #moarvm
01:56 cognominal joined #moarvm
01:56 jnap joined #moarvm
01:56 itz__ joined #moarvm
01:58 ashleydev joined #moarvm
01:58 timotimo joined #moarvm
01:58 tokuhirom joined #moarvm
01:58 harrow joined #moarvm
01:58 cxreg joined #moarvm
01:58 camelia joined #moarvm
01:58 japhb joined #moarvm
01:58 flussence joined #moarvm
01:58 TimToady joined #moarvm
01:58 japhb_ joined #moarvm
02:06 BinGOs joined #moarvm
02:06 masak_grr joined #moarvm
02:06 diakopter joined #moarvm
02:06 nwc10 joined #moarvm
02:06 krunen joined #moarvm
02:06 vendethiel joined #moarvm
02:06 xiaomiao joined #moarvm
02:06 jnthn joined #moarvm
02:06 hoelzro joined #moarvm
02:06 FROGGS joined #moarvm
02:08 ingy joined #moarvm
02:08 sergot joined #moarvm
02:08 betterworld joined #moarvm
02:08 retupmoca joined #moarvm
02:08 lue joined #moarvm
02:20 ChanServ joined #moarvm
02:48 avar joined #moarvm
02:48 avar joined #moarvm
06:42 nebuchadnezzar joined #moarvm
06:47 sergot o/
07:25 zakharyas joined #moarvm
07:52 teodozjan joined #moarvm
08:13 brrt joined #moarvm
08:13 brrt o/ #moarvm
08:14 nwc10 \o
08:14 brrt jnthn++ for jit windows build fixes
08:15 nwc10 brrt: I tried to build the JIT with ASAN. The first error is in NQP: http://paste.scsys.co.uk/408001
08:15 nwc10 2 byte read beyond a 2 byte allocation
08:15 brrt that's weird
08:16 brrt huh, that seems to be logging error
08:17 brrt the next one is in inline, it seems
08:18 brrt or not, i should ask jnthn about the lexical types array
08:18 brrt oh, i see what's wrong
08:25 dalek MoarVM/moar-jit: ca71858 | (Bart Wiegmans)++ | src/jit/graph.c:
08:25 dalek MoarVM/moar-jit: Add takeclosure
08:25 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/ca71858e59
08:45 teodozjan joined #moarvm
08:49 brrt nwc10++ for running with asan :-)
08:50 brrt it looks very much like an off-by-one
09:02 brrt 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 brrt i'm going to hope and try and see if it is the first :-)
09:28 brrt joined #moarvm
09:28 brrt \o #moarvm
09:37 jnthn heh, takeclosure was as easy as hoped :)
09:51 brrt yes
09:52 brrt my spidey sense is suspicious of a potential bug wrt inlining
09:52 brrt consider the following frames: A -> B -> C -> D
09:52 brrt inliner inlines C -> D to C'
09:53 brrt C' now refers to lexicals in A (2 out)
09:53 brrt inliner then inlines (at a later time) A -> B
09:53 brrt to A'
09:53 brrt so C' will refer to  ? <- A' <- C'
09:58 brrt or must inlining always make leaves?
09:58 brrt leafs
10:05 brrt 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 brrt because getting the current frame is a much more frequent operation than getting reading input args
10:05 brrt and this should simplify many things
10:05 brrt (much code, i mean)
10:08 jnthn The inliner simply refuses to inline anything with free lexicals.
10:09 jnthn So you won't inline something that refers to a 2-out thing
10:10 dalek MoarVM/moar-jit: fe014aa | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
10:10 dalek MoarVM/moar-jit: Try to fix nwc10++ ASAN barf
10:10 dalek MoarVM/moar-jit:
10:10 dalek MoarVM/moar-jit: When an inlined frame refers to the outer frame,
10:10 dalek MoarVM/moar-jit: we should still get the lexical types from the outer
10:10 dalek MoarVM/moar-jit: frame (of course :-)). Note that the actual code
10:10 dalek MoarVM/moar-jit: path seems not to have been tested.
10:10 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/fe014aadd0
10:10 brrt ok, great
10:10 brrt we may fix that one day
10:10 brrt but not today
10:10 brrt :-)
10:11 jnthn yeah, that's a hard one :)
10:12 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
10:12 brrt \o/
10:15 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
10:16 nwc10 All tests successful.
10:16 brrt \o/
10:16 brrt :-D
10:16 nwc10 jnthn: NQP tests don't run in parallel. Somewhere I have a patch to fix that
10:16 brrt thanks nwc10++
10:16 nwc10 so, obviously, run aware before Rakudo blows up...
10:17 jnthn Much safer than running unaware...
10:18 nwc10 OK, we're into stage parse
10:18 nwc10 yes, naughty fingrs
10:19 brrt nb
10:19 brrt i expect a getlex for an object to blow up one day or other
10:19 brrt with sigtrap
10:19 brrt why? i put a breakpoint instruction in the auto-viv code
10:20 brrt somehow it hasn't been executed yet
10:20 brrt you all have a nice weekend as well :-)
10:20 brrt (and i promise i'll backlog :-))
10:20 brrt left #moarvm
10:24 jnthn o/
10:24 nwc10 got past setting
10:24 nwc10 got past sanity tests, into spectests
10:25 nwc10 This is MoarVM version 2014.06-158-gfe014aa
10:25 nwc10 I did check. I am surprised.
10:27 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
10:27 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. :)
10:28 nwc10 I'm pretty sure I'm building using the same command from shell history as last time
10:28 timotimo oh, neato
10:29 timotimo 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.
10:29 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?
10:32 timotimo 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.
10:32 jnthn Yes, JITting should help the branch predictor a lot.
10:33 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 timotimo as opposed to one slot per occurence after jitting
10:33 timotimo that's pretty cool
10:33 timotimo oh, whether or not decont will invoke depends entirely on a container spec?
10:34 jnthn Right
10:34 timotimo like a boolification_spec, and i guess also numification_spec?
10:34 jnthn I suspect we'll be able to have spesh turn some deconts into cheap things, though.
10:34 timotimo i don't recall anything about a stringification spec
10:34 jnthn There isn't a spec for numification/stringification
10:34 timotimo OK
10:34 jnthn That's just case analysis in the op
10:35 nwc10 t/spec/S03-metaops/hyper.rakudo.moar hits
10:35 nwc10 t/spec/S03-metaops/hyper.rakudo.moar hits trace/breakpoint trap
10:36 nwc10 t/spec/S17-supply/classify.t t/spec/S17-supply/categorize.t are in their current usual state of sin
10:36 nwc10 t/spec/S32-io/IO-Socket-Async.t fails randomly
10:38 lizmat nwc10: are you talking about categorize that I broke yesterday, or something else ?
10:47 nwc10 I don't know.
11:08 nwc10 someone did something? as they pass now
11:08 nwc10 (I updated stuff and reran)
11:11 lizmat ok, then the S17-supply tests failing were my fault for removing the paused functionality from Supply.new
11:19 teodozjan_ joined #moarvm
11:21 jnthn On supplies, RxJS has got https://github.com/Reactive-Extensions/RxJS/blob/master/src/core/linq/observable/exclusive.js which is like migrate but different :) Wonder if we might want that one in our collection of supply-of-supply handlers too :)
11:48 nwc10 jnthn: if you really want to go ASAN squeaky clean, there's still one barf left, with the fixed size allocator disabled: http://paste.scsys.co.uk/408019
11:49 jnthn nwc10: Yeah, aware of that one; didn't get to the bottom of it yet.
12:14 jnap joined #moarvm
12:18 cognominal joined #moarvm
12:38 timotimo ah, actually we have a fetch_never_invokes flag that we can use
12:40 jnthn timotimo: I think we hang a spesh function off the spec.
12:41 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.
12:41 timotimo in that case we don't even need a special instruction yet
12:41 jnthn So it's just going to spesh like an attribute access does.
12:41 timotimo aye, i just found vm/moar/.../container.c
12:41 timotimo that'd be perfect
12:41 timotimo do you see any stumbling blocks i should be aware of?
12:42 jnthn For fetch? No, not really.
12:42 timotimo otherwise i could probably get to it right now
12:42 timotimo do we ever do store_unchecked on containers yet?
12:42 timotimo it says in the corresponding comment that an optimizer could emit that if it knows stuff
12:46 jnthn Yeah, we do
12:46 jnthn In parameter handling
12:47 timotimo ah, nice.
12:48 timotimo 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
12:49 timotimo ah, REPR_data might contain the offset for some kind of container "in the future"
12:52 timotimo garden work &
12:58 teodozjan_ hi again, what does mean: Unhandled exception: ctxlexpad needs an MVMContext?
13:02 jnthn Means something tried to use the ctxlexpad op (which is for introspecting a lexpad) and failed for some reason
13:09 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
13:10 timotimo and i should only try to optimize the decont into a sp_p6oget_o if it's also FACT_CONCRETE?
13:11 jnthn yes
13:18 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:19 jnthn :P
13:27 timotimo oh well, a segfault
13:34 timotimo wrong order of function pointers
13:48 timotimo jnthn: with my opt, only io-socket-async seems to fail :D
13:55 timotimo jnthn: how can i construct a bit of example code that ought to trigger my opt in spesh?
14:02 klaas-janstol joined #moarvm
14:06 btyler joined #moarvm
14:34 timotimo huh. why would SPESH_FACT_KNOWN_TYPE be set, but facts->type be 0x0?
14:37 timotimo oh yikes, bus error?!
14:39 timotimo and the stack trace i get looks b0rked
14:40 timotimo Spesh: unknown operand type 0 in codegen (op CJK COMPATIBILITY IDEOGRAPH-2F816) - wait what
14:42 jnthn timotimo: Well, any decont should...
14:43 jnthn timotimo: Look at how infix:<+> gets speshed if you call it with $a + $b for example
14:44 timotimo it should also be a case where decont doesn't simply turn into set
14:44 timotimo oh, but in this case it can't
14:44 jnthn right
14:45 jnthn 'cus it actually needs to decont
14:46 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:50 timotimo i don't know what i did wrong :S
14:52 timotimo i suppose i'll push a diff
14:54 dalek MoarVM/spesh_decont_contspec: e9f379e | (Timo Paulssen)++ | src/ (3 files):
14:54 dalek MoarVM/spesh_decont_contspec: give ContainerSpec a spesh function, use it for decont.
14:54 dalek MoarVM/spesh_decont_contspec: review: https://github.com/MoarVM/MoarVM/commit/e9f379ee02
14:55 timotimo this branch exists in rakudo as well
14:55 timotimo 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 #moarvm
17:35 btyler_ joined #moarvm
17:36 d4l3k_ joined #moarvm
17:38 jnthn timotimo: Does that patch alone change anything? Or does it pair with a Rakudo one?
17:38 jnthn oh, duh, found it
17:39 jnthn (the Rakudo commit)
17:39 jnthn offsetof( Rakudo_Scalar, value );
17:39 jnthn It needs to be the offset of the data portion of the object
17:39 jnthn So, minus the header
17:51 woolfy joined #moarvm
18:04 timotimo that'd explain something
18:14 timotimo jnthn: after subtracting offsetof( MVMObjectStooge, data ), it's giving me an "invalid utf8" error in stage parse :(
18:16 timotimo must be looking at bogus memory
18:18 brrt joined #moarvm
18:21 brrt nwc10: ping
18:21 brrt i noticed you caught a sigtrap
18:21 brrt awesome
18:22 brrt that is in tests, right?
18:23 brrt wrt to 'invokish' ops
18:23 brrt i have a plan, with the following reasons
18:23 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! :)
18:23 brrt yes, i've seen that too, awesome :-)
18:24 timotimo except it's pretty b0rked
18:24 brrt timotimo++
18:24 brrt well, you'll have to start somewhere
18:24 timotimo right; but i don't know where to continue looking; i can't get it to dump core any more ...
18:24 timotimo maybe you can have a look?
18:25 nwc10 brrt: yes, that's in one test, and it's the only difference in behaviour from master
18:26 brrt the sigtrap was expected, actually\
18:26 brrt i.e. i was hoping for /something/ to trigger it
18:26 nwc10 yes, IIRC you'd said it was the place holder for something
18:27 brrt you can (i'm not on a usable system right now) try if removing the following line makes it work:
18:27 brrt https://github.com/MoarVM/MoarVM/blob/moar-jit/src/jit/emit_x64.dasc#L389
18:28 brrt because if it works, that means the vivification also works :-)
18:29 brrt timotimo, not on a usable (bulding) computer right now, sorry
18:29 timotimo fair enough
18:30 timotimo i thought maybe a look at the diff would be enlightening
18:30 brrt i'll do that, then :-)
18:30 timotimo i don't need to "allocate" a third operand to hold information on the offset, right?
18:31 timotimo 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
18:36 jnthn o/ brrt
18:38 [Coke] everytime someone says brrt now I imagine someone is getting shocked.
18:39 brrt back
18:39 brrt why do you imagine that? :-o
18:40 [Coke] onomatopoeia
18:40 japhb I could see that if his alias was bzzzt
18:41 brrt aha, ok :-)
18:41 brrt i've heard other explanations, even
18:45 jnthn timotimo: Wait...do you allocate space for the extra operand?
18:46 jnthn ins->operands[2].lit_i16 = offsetof( Rakudo_Scalar, value );
18:46 jnthn decont is only 2 operands big, so that's going to scribble on random memory when you assign to the [2]
18:47 * brrt concurs
18:47 brrt decont is dst, src iirc
18:49 jnthn There are other opts that allocate bigger spesh operand space to look at for inspiration
18:49 jnthn (uses MVM_spesh_alloc)
18:50 brrt wouldn't a sequence of spesh_alloc, memcpy(), assign work?
18:50 jnthn Yes
18:50 jnthn Though I may just write two assignments instead of messing with memcpy... :)
18:51 brrt memcpy ftw :-))
18:53 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 jnthn Whereas assignments I can read and be comfortable with immediately.
18:53 jnthn For any more than 2 things then yeah, memcpy for sure :)
18:53 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
18:53 brrt well, i agree with that
18:53 brrt strcpy is more complex even
18:54 brrt if any invokish ops actually invoked, then the old frame* and the cur_frame* should be different
18:54 brrt comparing them is a single instruction for the jit, and calling out is also pretty cheap
18:55 jnthn OK
18:55 jnthn falling out?
18:55 jnthn or did you really mean calling? :)
18:55 brrt yeah, that's what i mean
18:55 brrt :-)
18:55 rurban in a register? shouldn't that be better on the stack?
18:56 brrt some registers are non-volatile (actually, about half of them are)
18:56 rurban you'll never who globbers that register (any sunfunction)
18:56 jnthn Were you going to keep cur_frame around for other reasons anyway?
18:56 brrt variables that you use really often are best put in one of these
18:56 rurban subfunction or external fun
18:57 brrt rurban - amd x64 ABI (or windows x64 ABI) specifies it quite clearly, fortunately :-)
18:57 jnthn non-volatile = callee saves, no?
18:57 brrt yes
18:58 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
18:59 rurban ok, if it works
18:59 brrt i understand :-)
18:59 jnthn Well, if it's what the ABI specs... :P
18:59 brrt (your scepticism, i mean)
18:59 rurban I was more used to i386 those times, and then we put everything on the stack
19:00 brrt but i first noticed the pressence of these registers (and how many of them there are) when i accidently clobbered one
19:00 brrt http://msdn.microsoft.com/en-us/library/9z1stfyw.aspx is a good resource (for win64)
19:00 rurban rbi is typically used for that, right? if it's free
19:01 brrt you mean rdi? or rsi?
19:02 brrt rdi and rsi are somewhat annoying as windows makes them callee-save and posix makes them caller-save
19:02 brrt i could pretend they are caller-save on windows, too, simply by optionally saving-and-restoring them
19:02 brrt rbx is also callee-save, and i used it for the pointer to the 'moar registers'
19:05 rurban I meant rbp with -fomit-frame-pointer
19:05 brrt oh, i see :-)
19:05 rurban for -O3, this would be free
19:05 brrt you can omit the frame base pointer? oh
19:06 brrt ]i use it in the JIT, though
19:06 rurban yes, counter everything from rsp only
19:06 rurban count
19:06 brrt i see
19:06 brrt if you know always exactly how large the stack frame will be, you can do that
19:06 brrt interesting
19:07 rurban In my potion jit have to keep rbp, because coros need it. Other than that, I could use rbp for something better
19:08 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
19:09 brrt hmm, why?
19:09 jnthn brrt: Yes, I noticed tc->cur_frame equivalent showing up a few times :)
19:10 rurban see e.g. https://github.com/perl11/potion/blob/master/core/callcc.c I need rsp and rbp there
19:12 brrt right :-) so these can be eliminated then
19:13 brrt that code makes me ponder the relative benefits of AT&T vs Intel syntax for  ASM :-)
19:14 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!" )
19:15 brrt i actually learned AT&T syntax first, but now i find Intel syntax slightly easier to read
19:16 rurban So I just compile this .o (using %rbp) with -fno-omit-frame-pointer to be on the safe side.
19:18 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 :-)
19:19 * brrt off
19:19 jnthn o/
19:19 nwc10 brrt: wait a mo?
19:20 nwc10 ./perl6-m t/spec/S03-metaops/hyper.rakudo.moar
19:20 nwc10 without the int 3
19:20 nwc10 [is running...]
19:20 nwc10 eh? still hits Trace/breakpoint trap
19:21 nwc10 confused. Please don't let me detain you further, if you want to go
19:21 brrt hmmm...
19:21 brrt do you happen to have lua installed?
19:21 brrt :-)
19:22 * brrt looks for other sources of breakpoints
19:22 nwc10 found one in src/jit/emit_posix_x64.
19:23 brrt well, that explains
19:23 nwc10 Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
19:23 brrt you probably don't have lua and lua bitop installed
19:23 brrt lua -e 'require("bit")'  says?
19:23 nwc10 lua: (command line):1: module 'bit' not found:
19:23 nwc10 plus a backtrace
19:23 nwc10 so, you're correct
19:24 brrt http://bitop.luajit.org/ :-)
19:24 nwc10 OK
19:24 nwc10 I don't think I can get that fixed up in a hurry
19:25 nwc10 I'm not root on the fast x86_64 machine I'm testing on
19:25 nwc10 and I'm too tired (And supposed to be packing) to figure out how to do it locally and ship the fixes up
19:26 brrt very well, it can wait i guess :-)
19:26 brrt it's been a long day
19:26 brrt thanks for your help, anyway
19:26 jnthn Long train journey?
19:26 brrt 3 hours 44 minutes
19:26 brrt long, for the netherlands anyway
19:26 nwc10 brrt: no problem. (a) What you're is very impressive (b) I think you deserve a weekend off
19:27 nwc10 what you're doing
19:27 nwc10 see, I'm too tired to type correctly
19:27 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
19:27 jnthn Yeah, I'm used to 4-hour-and-a-bit trips to Stockholm, so 3:44 doesn't feel too bad.
19:27 jnthn timotimo: No, you don't have to free anything.
19:28 brrt thanks, see you after the weekend :-)
19:28 jnthn nice weekend o/
19:28 timotimo well, now that i properly do the thing with the memory it doesn't crash any more
19:28 brrt you too o/
19:28 timotimo so that's a good start
19:28 timotimo brrt: enjoy your weekend!
19:32 dalek MoarVM/spesh_decont_contspec: 0fb638b | (Timo Paulssen)++ | src/ (2 files):
19:32 dalek MoarVM/spesh_decont_contspec: + comment, - debug print.
19:32 dalek MoarVM/spesh_decont_contspec: review: https://github.com/MoarVM/MoarVM/commit/0fb638b11a
19:42 timotimo spectests are clean, yay
19:45 dalek MoarVM: e9f379e | (Timo Paulssen)++ | src/ (3 files):
19:45 dalek MoarVM: give ContainerSpec a spesh function, use it for decont.
19:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e9f379ee02
19:45 dalek MoarVM: 0fb638b | (Timo Paulssen)++ | src/ (2 files):
19:45 dalek MoarVM: + comment, - debug print.
19:46 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0fb638b11a
20:14 jnthn I think this weekend I'm going to finally tackle Moar's strings.
20:14 jnthn Because the string-related benchmarks are just awful.
20:15 nwc10 is your weekend 2 days or 3?
20:15 nwc10 I'm trying to assess how crazy you are.
20:16 jnthn 2
20:16 nwc10 OK. very crazy :-)
20:16 nwc10 good luck
20:17 FROGGS ohh :o)
20:18 jnthn oh timo?
20:18 jnthn src\spesh\optimize.c(262) : warning C4090: 'initializing' : different 'const' qualifiers
20:18 jnthn src\spesh\optimize.c(267) : error C2275: 'MVMSpeshFacts' : illegal use of this type as an expression
20:23 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
20:23 camelia rakudo-moar 87dcd1: OUTPUT«timotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimotimo…»
20:24 dalek MoarVM: 645e0ef | jnthn++ | src/spesh/optimize.c:
20:24 dalek MoarVM: Fix MSVC build.
20:24 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/645e0ef3b2
20:25 japhb jnthn, do you want a perl6-bench commitbit so you can add more benchmarks yourself?
20:25 jnthn japhb: Sure, can do
20:25 japhb OK, hold on ...
20:26 japhb Done.
20:26 jnthn thanks.
20:26 japhb np
20:27 japhb (Shoulda done it sooner, honestly, but for some reason I got the impression you were less interested before.)
20:28 japhb Anyone else I should add while I'm here?  timo already has one.
20:28 nwc10 All tests successful.
20:28 nwc10 (ASAN, Linux)
20:28 japhb nwc10, do you use perl6-bench?
20:28 nwc10 no
20:29 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.
20:29 jnthn And that needed a bit more fiddling. Especially to do it on Windows. :)
20:30 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:32 japhb 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:34 cognominal joined #moarvm
20:46 jnthn japhb: I wasn't really expecting the 5 vs 6 perf thing to be attacked from both directions, but... :P
20:47 timotimo jnthn: sorry for making msvc unhappy ... again
20:48 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?
20:48 timotimo -fpedantic?
20:49 FROGGS I-f no idea...
20:50 jnthn No -fing clue...
20:53 dalek MoarVM: 1bd2d3a | jnthn++ | / (6 files):
20:53 dalek MoarVM: Make various spesh things available publicly.
20:53 dalek MoarVM:
20:53 dalek MoarVM: Since extops and container specs may participate in spesh also, and so
20:53 dalek MoarVM: need some graph manipulation APIs.
20:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1bd2d3a2ed
20:56 [Coke] many of clang warnings seem to be of const or unsigned warnings.
20:59 timotimo was i using non-public things in the rakudo patch? :o
21:00 jnthn yes :)
21:01 timotimo d'oh
21:01 timotimo gcc didn't care at all
21:06 japhb FROGGS, Are you referring to --std=c89 ?
21:06 FROGGS japhb: I think so, yes
21:28 dalek joined #moarvm
22:30 jnap joined #moarvm

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