github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
jnthn We don't know which slots are the pair for a method cache 00:03
And we can't just ignore NULL ones because when we inline, the spesh slots are populated
Potentially with a method
timotimo ah, you mean when we've reconstructed the spesh graph from the candidate to build the inline
jnthn Right
timotimo yes, indeed
jnthn Again, solvable somehow
But maybe more effort than it's worth
timotimo similarly we lose all comments on the spesh graphs, but i'd rather not keep them around 00:04
jnthn Known deconted type is probably going away anyway at some point
timotimo though of course they'd only have to be stored if spesh logging is turned on
jnthn I can't remember why we still have it
It's not reliable data, in general
timotimo so we guard on it all the time anyway? 00:06
jnthn I hope so :)
The problem is that if the container is shared another thread could write to it
Debug name of known type would be very useful, though 00:07
timotimo that'd be easy to add
though the facts section is already pretty big and messy
jnthn :) 00:17
'night o/
timotimo night jnthn!
00:17 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke 00:18 MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
timotimo well, that was a simple patch 00:22
00:22 lizmat left
Geth MoarVM: a74af55855 | (Timo Paulssen)++ | src/spesh/dump.c
output known type's debugname in spesh log
 00:23
timotimo i wonder what the motivation is behind using bitand_i to combine $pos >= 0 and isconcrete($reified) 00:28
0.000760% jit 2,762,500 entries 00:55
MasterDuke m: say 2762500*.00076 00:56
camelia 2099.5
MasterDuke timotimo: github.com/rakudo/rakudo/commit/0baeec0223 00:59
01:00 lizmat joined, p6bannerbot sets mode: +v lizmat
timotimo is watching moarperf slooowly using more and more RES memory 01:06
MasterDuke as it's doing something? or just while idle? 01:07
timotimo no requests at least; perhaps the websocket connection is pinging or something 01:08
i see one of the processes waiting for a futex, then waking one, then calling mprotecd, then waiting with the futex again 01:11
one process is doing nanosleep and getrusage over and over again, i'd assume that's the supervisor thread for the thread pool scheduler 01:12
that one also calls futex with WAKE_PRIVATE
i closed the browser tab that was connected, looks like it's still growing, though. 01:14
yeah
MasterDuke think it's something that can be fixed? 01:15
timotimo well, i sure hope so :) 01:21
it felt faster than 1 megabyte per minute 01:22
i don't know how i can tell heaptrack to ignore the first 60 seconds or so
maybe version 1.1 has something for that, i'm still on 1.0 01:26
MasterDuke you can attach heaptrack to an already running process 01:27
timotimo oh 01:28
well, that would do it
this time it didn't keep growing 01:35
MasterDuke a watched pot never boils, a heaptracked process never grows 01:37
timotimo it did when i had it attached that other time 01:38
it was just not possible to figure out which of the parts of the stack was the one that was growing
attaching it to jjust "pidof moar" gave me a recording of 0.001s run time :\ 01:45
eh. bedtime. 01:46
gnite!
01:50 Kaiepi joined 01:51 p6bannerbot sets mode: +v Kaiepi 02:20 MasterDuke left 03:51 ggoebel left 04:07 ggoebel joined, p6bannerbot sets mode: +v ggoebel 05:00 ItchyPlant joined 05:01 p6bannerbot sets mode: +v ItchyPlant 06:23 ItchyPlant left 07:03 domidumont joined 07:04 p6bannerbot sets mode: +v domidumont 09:26 zakharyas joined 09:27 p6bannerbot sets mode: +v zakharyas 09:28 zakharyas left 09:29 zakharyas joined 09:30 p6bannerbot sets mode: +v zakharyas 11:28 evalable6 left, evalable6 joined 11:29 p6bannerbot sets mode: +v evalable6 12:04 zakharyas left 12:21 brrt joined 12:22 p6bannerbot sets mode: +v brrt
brrt \o 12:23
.tell lizmat if apple releases a laptop with an A12/A14 chip, that's finally going to be a good reason for me to buy an apple laptop ;-)
yoleaux brrt: I'll pass your message to lizmat.
brrt A64 ISA seems like a fun challenge 12:24
nine 10.957s! That's 200ms better than the best value I got from master so far 12:39
Followed by 10.911 :)
brrt nine++ progress 12:42
jnthn Cool! :) 13:20
13:33 dogbert17 joined 13:34 p6bannerbot sets mode: +v dogbert17 14:00 zakharyas joined 14:01 p6bannerbot sets mode: +v zakharyas 14:37 lizmat left 14:51 domidumont left 15:57 lizmat joined, p6bannerbot sets mode: +v lizmat 16:04 robertle left 16:14 brrt left 16:20 brrt joined 16:21 p6bannerbot sets mode: +v brrt 16:31 robertle joined, p6bannerbot sets mode: +v robertle 16:37 zakharyas left 17:04 avar left, avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 17:05 p6bannerbot sets mode: +v avar
timotimo oooh fabulous 17:31
i'm still looking for a good solution for identifying specific functions from the core setting when loading a profile 17:45
since line numbers always change, and there's multi subs and methods with multiple candidates in one file that might be different enough that we want to tell them apart 17:46
the iterators file is especially bad at this, there's hundreds of push-all and pull-one and such in there
one example for "intelligence" would be to see that a user function indirectly calls Bridge on, for instance, Int or Rat 17:47
and that could be pointed out like "perhaps you can use Num earlier in this computation"
imagine code like if $foo < 5 { ... } that would convert 5 to num over and over again without need 17:48
brrt how is that not the job of the optimizer :-)
timotimo hmm.
i'll keep this idea on the drawing board for a bit 17:49
i'm thinking the profiler should offer (or even default) to combine all threads from one thread pool into a single tree
17:52 domidumont joined 17:53 p6bannerbot sets mode: +v domidumont 18:09 brrt left 18:38 patrickb joined 18:39 p6bannerbot sets mode: +v patrickb 18:52 patrickb left 18:54 fake_space_whale left
japhb brrt: Intelligence in depth. It's useful to work to have a good optimizer (and spesh and jit) *and* to detect cases where the optimizer (or spesh or jit) missed out *and* to determine cases where the user is doing something fundamentally difficult to optimize. 19:35
Sortof the same reason at the C level we have all of compiler warnings, valgrind, and *san tools. 19:36
20:04 domidumont left 20:08 domidumont joined 20:09 p6bannerbot sets mode: +v domidumont, domidumont left 20:28 patrickb joined, p6bannerbot sets mode: +v patrickb 20:52 patrickb left 21:04 lizmat left 22:12 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 22:22 lizmat joined, p6bannerbot sets mode: +v lizmat

Powered by Cro and the Raku® Programming Language.

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

Thank you!