02:25 FROGGS_ joined 02:49 ilbot3 joined 04:40 cognominal joined 04:44 vendethiel joined 09:21 rurban_ joined 11:55 vendethiel joined
dalek Heuristic branch merge: pushed 80 commits to MoarVM/even-moar-jit by bdw 12:58
konobi ullo all 13:10
how goes the illumos stuffz? 13:11
14:03 brrt joined
brrt ohai konobi 14:03
hasn't gotten much work so far, sorry about that 14:04
my suggested fix is that we somehow configure two different backends, namely
illumos/solaris+gcc and illumos/solaris+sunstudio 14:05
the sunstudio bits, they should probably work with the c99 compiler?
at any rate, as far as i care, only minilua would link with /usr/lib/values-xpg6.o
i was using dilos, but,... well... it's rough going 14:06
it's a one-man effort and while said one main is highly capable, the full OS isn't really stable
i've had worse luck with other OS-es
smartos, especially, i can't get that to work as a 'regular' os 14:07
i kind of have the feeling that is your main interest?
konobi brrt: yup... you can use -std= 14:13
brrt actually, that doens't work for gcc
or, not for the gcc i had installed
i kind of have the feeling gcc-on-illumos is in flux at this point?
konobi brrt: yeah, i'm part of the illumos community and I hadn't heard of it in years 14:14
brrt hmmpf
konobi brrt: yeah, I'm a SmartOS user
user/developer
brrt: illumos is only built with gcc these days
brrt hmm really 14:15
konobi yeah... the sunstudio dependency is purely for the linting tools... all the building is done by gcc
brrt here's what we can do, as far as i'm concerned
i can get a vm, or a walkthrough-onto-a-vm, or an ssh-into-a-vm, of your reference system, and i can try to make it work on that 14:16
konobi sure... lemme spin up a zone
brrt that would be awesome
i cannot spend $large-amounts-of-tuits on getting this to run, because i don't have them, and there are larger, higher-priority things (for me) to do 14:17
14:18 vendethiel- joined
timotimo even-more-jit please 14:18
not saying i don't care about illumos
i mean ... people can use moar even when even-moar-jit doesn't land yet, whereas people on illumos can't use moar at all yet 14:19
brrt aye, that is true
although i must say that illumos is fun :-) 14:21
konobi brrt: can you gist me your public key?
brrt aye, coming up 14:22
konobi timotimo: illumos has some tooling that make it great for performing analysis/testing/debugging moarvm
timotimo why didn't you say so immediately? :) 14:23
it has DTrace or ktap or something?
brrt timotimo: i agree, illumos looks awesome on the face of it 14:27
it's just.... probably better for people who know solaris 14:28
konobi timotimo: dtrace, mdb, libumem, kstat and more! 14:35
timotimo brrt: would it take you an alot of time to write the jit code for truncate/extend, switch between signed/unsigned and such things? 14:43
brrt no
timotimo it wouldn't come up in code often
brrt that would take very small amounts of time, actually
timotimo like, rakudo itself doesn't use that, ever
brrt truncate is especially simple; it's just 'use this thing as a smaller thing' 14:44
timotimo want me to prepare the graph.c stuff for you and entries into the switch statement?
brrt on x86
oh, you mean for the current jit
timotimo yes
sorry about that :)
brrt better idea
make a testcase
timotimo but i don't even know! :D 14:45
14:45 pmurias joined
timotimo damn. hitting those slow path binder code paths really takes a toll on allocations done 14:46
pmurias what is div_u used for?
timotimo divides two unsigned 64bit ints and stores the result as an unsigned 64bit int 14:47
um ... 14:49
either i did the build wrong
or i really am at fault for this
but ... how the hell? 14:50
konobi timotimo: here's a good example: blog.8thlight.com/colin-jones/2015...-slow.html
timotimo could it be the jit implementation of some method-related function is absolutely wrong?
ah, that one 14:51
i read that :)
brrt method related function?
timotimo well, yeah
here's what i mean:
527713 calls to "<anon> gen/moar/m-BOOTSTRAP.nqp:2048"
that's with my "my jit advancements cut out" branch
1882385 calls to that very same function 14:52
that's without the branch
hm, actually i think that's on latest moar master
brrt that... would be weird
timotimo that routine goes from 38.3% inclusive time, 14.55% exclusive time
to 72%/62.5%
switches places with "bind_one_param", which was 1st in one case and 2nd in the other 14:53
brrt huh
timotimo that's method find_best_dispatchee
the anon one
pmurias timotimo: what I'm really asking for what uses div_u 14:54
timotimo the call graph also doesn't show that anon routine at all, so i can't tell who/what is causing it to call
pmurias * is what
timotimo pmurias: no clue :)
would there be any reason our jitted code wouldn't hit the multi cache? just in general, i mean? 14:55
brrt hmmpf 14:56
no, i wouldn't say it at first
i'm going to have to be off for a bit 14:57
see you later
timotimo mhh, ok
see ya!
thing is... i've seen calls to find_best_dispatchee in the past where i had no idea where they came from 15:07
my recent commits cause more frames to be jitted, and the calls to find_best_dispatchee skyrocket
disabling the jit entirely also causes the speed to go back to "blazing fast" when enabling it has them at "slowed to a crawl" 15:08
oh, huh. weird! 15:13
disabling the jit and running the profile gives me 527713 calls to <anon> and 1852719 calls to bind_one_param
that's the exact same amount i get with my commits reverted
15:20 patrickz joined 15:21 zakharyas joined
timotimo so that's not because of the jit. but why then? 15:23
patrickz .tell mst That strange function rakudobrew injects into the shell is there to allow rakudobrew to modify an environment variable in the current shell (needed for the "shell" subcommand). It's a direct rip off of plenv. If you don't use that feature you don't need that function. 15:24
timotimo these 527k and 1.8m calls are also there when spesh is disabled 15:25
so that's not the right place to look ... huh.
konobi wonder what the cache strategy is for hotpathing 15:26
jnthn timotimo: Do we jit the find multi cache ops? 15:30
Could their jit be busted?
dalek arVM: bd56e2e | timotimo++ | src/ (4 files):
Work around performance regression in the jit.

