Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-07-30

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

All times shown according to UTC.

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

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