Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-05-16

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

All times shown according to UTC.

Time Nick Message
01:00 cognominal joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
01:50 zakharyas joined #moarvm
06:42 domidumont joined #moarvm
06:48 domidumont joined #moarvm
10:40 JimmyZ jnthn: I found when compiling rakudo, it never write any sc and sc_idx in serialize_object and write_locate_sc_and_index, when will it write it?
10:45 jnthn JimmyZ: Maybe you're looking for write_obj_ref?
10:48 JimmyZ jnthn: nope, it only write "packed", because sc_id <= PACKED_SC_MAX && idx <= PACKED_SC_IDX_MAX never be false
10:48 JimmyZ jnthn: and same for serialize_object
10:49 JimmyZ jnthn: sc <= OBJECTS_TABLE_ENTRY_SC_MAX && sc_idx <= OBJECTS_TABLE_ENTRY_SC_IDX_MAX never be false too.
10:49 jnthn OK, then I'm not understanding what you're looking for
10:50 JimmyZ jnthn: I am looking for when it will be true and write sc_id and idx
10:51 nwc10 (will be AFK very shortly)
10:51 nwc10 I think that nothing we generate is big enough to need to write a full sc_id and idx
10:51 jnthn Yeah, that's the conclusion I was coming to looking at the code
10:52 jnthn We didn't hit that limit yet
10:52 nwc10 but the packed format is (to my mind) too small to be safe
10:52 nwc10 someone is going to generate code that busts it
10:52 brrt joined #moarvm
10:52 JimmyZ ok, thanks.
10:53 brrt good * #moarvm
10:53 brrt jnthn: did you manage to read the webkit b3 post yet?
10:53 jnthn brrt: No...was exhausted :(
10:53 brrt no pressure :-)
10:53 * jnthn goes to nom, bbiab :)
10:54 brrt nom well :-)
10:59 * brrt will nom too
12:45 domidumont joined #moarvm
13:36 cognominal joined #moarvm
14:39 zakharyas joined #moarvm
15:21 domidumont joined #moarvm
17:19 * jnthn will probably get time to look at the heap profiler regression thingy tomorrow :)
17:20 timotimo yays
17:46 domidumont joined #moarvm
19:10 brrt joined #moarvm
19:10 brrt \o
19:12 brrt anyone else who did read the b3 thing possibly had the impression that b3 looks a lot like the expr jit?
19:13 nwc10 I don't know enough to answer that.
19:13 nwc10 For starters, I don't know what "the expr jit" is. Certainly not in this context.
19:14 brrt its the even-moar-jit branch :-)
19:14 nwc10 (I did read it, and thought "oh, more evidence that not using LLVM was probably the right choice)
19:14 nwc10 aha OK
19:14 brrt aye that too..
19:16 brrt well they are alike in a few aspects: both use 2 intermediaye representation with very similar functions
19:17 timotimo to be honest i didn't read the b3 article :S
19:17 brrt there is a similar conversion step between these
19:18 timotimo like the tiling step?
19:18 brrt they also use arrays and offsets rather than pointers in the ir
19:18 brrt yes
19:21 brrt so the good thing is, this pretty much validates our approach
19:21 jnthn Great minds think alike
19:22 jnthn .oO( All fools are the same :P )
19:22 brrt the curious thing is how distinct teams witbout  plausible flows of information can have such a convergent design
19:22 brrt :-p
19:24 brrt thw not so good thing..... if well-funded webkit can't get llvm to perform in a JIT setting, then who can?
19:25 brrt i mean, llvm is by rights awesome
19:25 jnthn I think that's part of the problem.
19:25 brrt hmmm... wh
19:25 jnthn "X is awesome at generating fast code." "Hmm, so let's use X in Y to make it awesome!"
19:25 hoelzro that b3 article is *long*
19:25 brrt y?
19:26 brrt it is :-)
19:26 hoelzro I got like halfway through it before filing it into "read later"
19:26 jnthn It's not obvious that just 'cus something does great code-gen in one scenario means it will be a good fit in another scenario.
19:27 jnthn Optimization algorithms take time, but the time budget is quite difference in a C/C++ compiler vs. a JIT compiler.
19:27 jnthn *different
19:28 jnthn And designing abstractions is Really Hard normally; designing ones that hold up in scenarios where one is trying to sqeeze out performance is crazy hard.
19:29 brrt from what i understand, part of the problem is also that concepts like deopt guards become multi-basivblock things in llvm
19:29 brrt high-level dynamic language concepts dont fit easily
19:30 jnthn Yeah, that seems to be the recurring pattern.
19:30 jnthn It's also quite natural to go back and patch up generated machine code in various ways in dynamic language VMs.
19:31 jnthn Which I believe can also be tricky to get right.
19:31 brrt not what we do in moar-jit though
19:32 brrt what would we use it for?
19:35 jnthn Can have evolving dispatch fast-paths for example
19:36 jnthn The CLR does one of those for interface dispatches...checks if the type is a commonly occuring one, if yes then there's a fast path, otherwise it calls back to a full dispatch and bumps a counter
19:36 jnthn If the slow path counter hits a certain value it patches the machine code up with whatever seems to be the in fashion thing to dispatch to now :)
19:37 jnthn So interface calls that usually dispatch to one concrete type, but sometimes might change that type with time, will hit the fast path
19:38 jnthn A kind of monomorphic inline cache I guess
19:39 brrt ... right... self-modifying sp-fastinvoke
19:40 brrt hey we could do that easier.... no
19:40 brrt cool idea though
19:40 jnthn I guess also in trace JITs it could be used to modify an interpreter fallback to instead jump directly into a side-trace that gets compiled later.
19:40 timotimo we'll get those inline caches
19:41 timotimo yeah, pypy has had that for ages, they call it "bridge" and they compile those brigdes, too
19:41 timotimo someone on reddit (or something?) recently called moar's runloop bad. i wonder how they meant it, and in what way we could improve it
19:41 timotimo but i couldn't find the post again :\
19:42 brrt i think luajit2 compiles them too
19:42 brrt the runloop? i honestly dont see what that might mean
19:42 timotimo we could have used C as an intermediate representation and embed the tiny c compiler (tcc) within moarvm :P
19:42 timotimo i think it's just interp.c
19:43 jnthn Could mean the interpreter, but we already do computed goto where possible, and I'm not sure I want the maint headache of doing it in assembly :)
19:43 timotimo i thought you couldn't do very much better than computed goto
19:45 brrt doesmt make any sense to make it in assembler; the majority of our ops is a function call with maybe
19:45 jnthn There'll be ways to suqeeze a little more out, but I'm quite sure we've got a lot of easier performance wins to be had before that.
19:45 brrt a few branches
19:45 timotimo yeah, by making spesh and the jit better
19:45 jnthn brrt: It makes even less sense when the C compiler is inlining a bunch of those functions :)
19:46 brrt right :-)
19:46 brrt by making rakudo smartet :-p
19:47 timotimo yeah, that's also worthwhile
19:47 jnthn But yeah, people saying "X is bad" isn't very interesting unless they actually proposing a concrete alternative they believe to be better. :)
19:47 timotimo worth alot
19:47 jnthn I like this alot
19:47 jnthn :P
19:48 brrt its alot work to make vms fast
19:50 brrt rigbt... battery is running out though
19:51 timotimo i hope our vm will be alot fast soon
19:53 timotimo i wonder if i should do fuzzing again?
19:53 timotimo with a newer moar and probably not the whole stage0
19:53 timotimo (because some files in there are just way too f'ing big)
19:54 * brrt off
19:57 timotimo oh, jnthn, maybe you have a bit of brane to spare to look at my generate_buildallplan branch and see what i'm doing wrong there?
19:57 timotimo if i get that to work i can perhaps even take a closer look at how we could improve codegen for nativecall
20:09 Ven joined #moarvm
20:14 jnthn timotimo: May find time for that soon, now reframe is done eating the brane cycles... :)
20:15 moritz has reframe been merged?
20:15 jnthn Not tonight though...didn't sleep enough last night, then various meetings today
20:15 jnthn moritz: Yes
20:15 jnthn Last week.
20:15 moritz \o/
20:16 * moritz quite out of the loop
20:16 moritz are there any benchmarks or memory comparisons available that compare before and after the merge?
20:17 jnthn moritz: Not yet, and the work so far was more the big refactor to enable the other improvements.
20:18 jnthn moritz: So was going to do the before/after once I've got the rest of the improvemnets, or at least more of them, in place. :)
20:26 timotimo i don't think we actually have memory savings, do we?
20:27 timotimo or even potential for that? i'm not sure
20:27 timotimo cat says "021snkh"

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