Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-06-29

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

All times shown according to UTC.

Time Nick Message
00:50 ggoebel9 joined #moarvm
01:05 ggoebel joined #moarvm
01:32 vendethiel joined #moarvm
03:33 * [Coke] finally opened a ticket to get Moarvm macport file updated, sorry for delay.
05:47 FROGGS joined #moarvm
05:59 FROGGS o/
06:03 dalek MoarVM: 728fa7a | FROGGS++ | build/setup.pm:
06:03 dalek MoarVM: use cross-platform devnull in build script
06:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/728fa7ab34
06:22 vendethiel joined #moarvm
06:51 zakharyas joined #moarvm
06:57 Ven joined #moarvm
07:03 brrt joined #moarvm
07:04 vendethiel joined #moarvm
07:05 brrt \o
07:13 FROGGS hi brrt
07:13 brrt hi FROGGS
07:58 jnthn morning o/
08:00 FROGGS morning jnthn
08:01 brrt morning jnthn
08:02 * FROGGS cries when looking at his work code... he'd like to run code in parallel in a POE worker, but that seems to be problematic in P5
08:03 JimmyZ it is easy by Inline::perl5 :P
08:03 masak FROGGS: worth a shot. I hear good things about POE.
08:04 nwc10 if your code objects to any sort of event loop or co-operation, maybe try https://metacpan.org/pod/Parallel::ForkManager ?
08:05 FROGGS masak: I use POE
08:06 FROGGS though forking in a worker is the issue... I tried to apply this to my code but failed: http://poe.perl.org/?POE_Cookbook/Child_Processes_Nested
08:07 FROGGS my main event loop is a POE::Wheel::SocketFactory that handles http/https connections
08:07 vendethiel joined #moarvm
08:10 brrt what's POE
08:11 FROGGS brrt: "POE is a Perl framework for reactive systems, cooperative multitasking, and network applications."
08:11 brrt ah
08:12 brrt looks quite useful
08:13 brrt ok, to give a minor update on my progress so far since last week
08:15 brrt you can do code generation in two ways; linearly, using register management and pre-generation register allocation to get good results, *if* you're compiling for a RISC machine
08:16 brrt that way is relatively simple, and would be a minor extension on what we currently have (at the cost of quite significant complexity),
08:17 brrt or you can use a tree-form, and then you can compile whole expressions at a time
08:17 brrt notably, moarvm bytecode can be seen as a linear IR
08:18 brrt the latter format can generate much better code because it encodes relations between instructions in a way that the linear form does not
08:18 brrt unless, of course, you treat the linear form like a tree
08:18 brrt it was and still is my intention to use the tree form, *however* all then depends on what we still call an expression and what we do not
08:18 * jnthn notes that what is a single instruction at VM level can be tree-ish at machine level...
08:19 brrt yes, exactly, that too
08:19 jnthn But that won't get us all the goodness since we want to avoid lots of the register writes
08:20 brrt to give a very simple example, suppose we try to generate an expresion from a basic block (or rather a set of expression, bear with me)
08:20 brrt suppose the last of the operations is an addition
08:20 brrt now in x86 i can do two things
08:20 brrt three, actually
08:21 brrt a): add register to register; b): add memory to register; c): add register to memory
08:21 jnthn FROGGS++ # warning is gone in Configure
08:22 FROGGS jnthn: and it wasn't even my fault :o)
08:22 FROGGS (at least kinda not)
08:22 brrt now whichever is actually cheaper depends on whether the second operand is in a register (the previous code) and on whether we will want to store the write operand into memory (i.e. we know that it'll spill)
08:23 brrt hence, the spill is also part of the expression
08:23 brrt (whereas hopefully no spill is necessary for temporary variables)
08:32 brrt hmm, i also have another plan
08:32 brrt a actionable plan, i might add
08:33 brrt maybe you recall i said something about using a string representation to map opcodes to c-calls
08:34 brrt (that is to say, a string, pointer pair representation, with the string representing the code and the pointer the c function
08:34 brrt )
08:34 jnthn Ah, think I vaguely remember
08:35 brrt well, one of the bigger advantages of that is that this can be used by the per-piece JIT as well as by the expression JIT
08:35 brrt my plan (for integration at least) is:
08:36 brrt for each basic block, first try to construct an expression
08:36 brrt if you can't construct an expression, construct a graph of per-opcode nodes (as before)
08:38 brrt well, if we'd have a table of conversions from opcode to function call, they can be added automatically to the expression
08:43 dalek MoarVM: f443ffd | FROGGS++ | src/io/procops.c:
08:43 dalek MoarVM: let libuv autoquote cmd line args on windows
08:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f443ffddb6
09:45 Ven joined #moarvm
10:00 Ven joined #moarvm
10:25 vendethiel joined #moarvm
11:06 brrt it's quite warm here
11:08 jnthn Only a little over 20 here :)
11:08 jnthn And yays, I now have my nice dev machine, keyboard, etc. set up :)
11:08 nwc10 and coffee?
11:08 JimmyZ cherry keyboard?
11:09 jnthn It's a split keyboard...I've had it for years...
11:09 jnthn And they don't make the same model any more.
11:09 nwc10 jnthn: you're aware of obra's new crazy keyboard? https://www.kickstarter.com/projects/keyboardio/the-model-01-an-heirloom-grade-keyboard-for-seriou
11:11 brrt wow
11:11 brrt even the way they've described it
11:11 brrt a heirloom keyboard
11:12 JimmyZ there is a  camelia on the keyboard ...
11:13 JimmyZ which is perl6-friendly ,hahah
11:13 brrt as if in 50 year's people will be using an USB plug for their keyboard
11:23 jnthn nwc10: Yeah, saw that one. :)
11:53 brrt errand &
12:07 vendethiel joined #moarvm
12:17 ggoebel joined #moarvm
12:25 flussence on the one hand, that looks like the sort of keyboard I've dreamed of having... on the other, that was before I became a prolific AltGr [ab]user :D
12:35 dalek MoarVM: a6330f7 | jnthn++ | src/math/bigintops.c:
12:35 dalek MoarVM: Add missing concreteness check on bigint ops.
12:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a6330f7dc1
12:37 jnthn And that was le SEGV
12:43 vendethiel joined #moarvm
13:27 vendethiel joined #moarvm
13:56 vendethiel joined #moarvm
13:59 JimmyZ_ joined #moarvm
14:21 Ven joined #moarvm
14:22 vendethiel joined #moarvm
14:35 FROGGS[mobile] joined #moarvm
15:54 timotimo i wonder if it's easy to figure out during a GC run whether or not a given jit code segment has an instruction pointer or a return address point at it from any of the threads
15:54 timotimo if it's simple-ish, maybe i'll go ahead and write a "merge small jit code segments into big jit code segments" thing; though i'm not sure if there are any absolute jumps in these code segments at all that need fixing up
15:55 * jnthn looks confusedly at timotimo's suggestion
15:56 timotimo i've talked about this a while back
15:57 timotimo due to having to make the jit code segments either writable or executable, we have to (potentially) waste a whole page on even the smallest pieces of bytecode we spit out
15:58 timotimo hm, though i remember now: the problem was that we had to also be able to free jit code segments
16:04 timotimo i suppose i'm just starting to feel a bit useless, what with not writing moarvm/rakudo code in a bit
16:04 timotimo so i may be jumping at straws :)
16:04 jnthn Yeah...there's probably more useful things to work at... :)
16:04 timotimo i think today i'll run a spectest and try out a few libraries to see if merge_facts_at_phi is good to be merged
16:05 * jnthn ponders whether to have dinner or do more pre-comp bughunt
16:06 jnthn Ah, let's do 30 mins more, maybe I'll find it... :)
16:07 timotimo got something simple-ish you'd like me to point my eyeballs & fingers at?
16:08 jnthn Well, I dunno how simple it'll be, but there's a spesh bug exposed in https://rt.perl.org/Ticket/Display.html?id=125408
16:14 JimmyZ_ timotimo: engineering a compiler is a nice book, maybe we can steal some ideas from there.
16:15 timotimo ah, yeah
16:15 timotimo i looked at the spesh log and it didn't seem suspicious :\
16:15 timotimo i'll take another look
16:15 Ven joined #moarvm
16:15 JimmyZ_ I saw many spesh idea from that book .
16:15 timotimo i'll try to reproduce it, that ought to help
16:17 * JimmyZ_ hopes jnthn++ will push his old ea branch, he wants to learn something from there too. 😊
16:22 dalek MoarVM: 017d184 | jnthn++ | src/6model/6model.h:
16:22 dalek MoarVM: Expose HOW accessors in API.
16:22 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/017d18404e
16:23 [Coke] .seen curisovidpoe
16:48 timotimo curtis*
16:49 timotimo alternatively: curious
17:19 FROGGS joined #moarvm
17:24 FROGGS nebuchadnezzar: hi, is it possible that the reproducable build fixes are not in yet?
17:25 FROGGS nebuchadnezzar: I'm just wondering because these two sites show different stats: https://tracker.debian.org/pkg/moarvm and https://packages.qa.debian.org/m/moarvm.html
18:09 ggoebel2 joined #moarvm
19:16 nebuchadnezzar FROGGS: yes, the fixes are not yet commited, + Arturo ask an experimental branch on latest git to check mips build
19:17 FROGGS ahh, okay
19:30 dalek joined #moarvm
19:32 TEttinger joined #moarvm
19:37 timotimo turns out i didn't actually attempt to reproduce that problem
19:37 timotimo instead, i read a webcomic, cooked and ate
19:43 jnthn Food is important too :)
19:58 masak as are webcomics
21:17 FROGGS_ joined #moarvm
23:38 vendethiel joined #moarvm
23:45 timotimo to be fair, if i want to find some hard to crack spesh failures :\
23:45 timotimo doesn't need to be the CArray thing
23:45 timotimo but it definitely helps that it's happened to a user rather than "just in theory if we make moar more aggressive"
23:45 timotimo agressive*

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