|
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 | |