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 |