01:07 FROGGS_ joined 05:54 domidumont joined 05:59 domidumont joined 06:00 domidumont joined 06:23 ggoebel joined 10:42 brrt joined
brrt nine: i see no really good reason why we couldn't add a high-level interface to spesh/jit, other than memory lifetimes 10:43
i.e. we'd have to make spesh work with GC 10:44
or rwfcounting 10:45
*ref
and it'd be hugely sensitive and segfault often 10:46
and it's interface would be event-based... 10:47
alternatively, we could have just a high-level interface to the bytecode similar to cpython... 10:49
but the spesh object model is considerably more powerful
lizmat brrt: an event interface points to a Supply :-) 11:38
brrt hmmm 11:41
good point
on top of a more low-level interface i'd guess 11:45
my thesis is finished though, barring corrections 11:48
lizmat brrt++
brrt (finally...)
lizmat brrt++ # perseverance 11:49
brrt :-) thanks 11:50
jnthn Congrats, brrt :) 11:51
brrt :-)
now i don't quite know what to do with my free time... i don't have my laptop on me 11:53
actually having to relax :-o
mst what a bizarre concept 11:54
brrt wiki.luajit.org/JIT-Compiler-API - sort if what we could do 12:18
nwc10 what does the pain of implementing a high-level inteface buy us? (for some value of "us") 12:38
easier ability to write more sophisticated bytecode transforms?
(such as optimisers)
brrt hmmm... theoretically 12:39
difficult to say really 12:40
i dont know what folks use the luajit jit api for 12:41
i personally don't see it helping very soon 12:44
there seems to be substantial overlap between people who know how to implement specializations / optimizations and people who know c 12:46
on the other hand, there is democratization / bus factor reduction 12:52
eh increase
lizmat jnthn: I'm puzzled about some profile info 20:21
if one profile has about 10K allocations, and another profile has more than 10x as many allocations 20:22
how can the first profile (with 10K allocations) have more garbage collections than the second ? 20:23
timotimo 1) we might have forgotten to mark some operations as allocating
2) our heuristic for "was this actually allocated recently?" is faulty 20:24
3) ... ?? 20:25
lizmat ok 20:26
well, I find it strange :-)
what I profiled was: 'my @a = ^1000; for ^1000 { @a.min }'
with the current code, and the code I'm about to push 20:27
timotimo you made it allocate less, but gc more often?
lizmat yup
timotimo in general, the amount of GCing is definitely correct
because otherwise things would asplode
lizmat anyway, this fix makes .min / .max about 40% faster 20:28
and it makes %h.min(*.value) work
timotimo nice 20:29
lizmat just more GC's :-(
arnsholt Maybe it changes the sizes of the allocations? 20:31
Anyways, I'm off to bed 20:32
arnsholt zzz &
lizmat well, actually, the old code was not doing 10x as many allocations, but 100x as many
good night arnsholt
it does 1M IntLexRef allocations 20:33
timotimo does the other code allocate more than the previous one of anything else? 20:40
IntLexRef isn't very big, but it really depends on what you compare it to 20:44
lizmat nope, all lower numbers
the new code doesn't allocate any IntLexRefs at all 20:45
timotimo huh
lizmat anyways, I just pushed it: it spectests ok and it *is* faster with less CPU usage
timotimo i have code where .min (or is it .max?) is a big part of the innermost, hottest loop 20:46
lizmat well, that should be faster now :-)
timotimo it's a cellular automaton that takes into account each cell's 8 neighbours 20:47
but only the minimum (or maximum?) value of the neighbour cells is interesting
lizmat well, I hope it will be faster for you now :-)
(it should be :-) unless they were natives) 20:48
timotimo hm
might be natives, actually
lizmat actually, it looks like we don't have a dedicated .min/.max for native arrays ?
ok, that is easily fixed :-) 20:49
timotimo oh! 21:00
the reason why i don't have it as a native int array is because i "default to" Inf 21:01
um ... i don't seem to any more
so i guess i get ... something else
jnthn There are some things that are GC-allocated that aren't really tracked too well, including promoted call frames. 22:12
timotimo oh, that's a good point 22:21
jnthn And call frames are phat.
timotimo i wonder if that'd go into a totally different bucket from other allocated things 22:22