Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-07

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

All times shown according to UTC.

Time Nick Message
00:24 btyler joined #moarvm
00:30 btyler joined #moarvm
00:54 [Coke] m: say Order::Decrease
00:54 camelia rakudo-moar fc4943: OUTPUT«Could not find symbol '&Decrease'␤  in method <anon> at src/gen/m-CORE.setting:12877␤  in any find_method_fallback at src/gen/m-Metamodel.nqp:2604␤  in any find_method at src/gen/m-Metamodel.nqp:934␤  in block  at /tmp/7egrdnNexb:1␤␤»
00:55 [Coke] we have tests for Order::Decrease in roast. Anyone object to me removing them?
01:36 TimToady well, they're deprecation tests, but perhaps Decrease has been sufficiently deprecated
01:38 TimToady n: say 23 cmp 22
01:38 camelia niecza v24-109-g48a8de3: OUTPUT«More␤»
01:49 [Coke] the spec tests shouldn't be testing things we had once but have since removed.
01:50 [Coke] they should be testing the spec.
02:03 FROGGS joined #moarvm
06:29 nwc10 good *, *
06:45 sergot o/
06:57 FROGGS joined #moarvm
07:01 FROGGS uff: moar: double free or corruption
07:02 FROGGS https://github.com/coke/perl6-roast-data/blob/308115a53b93e85d2a802c2d92648a51298a3ab7/log/rakudo.moar_summary.out#L1766
07:03 nwc10 ASAN already found that one, and jnthn knows about it
07:04 nwc10 http://paste.scsys.co.uk/406590
07:04 nwc10 I don't know how to fix it
07:04 FROGGS ahh, nice :o)
07:04 nwc10 but it's an out of bound write
07:04 FROGGS oob write... interesting O.o
07:09 dalek MoarVM/nativecast: a4cdc2d | jnthn++ | src/spesh/inline.c:
07:09 dalek MoarVM/nativecast: Fix merging of inline table entries.
07:09 dalek MoarVM/nativecast:
07:09 dalek MoarVM/nativecast: Need to add offsets to return address deopt location, locals, and
07:09 dalek MoarVM/nativecast: lexicals.
07:10 dalek joined #moarvm
07:31 FROGGS nwc10: is such a union inlined in the struct? https://github.com/MoarVM/MoarVM/blob/master/src/6model/6model.h#L143
07:36 nwc10 in which struct? I'm a bit confused. That union is within the header common to every GC'able
07:39 FROGGS I'm just asking how such a struct like MVMCollectable lives in memory...
07:40 FROGGS is sizeof(MVMCollectable) == sizeof(uint32 + uint16 + uint16 + void*)?
07:41 nwc10 the union is there, so it's sizeof(uint32 + uint16 + uint16 +
07:41 nwc10 void * + void *)
07:41 FROGGS or: sizeof(MVMCollectable) == sizeof(uint32 + uint16 + uint16 + sizeof(sc_forward_u))?
07:41 nwc10 you're missing the MVMStable* at the end
07:41 nwc10 oh, no I'm confused
07:41 nwc10 you're right
07:41 nwc10 it's what you said
07:41 nwc10 and I  *thought* I had enough coffee
07:42 FROGGS okay, so such a union in a struct is represented as a pointer... k
07:42 FROGGS thank you :o)
07:42 nwc10 no. wait
07:42 nwc10 the struct *is* inline. But it's carefully chosen so that all the parts of it aren't larger than a pointer
07:43 FROGGS hmmmm
07:44 nwc10 struct MVMSerializationIndex *sci; is a pointer to a struct
07:44 nwc10 struct { MVMuint16 sc_idx; MVMuint16 idx; } sc;
07:44 nwc10 is a struct
07:44 nwc10 which, "oh dear" is the same size as a pointer
07:44 FROGGS aha
07:44 nwc10 (32 bit systems)
07:50 FROGGS I love Perl 6: https://gist.github.com/FROGGS/79fe3fcf799724fa6106
07:51 vendethiel (people making us love Perl 6)++
08:23 jnthn morning o/
08:23 jnthn FROGGS: That's evil! :P
08:25 jnthn I had hoped one of my earlier fixes had nailed http://paste.scsys.co.uk/406590 but apparently not...
08:30 FROGGS jnthn: no, that's awesome :o)
08:30 jnthn The two aren't mutually exclusive :)
08:31 FROGGS that means that you can work around gc bugs by fiddling with the memory directly :P
08:31 FROGGS (from within perl)
08:33 jnthn o.O
08:33 FROGGS *g*
08:35 FROGGS I guess it would be impressive to draw a memory map (using svg) of an object in the same program and show that at a conference...
08:39 jnthn True
08:39 jnthn Only problem is if it moves :P
08:40 FROGGS yeah, you have to be quick *g*
08:40 FROGGS jnthn: by the way, I going to merge nativecast in MoarVM/nqp/zavolaj today in case there is no intervention from your side :o)
08:41 jnthn FROGGS: OK; going to be busy for the day on a $dayjob project.
09:52 sergot Can I use us__stream_fd somehow in moar?
09:52 sergot uv__stream_fd() *
09:56 jnthn The double-underscore means it's private to libuv, no?
09:57 teodozjan joined #moarvm
10:02 sergot jnthn: sounds reasonable, I don't know libuv well.
10:03 sergot yet :)
10:03 jnthn So, it's preferable not to use those things, because as soon as we update libuv...it could break.
10:06 sergot jnthn: I really need to get IO::Socket's fd somewhere, any ideas how can I do this?
10:07 sergot It's easy for syncfile, but what about syncsocket?
10:10 jnthn What do you need it for?
10:12 sergot For my openssl gsoc stuff, there is an openssl function SSL_set_fd($ssl, $fd), and.. I need to pass a $fd here
10:13 sergot So, moritz suggested to write nqp op nqp::getfdfromfh or something and I'm struggling with it now
10:14 sergot anyway, for now I just want to printf a fd of my socket on creating it
10:14 sergot I tried getting fd from $!PIO (which is MVMOSHandle) but it's not so easy for sockets (it's much easier for files)
10:16 * vendethiel is watching https://www.youtube.com/watch?v=FGgFMZhnXvU ... interesting jit stuff
10:23 jnthn sergot: The library is going to want to read/write using the fd, I guess?
10:24 sergot jnthn: yes
10:25 timotimo the lower parts of jnthns benchmark run are quite interesting, i find
10:25 jnthn I'm a little concerned how both libuv and openssl thinking they own the same fd will work out...
10:25 jnthn Also whether we have any hope of obtaining the underlying fd on, say, the JVM...
10:26 timotimo we're quite faster than perl5 at rational numbers, that's good
10:26 jnthn And whether using the BIO API described in http://www.ibm.com/developerworks/opensource/library/l-openssl/index.html and letting OpenSSL manage the whole thing, if we're using it, could be wise...
10:26 timotimo and apparently we're faster than perl5 with rational numbers, too?
10:27 timotimo er, imaginary numbers
10:31 sergot jnthn: you're right
10:31 sergot hmm
10:31 sergot FROGGS: what do you think?
10:33 FROGGS sergot: I think we should perhaps let openssl manage the connection if we can't obtain the fd easily
10:33 jnthn It's not just about obtaining the fd
10:33 FROGGS and then we provide a subclass of IO::Socket::INET
10:33 FROGGS jnthn: yes, true
10:34 jnthn It's that libuv will likely have set it up expecting to do async IO stuff with it.
10:35 jnthn It may work out, it just feels rather fragile.
10:35 FROGGS yeah, I guess you are right...
10:38 FROGGS sergot: I think I'd make the bindings to openssl, and then expose tls ops like tls_readfh and tls_socket that take the same arguments as the non tls ops that nqp provides atm
10:38 FROGGS sergot: the you can easily port IO::Socket::INET to use these ops
10:38 timotimo why can't we just be doing async io on openssl sockets? :3
10:40 FROGGS sergot: the benefit of implementing ops like tls_readfh is that you know in detail what it gets and what it should do
10:40 jnthn timotimo: Looks like openssl can do non-blocking too
10:41 timotimo oh, neat
10:41 jnthn But it seems it wants to "own" the connection
10:41 timotimo understandably
10:41 timotimo well, how do the node.js people do ssl?
10:42 sergot FROGGS: ok
10:42 jnthn ooh, good question
10:42 FROGGS sergot: unless jnthn can propose a better way of doing it...
10:43 jnthn Well, seeing how http://nodejs.org/api/tls.html is done may be interesting
10:43 FROGGS I guess I have to play with openssl before I can say more on this topic
10:45 FROGGS that document is indeed very informative
10:49 jnthn https://github.com/joyent/node/blob/master/lib/_tls_wrap.js may also be worth a look
10:54 dalek MoarVM: 0054a6a | sergot++ | / (8 files):
10:54 dalek MoarVM: MVM_nativecall_cast added
10:54 dalek MoarVM:
10:54 dalek MoarVM: MVM_nativecall_cast has been added which provides casting an
10:54 dalek MoarVM: OpaquePointer to any type we want. It makes us able to unpack things
10:54 dalek MoarVM: conditionally.
10:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0054a6a18c
10:54 dalek MoarVM: 6fda5ad | (Tobias Leich)++ | src/core/nativecall.c:
10:54 dalek MoarVM: fix bogus declaration (copy&pasto)
10:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6fda5ad921
10:54 dalek MoarVM: 55187a1 | (Tobias Leich)++ | / (6 files):
10:54 dalek MoarVM: add box target parameter to nativecallcast
10:54 dalek MoarVM:
10:54 dalek MoarVM: This op now gets a param that says something about the bit size we are
10:55 tadzik \o/
10:58 dalek joined #moarvm
11:31 brrt joined #moarvm
11:31 brrt \o moarning
11:32 jnthn good (UGT :)) moarning, brrt o/
11:32 brrt :-)
11:32 jnthn whoa, that's some heavy rain...
11:32 FROGGS hi brrt
11:32 FROGGS jnthn: here too
11:32 brrt here yesterday
11:32 FROGGS at least it is starting to get heavy
11:33 jnthn Had some thunder too
11:34 brrt i figured that - for now - we'd be in trouble if the last instruction in the graph was an invoke instruction (i.e., a tail call without return)
11:35 jnthn I think by contract code must end with a return.
11:35 brrt and  that i'd compile this somewhat differently from a 'regular' invoke, even if the next instruction is a return, because in that case there is at least a label to jump to
11:35 jnthn To the degree the bytecode assembler inserts one if it's missing
11:35 jnthn And presumably the validator whines if it's missing.
11:35 brrt ok, very well
11:36 brrt anyway, i could suppose that in some cases we might optimize it to a tail call directly,  but in that case that will likely be a spesh op, so i'll handle that separately
11:39 brrt i.e. if you know you can tail call then i suppose you can also compile a jump
11:43 jnthn *nod*
11:43 jnthn That's an opt for later, though :)
11:45 FROGGS I wonder what normal ppl think what a tail call optimization is...
11:46 jnthn I'm not sure normal people think about things like that... :P
11:47 FROGGS hehe
11:48 FROGGS that might be totaily true :P
11:48 brrt yes, it is, lets not get ahead with the moving targets just yet
11:49 jnthn Yeah. It'd be rather nice if the JIT could, for example, do its magic on some of the benchmarks. And we need invoke support and OSR for that. :)
11:50 brrt :-) benchmarks are important
12:06 timotimo is there much left for OSR in the jit part? i thought it'd be only a tiny bit of work on top of the spesh OSR?
12:06 brrt i don't know about that... i'm not sure how OSR works in moar
12:08 cognominal joined #moarvm
12:10 brrt bbiab
12:22 jnap joined #moarvm
12:31 nwc10_ joined #moarvm
12:31 _sri joined #moarvm
12:34 brrt joined #moarvm
12:59 [Coke] (order decrease, whoops I was in the wrong channel when I started that convo)
13:20 woolfy joined #moarvm
13:32 lizmat joined #moarvm
13:33 btyler joined #moarvm
13:42 zakharyas joined #moarvm
14:33 brrt vendethiel - thanks for that link
14:33 brrt vendethiel++ :-)
14:40 cognominal vendethiel++ # itou
15:15 dalek MoarVM/moar-jit: e528d54 | (Bart Wiegmans)++ | / (3 files):
15:15 dalek MoarVM/moar-jit: Add sp_getspeshslot
15:15 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e528d54544
15:15 dalek MoarVM/moar-jit: 2b2fd45 | (Bart Wiegmans)++ | src/ (6 files):
15:15 dalek MoarVM/moar-jit: Refactor addresses to call args
15:15 dalek MoarVM/moar-jit:
15:15 dalek MoarVM/moar-jit: The JIT never used addresses as addresses and only ever
15:15 dalek MoarVM/moar-jit: as call args. Call arguments have quite different features
15:15 dalek MoarVM/moar-jit: from addresses; importantly, they care about the difference
15:15 dalek MoarVM/moar-jit: between floating point and integer numbers.
15:15 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/2b2fd45be0
15:15 brrt long story short, invocation is invovled
15:18 FROGGS what does that mean?
15:21 ssutch joined #moarvm
15:21 brrt there are a /lot/ of unimplemented ops that have to be done before i can get to invocation proper
15:22 FROGGS ahh, okay :o)
15:22 brrt one of which is, for example, smart numify, which needed the address of a register as an argument
15:22 brrt i hadn't done that yet, but now i have
15:22 brrt another is current callsite
15:22 brrt i.e. prepargs
15:23 FROGGS does that mean that you can jit partial stuff atm, but when something gets invoked this branch will not be jitted?
15:24 FROGGS I have problems imagining how that works...
15:25 brrt no, i can't JIT partial frames, and won't be able to :-)
15:25 brrt i try to construct a JIT graph partially, and if i encounter something that doesn't work, i bail out
15:27 FROGGS okay, so when a frame contains an invocation, the frame won't be jitted
15:27 brrt exactly
15:27 FROGGS okay, understand
15:27 brrt now the invocation itself is already pretty complex
15:28 brrt but it's doable, right?
15:28 brrt but there are so many things that come before it
15:28 FROGGS hehe, I have no idea :o)
15:29 brrt well, it's bascially setting pointers and calling MVM_frame_invoke
15:29 FROGGS that sounds indeed doable :o)
15:29 brrt it's doable but complex
15:29 FROGGS bbi15
15:30 brrt ok, see you then
15:33 jnthn brrt: I'd put smart numify off until *after* invocation, as it may invoke.
15:33 brrt oh... really?
15:33 brrt hmmm
15:33 brrt that
15:33 jnthn Yeah. There are a few things like this.
15:34 brrt is annoying
15:34 brrt :-)
15:34 brrt ok, i'll disable smart numify for now then
15:34 jnthn But really a call consists of prepargs, arg* ops (which are just stores), and an invoke of some kind at the end.
15:35 brrt uhuh
15:36 brrt i'm thinking i probably should put cur_callsite into a non-volatile register
15:36 brrt that, or collapse the whole of prepargs, arg*, invoke into a single node
15:36 brrt hmm
15:36 brrt i'm not against that idea at all, now that i think of it
15:37 brrt how about you?
15:37 brrt or does it often happen that there are conditionals between the arg* staments?
15:39 jnthn I don't think that's allowed
15:39 jnthn As in, think the validator refuses it at the moment.
15:39 jnthn I'm almost certain we never emit it
15:39 jnthn The call code-gen just does prepargs arg*,
15:40 brrt ok, i can always bail compilation in the worst case
15:40 brrt and in the best case, i can actually represent the conditionals in the tree - but that's far from now
15:41 jnthn Also note that there's 7 arg instructiosn only. 4 of them (reg to arg) are probably identical at assembly level.
15:42 jnthn argconst_s is the only slightly more intresting one.
15:42 FROGGS joined #moarvm
15:43 brrt yes, i see
15:43 jnthn You may want to factor what prepargs does out into a function, fwiw
15:43 jnthn which returns the callsite
15:44 * brrt nods
15:44 brrt but i'm going to make dinner now
15:44 jnthn (and have interp.c call that too)
15:44 * brrt nods again :-)
15:44 jnthn The piece that'll need more work is the invoke itself.
15:45 brrt fastinvoke isn't very complex
15:45 brrt but i suppose not very common, either
15:45 jnthn It has the same structural issue as any invoke.
15:45 jnthn Which is, invoke today assumes interpreter semantics.
15:46 brrt as in, we need to jump out of jit to the interpreter?
15:46 jnthn No
15:46 jnthn Just that we need to refactor how invoke works to know about JIT
15:46 jnthn At present it returns nothing
15:46 brrt uhuh
15:47 brrt what would you like it to return, then? i'm not totally following i think
15:47 jnthn When called from JIT land it needs to (a) know it doesn't need to do the setting up of the JIT thunk, and (b) return to the JIT the address of the JITted code to jump to
15:47 jnthn That's when it's a JIT -> JIT call
15:48 brrt oh, i see
15:48 jnthn The other case is JIT -> interpreter, which I guess could be signaled with a NULL being returned.
15:48 brrt or, we could ignore that case for now, and live with the fact that this isn't ideal in terms of speedup
15:48 jnthn And then the thing you already have - the mechanism for the JIT to return to the interpreter but say "don't actually call the return thing" - comes into play.
15:48 jnthn Oh, and always fall back to the interpreter, and then re-enter the JIT?
15:49 brrt yes
15:49 jnthn Oh.
15:49 brrt ugly, i agree
15:49 jnthn Yeah, that actually does work for a first cut.
15:49 brrt but i see what you mean wrt to jit->jit calls
15:49 brrt how we can speed that up
15:49 jnthn Yeah. Feel free to skip the smart thing initially.
15:49 jnthn But it's an "obvious" optimization.
15:50 brrt in a way, the frame_invoke 'knows' the current frame is in JIT by the virtue of there being jit code and a 'jit continuation
15:50 brrt i'll note it and write it down :-)
15:50 jnthn Especially as for hot call paths the jump from JITted code should get branch prediction love. :)
15:51 brrt i'd hope so :-)
15:52 brrt see you in a few hours :-)
15:52 jnthn Happy cooking/nomming :) o/
15:52 brrt left #moarvm
15:59 carlin joined #moarvm
16:10 btyler_ joined #moarvm
16:14 vendethiel typo here : https://github.com/MoarVM/MoarVM/commit/2b2fd45be0894c8665aad82cd5e5082a5090bd9f "arugments"
16:46 timotimo oooh jitted invocations ♥
17:05 tadzik aww yiss
17:05 timotimo well, they're not here yet
17:06 timotimo but at least we have someone who knows how it can be implemented later
17:52 lue joined #moarvm
18:05 vendethiel (people knowing)++
19:05 dalek MoarVM/moar-jit: 148bde3 | (Bart Wiegmans)++ | src/jit/graph.c:
19:05 dalek MoarVM/moar-jit: Remove smart_numify support because it might invoke
19:05 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/148bde357c
20:07 [Coke] 440 warnings building moar.
20:07 FROGGS [Coke]: using clang?
20:07 [Coke] er, scratch that, but many.
20:08 [Coke] FROGGS: aye: Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
20:09 FROGGS would be a nice LHF for someone you has such a compiler
20:09 FROGGS who has*
20:09 [Coke] here's a chunk of them: https://gist.github.com/coke/bda800a830e6f653b4fc
20:20 [Coke] added some rakudo build warnings also.
20:20 [Coke] did a || build on rakudo-moar, saw this:
20:21 [Coke] perl -MExtUtils::Command -e cp perl6-m perl6
20:21 [Coke] The following step can take a long time, please be patient.
20:21 [Coke] /Users/willcoleda/sandbox/rakudo/install/bin/moar --libpath="/Users/willcoleda/sandbox/rakudo/install/languages/nqp/lib" perl6.moarvm --setting=NULL --ll-exception --optimi
20:21 [Coke] isn't that copy a bit premature?
20:21 [Coke] guessing we're missing some deps.
20:26 * jnthn manages to keep Moar and Rakudo builds warning-free on MSVC, and would be very happy to see that championed by others for different compilers
20:27 FROGGS jnthn: gcc is warning free also, due to masak++'s latest patch
20:27 jnthn ah, cool
20:27 jnthn I'd not remember that being noisy either
20:28 jnthn So, just clang is, well, clanging... :)
20:28 [Coke] I can take a look, but IANACP.
20:31 jnthn Me either, by clang's reckoning...
20:40 rurban if the code will pass -fsanitize=undefined we could safely use -O3 then
20:40 rurban parrot already is, but nqp not
22:34 jnap1 joined #moarvm
22:38 cognominal joined #moarvm

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