Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-21

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

All times shown according to UTC.

Time Nick Message
00:10 [Coke] hoelzro: (portfile) ok
00:16 [Coke] google news alert: http://park15.wakwak.com/~k-lovely/cgi-bin/wiki/wiki.cgi?page=PERL6
00:24 psch joined #moarvm
00:34 arnsholt joined #moarvm
00:41 hoelzro joined #moarvm
00:41 flussenc1 joined #moarvm
00:44 perlpilot joined #moarvm
00:44 leedo joined #moarvm
00:44 rudi_s_ joined #moarvm
00:45 nwc10_ joined #moarvm
02:37 flussence joined #moarvm
06:13 danaj joined #moarvm
06:34 FROGGS o/
07:58 TEttinger joined #moarvm
08:12 nwc10 \o
10:03 brrt joined #moarvm
10:10 brrt \o
10:26 jnthn o/
10:26 brrt how is packing going along
10:27 jnthn Slowly, but it's getting there :)
10:27 jnthn Been catching up on sleep plenty too :)
10:28 brrt very nice
10:35 brrt ok, i kind of get the feeling i'm spamming, but, i think i can do the following
10:35 brrt i can mark the REX byte by emitting a DASM_MARK action *after*  it
10:36 brrt then i can OR in the bytes in DASM_VREG
10:39 brrt when i do need to add a REX byte, i should add this to the offset in dasm_link
10:39 brrt so to make space for it
10:41 brrt oh, that can be done using DASM_SPACE, which can be inserted at dasm_put time
10:41 brrt the size of the spaces, that is
10:47 jnthn Seems very state-machine-y
10:48 brrt yes. dasm is very state-machine-y
10:49 jnthn Makes sense for what it's doing :)
10:49 brrt as in, dynasm the preprocessor takes a bit of a global view, but dynasm-the-runtime assembler works like a state machine
10:50 brrt it's interesting enough for a blog post, i think
10:51 brrt oh, jnthn, fwiw, we might want to coordinate our yapc talks a bit. I'll be talking about the relation between compiler and interpreter, and that has some intersection with vm engineering in general, i think?
10:52 jnthn Alternatively, we could just JIT everything to "mov"... :) https://github.com/xoreaxeaxeax/movfuscator
10:52 brrt :-D
10:52 brrt i know
10:52 brrt i think there was a paper on that last year
10:53 brrt nice github handle though :-)
10:53 jnthn :-)
10:53 jnthn Yeah, agree making sure our talks don't over-overlap is a good thing.
10:54 brrt right
10:54 jnthn I was going to keep mine at least somewhat high level, and try to extract some of the more general lessons about things that have worked well for us.
10:54 brrt i was going to be talking about the tension between JITting and interpreting
10:54 brrt e.g.
10:55 brrt for efficient interpretation, - supposing your dispatch time is considerable - you actually want a lot of high-level operations that do complex calculations
10:55 brrt that's not what you want for JITting
10:56 brrt and how the interpreter can always assume to know the full state of the program explicitly, and a lot of that moves to implicit knowledge encoded in the compiled frame
10:57 jnthn *nod*
10:57 jnthn It's an interesting angle. :)
10:57 brrt case in point: the MVM_coerce_istrue() operations
10:57 brrt i hope :-)
10:57 jnthn It's also worth noting though, that:
10:58 jnthn 1) There's also the bytecode size angle; we check for object truth all over, so if_o/unless_o are quite helpful.
10:59 brrt right. that's precisely the kind of tension that i think is interesting
10:59 jnthn 2) Many of the complex ops get lowered to simple ones in the process of specialization, so the JIT sees less of them.
10:59 jnthn But yes, lots of interesting trade-offs to discuss :)
10:59 brrt that too
10:59 brrt anyway, lunch &
10:59 jnthn ooh, not a bad idea... :)
11:00 brrt i *think* i should be able to produce a hacked dynasm tomorrow :-)
11:37 colomon joined #moarvm
12:44 Ven joined #moarvm
12:48 Ven joined #moarvm
13:02 flussenc1 joined #moarvm
13:04 rudi_s joined #moarvm
13:05 hoelzro_ joined #moarvm
13:28 moritz joined #moarvm
13:52 zakharyas joined #moarvm
14:26 JimmyZ_ joined #moarvm
14:46 JimmyZ_ joined #moarvm
15:26 FROGGS side note: the libffi code path passes all rakudo sanity tests except the callback one... (which is not handled yet at all)
15:26 FROGGS jnthn / brrt: do I need to care about spesh when it comes to nativecall?
16:33 Ven joined #moarvm
16:47 zakharyas joined #moarvm
16:50 jnthn FROGGS: Not yet.
16:51 jnthn (Eventually we want to be able to JIT them awesomely.)
17:04 FROGGS jnthn: I guess that won't be trivial, when looking at the nativecall functions...
17:05 jnthn Yeah, it's a project of its own :)
17:42 mj41 joined #moarvm
18:22 timotimo fortunately we only have to jit the native calls for the platform we're already jitting
18:31 vendethiel joined #moarvm
19:01 mj41 joined #moarvm
19:15 zakharyas joined #moarvm
19:17 FROGGS callbacks are working O.o
19:39 timotimo sweet!
19:40 japhb FROGGS: So what all do we gain from having both nativecall backends?  More platform/arch support?
19:41 FROGGS japhb: more platforms, yes
19:42 FROGGS and I can imagine that libffi is a little bit faster when calling C functions repeatedly
19:43 japhb "imagine"?  Is the API weighted in favor of faster repeated calls?  Or do you have timings?
19:44 FROGGS japhb: for dyncall we alloc/free more stuff when making the call into C, for libffi we do that once
19:44 japhb Ah, OK, gotcha.  Is libffi reentrant/threadsafe in that case?
19:45 FROGGS I think so
19:45 FROGGS but I'm not an expert when it comes to that
19:45 FROGGS hmmm, actually, I'm not sure
19:49 timotimo if it has anything that's sort of global, then it's definitely not threadsafe
19:51 FROGGS timotimo: the question is: how often do we call nqp::nativecallbuild per nativecall sub?
19:54 timotimo i think we only do once a sub gets "set up"
19:54 timotimo you can find it in NativeCall.pm, i think it is guarded by a $!setup flag
19:56 FROGGS yeah, I know
19:56 FROGGS so.. hmmm
19:57 FROGGS so I probably have to move the stuff that allocates the argument types and argument value slots to the call itself
19:57 FROGGS and not store it in the nativecallbody
19:58 timotimo at some point we want to do it differently anyway, so that we can know everything we need to know at jit time
19:58 timotimo also, the decont_all sub we use still annoys me a whole lot
19:58 timotimo because we can't de"virtualize" the loop at all
19:59 FROGGS do we still have that decont_all?
19:59 FROGGS I thought we got rid of it when making 'is rw' params work
20:00 timotimo i don't think so, let me have a look
20:01 timotimo yes, we do
20:01 timotimo but it had to learn about native containers
20:03 FROGGS yes, I did that
20:04 vendethiel joined #moarvm
20:04 timotimo right
21:16 FROGGS_ joined #moarvm
23:16 dalek MoarVM: cad11bd | timotimo++ | src/spesh/dump.c:
23:16 dalek MoarVM: output a callsite's flags in the spesh dump
23:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cad11bd354
23:34 timotimo the reason why optimize_can_op didn't work was because we just checked for the object pointer, but can_method_cache_only checked via MVM_is_null
23:35 timotimo i'm now running a spectest with re-enabled optimize_can_op
23:35 timotimo which may get us rid of a bunch of pieces of sink code-gen
23:35 timotimo only post-spesh, of course
23:46 timotimo hmm
23:47 timotimo if we have VMNull as the known type of something
23:47 timotimo is there any way whatsoever for can to return 1 for any method?

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