Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-12-20

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

All times shown according to UTC.

Time Nick Message
02:25 FROGGS_ joined #moarvm
02:49 ilbot3 joined #moarvm
02:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:40 cognominal joined #moarvm
04:44 vendethiel joined #moarvm
09:21 rurban_ joined #moarvm
11:55 vendethiel joined #moarvm
12:58 dalek Heuristic branch merge: pushed 80 commits to MoarVM/even-moar-jit by bdw
13:10 konobi ullo all
13:11 konobi how goes the illumos stuffz?
14:03 brrt joined #moarvm
14:03 brrt ohai konobi
14:04 brrt hasn't gotten much work so far, sorry about that
14:04 brrt my suggested fix is that we somehow configure two different backends, namely
14:05 brrt illumos/solaris+gcc and illumos/solaris+sunstudio
14:05 brrt the sunstudio bits, they should probably work with the c99 compiler?
14:05 brrt at any rate, as far as i care, only minilua would link with /usr/lib/values-xpg6.o
14:06 brrt i was using dilos, but,... well... it's rough going
14:06 brrt it's a one-man effort and while said one main is highly capable, the full OS isn't really stable
14:06 brrt i've had worse luck with other OS-es
14:07 brrt smartos, especially, i can't get that to work as a 'regular' os
14:07 brrt i kind of have the feeling that is your main interest?
14:13 konobi brrt: yup... you can use -std=
14:13 brrt actually, that doens't work for gcc
14:13 brrt or, not for the gcc i had installed
14:13 brrt i kind of have the feeling gcc-on-illumos is in flux at this point?
14:14 konobi brrt: yeah, i'm part of the illumos community and I hadn't heard of it in years
14:14 brrt hmmpf
14:14 konobi brrt: yeah, I'm a SmartOS user
14:14 konobi user/developer
14:14 konobi brrt: illumos is only built with gcc these days
14:15 brrt hmm really
14:15 konobi yeah... the sunstudio dependency is purely for the linting tools... all the building is done by gcc
14:15 brrt here's what we can do, as far as i'm concerned
14:16 brrt 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
14:16 brrt that would be awesome
14:17 brrt 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:18 vendethiel- joined #moarvm
14:18 timotimo even-more-jit please
14:18 timotimo not saying i don't care about illumos
14:19 timotimo 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
14:21 brrt although i must say that illumos is fun :-)
14:21 konobi brrt: can you gist me your public key?
14:22 brrt aye, coming up
14:22 konobi timotimo: illumos has some tooling that make it great for performing analysis/testing/debugging moarvm
14:23 timotimo why didn't you say so immediately? :)
14:23 timotimo it has DTrace or ktap or something?
14:27 brrt timotimo: i agree, illumos looks awesome on the face of it
14:28 brrt it's just.... probably better for people who know solaris
14:35 konobi timotimo: dtrace, mdb, libumem, kstat and more!
14:43 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
14:43 timotimo it wouldn't come up in code often
14:43 brrt that would take very small amounts of time, actually
14:43 timotimo like, rakudo itself doesn't use that, ever
14:44 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?
14:44 brrt on x86
14:44 brrt oh, you mean for the current jit
14:44 timotimo yes
14:44 timotimo sorry about that :)
14:44 brrt better idea
14:44 brrt make a testcase
14:45 timotimo but i don't even know! :D
14:45 pmurias joined #moarvm
14:46 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?
14:47 timotimo divides two unsigned 64bit ints and stores the result as an unsigned 64bit int
14:49 timotimo um ...
14:49 timotimo either i did the build wrong
14:49 timotimo or i really am at fault for this
14:50 timotimo but ... how the hell?
14:50 konobi timotimo: here's a good example: https://blog.8thlight.com/colin-jones/2015/12/01/ask-dtrace-why-are-my-tests-so-slow.html
14:50 timotimo could it be the jit implementation of some method-related function is absolutely wrong?
14:51 timotimo ah, that one
14:51 timotimo i read that :)
14:51 brrt method related function?
14:51 timotimo well, yeah
14:51 timotimo here's what i mean:
14:51 timotimo 527713 calls to "<anon> gen/moar/m-BOOTSTRAP.nqp:2048"
14:51 timotimo that's with my "my jit advancements cut out" branch
14:52 timotimo 1882385 calls to that very same function
14:52 timotimo that's without the branch
14:52 timotimo hm, actually i think that's on latest moar master
14:52 brrt that... would be weird
14:52 timotimo that routine goes from 38.3% inclusive time, 14.55% exclusive time
14:52 timotimo to 72%/62.5%
14:53 timotimo switches places with "bind_one_param", which was 1st in one case and 2nd in the other
14:53 brrt huh
14:53 timotimo that's method find_best_dispatchee
14:53 timotimo the anon one
14:54 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
14:54 pmurias * is what
14:54 timotimo pmurias: no clue :)
14:55 timotimo would there be any reason our jitted code wouldn't hit the multi cache? just in general, i mean?
14:56 brrt hmmpf
14:56 brrt no, i wouldn't say it at first
14:57 brrt i'm going to have to be off for a bit
14:57 brrt see you later
14:57 timotimo mhh, ok
14:57 timotimo see ya!
15:07 timotimo thing is... i've seen calls to find_best_dispatchee in the past where i had no idea where they came from
15:07 timotimo my recent commits cause more frames to be jitted, and the calls to find_best_dispatchee skyrocket
15:08 timotimo 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:13 timotimo oh, huh. weird!
15:13 timotimo disabling the jit and running the profile gives me 527713 calls to <anon> and 1852719 calls to bind_one_param
15:13 timotimo that's the exact same amount i get with my commits reverted
15:20 patrickz joined #moarvm
15:21 zakharyas joined #moarvm
15:23 timotimo so that's not because of the jit. but why then?
15:24 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:25 timotimo these 527k and 1.8m calls are also there when spesh is disabled
15:25 timotimo so that's not the right place to look ... huh.
15:26 konobi wonder what the cache strategy is for hotpathing
15:30 jnthn timotimo: Do we jit the find multi cache ops?
15:30 jnthn Could their jit be busted?
15:32 dalek MoarVM: bd56e2e | timotimo++ | src/ (4 files):
15:32 dalek MoarVM: Work around performance regression in the jit.
15:32 dalek MoarVM:
15:32 dalek MoarVM: Something causes a gigantic amount of calls to find_best_dispatchee.
15:32 dalek MoarVM:
15:32 dalek MoarVM: Until the cause for that is properly investigated and fixed,
15:32 timotimo we do. i looked over them, but they don't seem busted
15:33 dalek joined #moarvm
15:33 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 timotimo +1/-1?
15:34 jnthn +1
15:34 timotimo good
15:34 jnthn It's also possible that invocation isn't checking the multi cache properly.
15:36 patrickz wrong channel...
15:36 timotimo so invoke_* on a proto method/sub?
15:39 timotimo emit_invoke also calls into MVM_frame_find_invokee_multi_ok
15:39 jnthn Hm
15:39 jnthn Yeah, that'd be the place
15:39 jnthn Very odd
15:40 jnthn But yes, let's revert and bump for now and diagnose later
15:40 timotimo revert & bump is done
15:42 timotimo and the jit also knows about fastinvoke sufficiently well it seems
15:43 jnthn Yeah
15:43 jnthn 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
15:43 jnthn It's possible it's something else going wrong that creates that effect
15:43 timotimo "a lot" is an understatement
15:44 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
15:44 jnthn And good performance relies a lot on finding ways to cheat on that
15:44 timotimo https://gist.github.com/smls/9adf4b6707938445c050  -  i was running this for profiling
15:44 jnthn So yeah, it's perhaps the most painful optimization you could break, aside from method caching.
15:45 timotimo spending 62.5% exclusive time in find_best_dispatchee is *tough*
15:45 konobi jnthn: tried using ARC?
15:45 jnthn Right. That's how much we rely on it.
15:45 timotimo oh, btw, i'd like to put the size of an allocated thing into the profile, too. sounds sensible?
15:45 jnthn konobi: Don't think I've even *used* a language that does that, let alone implemented one. :)
15:46 timotimo for that purpose, perhaps a flag "mallocs some extra data" might be interesting
15:46 timotimo i don't know what ARC is ... only know "arc flags" for making path finding faster
15:46 jnthn I suspect Automatic Reference Counting
15:46 timotimo oh
15:46 jnthn The thing that Swift/Objective C do
15:47 jnthn To handwave a bit, "do static analysis to work out where the calls to free go"
15:47 jnthn Guess it's highly related to escape analysis.
15:47 timotimo we're hoping to get escape analysis at one point, anyway
15:48 timotimo perhaps that'll be enough for our purposes?
15:48 jnthn My impression is using ARC is more a language design decision
15:49 jnthn 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:50 konobi jnthn: nope... adaptive replacement cache
15:50 timotimo ah, fair enough
15:50 jnthn (size of allocated thing) can work, but arrays/hashes resize over time...
15:50 jnthn konobi: Dammit, too many acronyms :P
15:50 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"
15:51 jnthn konobi: Also makes more sense in context :)
15:51 timotimo hehe
15:51 jnthn But no...and doing so would need some consideration of concurrency
15:52 jnthn 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
15:52 konobi that should be fine
15:52 jnthn And that's easy to achieve with an append-only cache.
15:52 jnthn Yeah, I think it's possible to engineer.
15:52 jnthn But we should actually meausre if we can get a win out of it first.
15:53 jnthn As in, whether full caches are common
15:53 konobi or at least that it does no worse =0)
15:54 timotimo today is headache-day ... it's not getting better :S
15:54 jnthn No, it'd actually have to do notably better
15:54 jnthn As a general Moar architectural principle, anything that increases code complexity has to pull its weight.
15:54 timotimo "time spent on designing and implementing" is a big cost for us
15:55 konobi jnthn: https://java.net/projects/solaris/sources/on-src/content/usr/src/uts/common/fs/zfs/arc.c?rev=13149
15:55 konobi that's probably a good start... heavily commented =0)
15:56 jnthn Yes, thanks
15:56 jnthn And obviously more involved than what we have now :)
15:56 geekosaur um? which ARC are we talking about here?
15:57 jnthn Well, we've been through two of them so far :)
15:57 jnthn Niether is arc welding...
15:57 geekosaur zfs's arc is an adaptive filesystem cache. there are some similarities but not much
15:57 jnthn https://en.wikipedia.org/wiki/Adaptive_replacement_cache anyway
15:57 geekosaur (if you;re thinking of e.g. apple's automatic refcounting)
16:14 Ven joined #moarvm
16:51 vendethiel joined #moarvm
17:42 Ven joined #moarvm
18:11 vendethiel joined #moarvm
18:56 virtualsue joined #moarvm
20:47 virtualsue joined #moarvm
21:51 diakopter I still have to disable jit to build nqp on latest msvc
22:03 jnthn diakopter: Did you figure out why at all? I have a hazy memory of some 32-bit/64-bit confusion...
22:08 diakopter jnthn: it was misconfusion
22:08 diakopter it's 64-bit for sure
22:19 konobi oh... yet more ridiculousness... http://copy.sh/v86/
23:11 TimToady m: say EVAL "42"
23:11 camelia rakudo-moar e8d924: OUTPUT«42␤»
23:11 TimToady m: say EVAL 42
23:11 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⏏…»
23:12 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…»
23:12 jnthn Does it really need 3 !s? :)
23:12 jnthn Also probably wants a re-word for the literal thing
23:17 rurban_ joined #moarvm
23:21 dalek MoarVM: 2ce4b7a | cygx++ | src/io/syncfile.c:
23:21 dalek MoarVM: fix typo in error message
23:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2ce4b7a24f
23:21 dalek MoarVM: 9a79010 | lizmat++ | src/io/syncfile.c:
23:21 dalek MoarVM: Merge pull request #317 from cygx/patch-1
23:21 dalek MoarVM:
23:21 dalek MoarVM: fix typo in error message
23:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9a79010936
23:21 lizmat m: 42.EVAL
23:21 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␤»
23:22 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␤»
23:22 lizmat Ah, I guess something got nuked and it's now rebuilding ?
23:24 TimToady yes, but waiting for jvm build to finish, or we run out of mem
23:29 diakopter no swap?
23:31 TimToady m: use Test; say EVAL 42
23:31 camelia rakudo-moar af5b39: OUTPUT«42␤»

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