Something causes a gigantic amount of calls to find_best_dispatchee.
Until the cause for that is properly investigated and fixed, 2ce4b7a | cygx++ | src/io/syncfile.c: fix typo in error message		 15:32
timotimo we do. i looked over them, but they don't seem busted
15:33 dalek joined
timotimo i'd like to bump NQP and MOAR revision to this so that our users get better performance for the time being 15:33
+1/-1?
jnthn +1 15:34
timotimo good
jnthn It's also possible that invocation isn't checking the multi cache properly.
patrickz wrong channel... 15:36
timotimo so invoke_* on a proto method/sub?
emit_invoke also calls into MVM_frame_find_invokee_multi_ok 15:39
jnthn Hm
Yeah, that'd be the place
Very odd
But yes, let's revert and bump for now and diagnose later 15:40
timotimo revert & bump is done
and the jit also knows about fastinvoke sufficiently well it seems 15:42
jnthn Yeah 15:43
I didn't "prove" the multi dispatch cache miss is the problem conclusively, fwiw, I just observed that we ended up slow-pathing a lot
It's possible it's something else going wrong that creates that effect
timotimo "a lot" is an understatement
jnthn Well, Perl 6 is built around multi-dispatch 15:44
timotimo the profile definitely shows a vast amount of time is spent inside find_best_dispatchee
jnthn And good performance relies a lot on finding ways to cheat on that
timotimo gist.github.com/smls/9adf4b6707938445c050 - i was running this for profiling
jnthn So yeah, it's perhaps the most painful optimization you could break, aside from method caching.
timotimo spending 62.5% exclusive time in find_best_dispatchee is *tough* 15:45
konobi jnthn: tried using ARC?
jnthn Right. That's how much we rely on it.
timotimo oh, btw, i'd like to put the size of an allocated thing into the profile, too. sounds sensible?
jnthn konobi: Don't think I've even *used* a language that does that, let alone implemented one. :)
timotimo for that purpose, perhaps a flag "mallocs some extra data" might be interesting 15:46
i don't know what ARC is ... only know "arc flags" for making path finding faster
jnthn I suspect Automatic Reference Counting
timotimo oh
jnthn The thing that Swift/Objective C do
To handwave a bit, "do static analysis to work out where the calls to free go" 15:47
Guess it's highly related to escape analysis.
timotimo we're hoping to get escape analysis at one point, anyway
perhaps that'll be enough for our purposes? 15:48
jnthn My impression is using ARC is more a language design decision
Escape analysis is just an analysis, so can apply to either...it's what you do with the escape information that's the exciting thing :) 15:49
konobi jnthn: nope... adaptive replacement cache 15:50
timotimo ah, fair enough
jnthn (size of allocated thing) can work, but arrays/hashes resize over time...
konobi: Dammit, too many acronyms :P
timotimo yeah. that's what the flag is for. i'd've only tracked object header + object body and maybe have a little star saying "this object does its own mallocing"
jnthn konobi: Also makes more sense in context :) 15:51
timotimo hehe
jnthn But no...and doing so would need some consideration of concurrency
Since we need at least queries of the cache to take place lock free 15:52
timotimo also, i thought we'd be using escape analysis to put allocation of some things onto "the stack" instead of in our fully gc-managed heap
konobi that should be fine
jnthn And that's easy to achieve with an append-only cache.
Yeah, I think it's possible to engineer.
But we should actually meausre if we can get a win out of it first.
As in, whether full caches are common 15:53
konobi or at least that it does no worse =0)
timotimo today is headache-day ... it's not getting better :S 15:54
jnthn No, it'd actually have to do notably better
As a general Moar architectural principle, anything that increases code complexity has to pull its weight.
timotimo "time spent on designing and implementing" is a big cost for us
konobi jnthn: java.net/projects/solaris/sources/...?rev=13149 15:55
that's probably a good start... heavily commented =0)
jnthn Yes, thanks 15:56
And obviously more involved than what we have now :)
geekosaur um? which ARC are we talking about here?
jnthn Well, we've been through two of them so far :) 15:57
Niether is arc welding...
geekosaur zfs's arc is an adaptive filesystem cache. there are some similarities but not much
jnthn en.wikipedia.org/wiki/Adaptive_rep...ment_cache anyway
geekosaur (if you;re thinking of e.g. apple's automatic refcounting)
16:14 Ven joined 16:51 vendethiel joined 17:42 Ven joined 18:11 vendethiel joined 18:56 virtualsue joined 20:47 virtualsue joined
diakopter I still have to disable jit to build nqp on latest msvc 21:51
jnthn diakopter: Did you figure out why at all? I have a hazy memory of some 32-bit/64-bit confusion... 22:03
diakopter jnthn: it was misconfusion 22:08
it's 64-bit for sure
konobi oh... yet more ridiculousness... copy.sh/v86/ 22:19
TimToady m: say EVAL "42" 23:11
camelia rakudo-moar e8d924: OUTPUT«42␤»
TimToady m: say EVAL 42
camelia rakudo-moar e8d924: OUTPUT«===SORRY!=== Error while compiling /tmp/5VGxLhs_KO␤EVAL is a very dangerous function!!! (use MONKEY-SEE-NO-EVAL to override,␤but only if you're VERY sure your data contains no injection attacks)␤at /tmp/5VGxLhs_KO:1␤------> say EVAL 42⏏…»
TimToady m: use Test; say EVAL 42 23:12
camelia rakudo-moar e8d924: OUTPUT«===SORRY!=== Error while compiling /home/camelia/rakudo-m-inst-2/share/perl6/sources/5A873B6C22E600D8BE41B8846C251CD7D914CFE3␤EVAL is a very dangerous function!!! (use MONKEY-SEE-NO-EVAL to override,␤but only if you're VERY sure your data contain…»
jnthn Does it really need 3 !s? :)
Also probably wants a re-word for the literal thing
23:17 rurban_ joined
arVM: 9a79010 | lizmat++ | src/io/syncfile.c:
Merge pull request #317 from cygx/patch-1

fix typo in error message
lizmat m: 42.EVAL
camelia rakudo-moar e8d924: OUTPUT«Unhandled exception: While looking for '/home/camelia/rakudo-m-inst-2/share/perl6/runtime/perl6.moarvm': no such file or directory␤»
lizmat m: 42 23:22
camelia rakudo-moar e8d924: OUTPUT«Unhandled exception: While looking for '/home/camelia/rakudo-m-inst-2/share/perl6/runtime/perl6.moarvm': no such file or directory␤»
lizmat Ah, I guess something got nuked and it's now rebuilding ?
TimToady yes, but waiting for jvm build to finish, or we run out of mem 23:24
diakopter no swap? 23:29
TimToady m: use Test; say EVAL 42 23:31
camelia rakudo-moar af5b39: OUTPUT«42␤»

Powered by Cro and the Raku® Programming Language.

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

Thank you!