01:00 cognominal joined 01:48 ilbot3 joined 01:50 zakharyas joined 06:42 domidumont joined 06:48 domidumont joined
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:40
jnthn JimmyZ: Maybe you're looking for write_obj_ref? 10:45
JimmyZ jnthn: nope, it only write "packed", because sc_id <= PACKED_SC_MAX && idx <= PACKED_SC_IDX_MAX never be false 10:48
jnthn: and same for serialize_object
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
JimmyZ jnthn: I am looking for when it will be true and write sc_id and idx 10:50
nwc10 (will be AFK very shortly) 10:51
I think that nothing we generate is big enough to need to write a full sc_id and idx
jnthn Yeah, that's the conclusion I was coming to looking at the code
We didn't hit that limit yet 10:52
nwc10 but the packed format is (to my mind) too small to be safe
someone is going to generate code that busts it
10:52 brrt joined
JimmyZ ok, thanks. 10:52
brrt good * #moarvm 10:53
jnthn: did you manage to read the webkit b3 post yet?
jnthn brrt: No...was exhausted :(
brrt no pressure :-)
jnthn goes to nom, bbiab :)
brrt nom well :-) 10:54
brrt will nom too 10:59
12:45 domidumont joined 13:36 cognominal joined 14:39 zakharyas joined 15:21 domidumont joined
jnthn will probably get time to look at the heap profiler regression thingy tomorrow :) 17:19
timotimo yays 17:20
17:46 domidumont joined 19:10 brrt joined
brrt \o 19:10
anyone else who did read the b3 thing possibly had the impression that b3 looks a lot like the expr jit? 19:12
nwc10 I don't know enough to answer that. 19:13
For starters, I don't know what "the expr jit" is. Certainly not in this context.
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)
aha OK
brrt aye that too..
well they are alike in a few aspects: both use 2 intermediaye representation with very similar functions 19:16
timotimo to be honest i didn't read the b3 article :S 19:17
brrt there is a similar conversion step between these
timotimo like the tiling step? 19:18
brrt they also use arrays and offsets rather than pointers in the ir
yes
so the good thing is, this pretty much validates our approach 19:21
jnthn Great minds think alike
.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
:-p
thw not so good thing..... if well-funded webkit can't get llvm to perform in a JIT setting, then who can? 19:24
i mean, llvm is by rights awesome 19:25
jnthn I think that's part of the problem.
brrt hmmm... wh
jnthn "X is awesome at generating fast code." "Hmm, so let's use X in Y to make it awesome!"
hoelzro that b3 article is *long*
brrt y?
it is :-) 19:26
hoelzro I got like halfway through it before filing it into "read later"
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.
Optimization algorithms take time, but the time budget is quite difference in a C/C++ compiler vs. a JIT compiler. 19:27
*different
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:28
brrt from what i understand, part of the problem is also that concepts like deopt guards become multi-basivblock things in llvm 19:29
high-level dynamic language concepts dont fit easily
jnthn Yeah, that seems to be the recurring pattern. 19:30
It's also quite natural to go back and patch up generated machine code in various ways in dynamic language VMs.
Which I believe can also be tricky to get right. 19:31
brrt not what we do in moar-jit though
what would we use it for? 19:32
jnthn Can have evolving dispatch fast-paths for example 19:35
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
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 :)
So interface calls that usually dispatch to one concrete type, but sometimes might change that type with time, will hit the fast path 19:37
A kind of monomorphic inline cache I guess 19:38
brrt ... right... self-modifying sp-fastinvoke 19:39
hey we could do that easier.... no 19:40
cool idea though
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.
timotimo we'll get those inline caches
yeah, pypy has had that for ages, they call it "bridge" and they compile those brigdes, too 19:41
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
but i couldn't find the post again :\
brrt i think luajit2 compiles them too 19:42
the runloop? i honestly dont see what that might mean
timotimo we could have used C as an intermediate representation and embed the tiny c compiler (tcc) within moarvm :P
i think it's just interp.c
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
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.
brrt a few branches
timotimo yeah, by making spesh and the jit better
jnthn brrt: It makes even less sense when the C compiler is inlining a bunch of those functions :)
brrt right :-) 19:46
by making rakudo smartet :-p
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. :)
timotimo worth alot
jnthn I like this alot
:P
brrt its alot work to make vms fast 19:48
rigbt... battery is running out though 19:50
timotimo i hope our vm will be alot fast soon 19:51
i wonder if i should do fuzzing again? 19:53
with a newer moar and probably not the whole stage0
(because some files in there are just way too f'ing big)
brrt off 19:54
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
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
jnthn timotimo: May find time for that soon, now reframe is done eating the brane cycles... :) 20:14
moritz has reframe been merged? 20:15
jnthn Not tonight though...didn't sleep enough last night, then various meetings today
moritz: Yes
Last week.
moritz \o/
moritz quite out of the loop 20:16
are there any benchmarks or memory comparisons available that compare before and after the merge?
jnthn moritz: Not yet, and the work so far was more the big refactor to enable the other improvements. 20:17
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:18
timotimo i don't think we actually have memory savings, do we? 20:26
or even potential for that? i'm not sure 20:27
cat says "021snkh"

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!