Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-03-24

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

All times shown according to UTC.

Time Nick Message
00:36 dalek MoarVM/jit_devirtualize_reprops_2: a185b28 | timotimo++ | src/jit/emit_x64.dasc:
00:36 dalek MoarVM/jit_devirtualize_reprops_2: special case initial TC and STable, obj, objbody cases in jit
00:36 dalek MoarVM/jit_devirtualize_reprops_2: review: https://github.com/MoarVM/MoarVM/commit/a185b28d3d
02:45 ggoebel joined #moarvm
07:03 brrt joined #moarvm
07:09 FROGGS joined #moarvm
07:53 Ven joined #moarvm
08:58 Ven joined #moarvm
09:09 kjs_ joined #moarvm
10:07 kjs_ joined #moarvm
10:24 brrt joined #moarvm
10:24 brrt 6
10:24 brrt damnit erc
10:24 brrt \o
10:24 brrt timotimo
10:24 brrt i do not agree
10:25 brrt i mean, yeah, this probably works, but is it worth it?
10:25 brrt heck, i'd rather have you generate a single JIT_REG_REPROP, and check for that; but again
10:25 brrt not worth it (yet)
11:46 kjs_ joined #moarvm
11:52 zakharyas joined #moarvm
12:42 timotimo as soon as the expression thingie is in, this will be completely unnecessary
12:42 timotimo the problem with JIT_REG_REPROP is that it'd have to be counted as three arguments, which i'm not completely sure how to do, etc etc
12:42 timotimo but i haven't looked into it too deeply
13:08 brrt joined #moarvm
13:09 timotimo exprcomp, was that the name?
13:09 timotimo brrt: i didn't mean to undermine your pretty code in the jit :)
13:09 timotimo also, for some reason i'm getting crashes with valgrind, but nothing at all with asan
13:10 timotimo so i'll likely revert it anyway
13:10 brrt timotimo - i'm not saying my jit code is necessarily pretty
13:10 brrt just that this was a hack, and likely to be overseen in a future time
13:11 brrt wierd though
13:14 timotimo :)
13:34 brrt also timotimo++ for the weekly
13:34 timotimo thank you :)
13:35 timotimo do you have an idea why devirtualizing reprops might not give a significant improvement at all?
13:35 timotimo oh, already dc'd
13:35 brrt joined #moarvm
13:35 timotimo you're back! :)
13:35 brrt yeah, i had to restart polari because it was... annoying
13:35 brrt it's a shame when otherwise well-designed software acts annoying like this
13:36 timotimo i don't even know what polari is :)
13:36 brrt it's a graphical irc client for gnome3
13:37 brrt i use that or erc typicallly :-)
13:39 timotimo OK
13:39 timotimo are you pleased with gnome3?
13:39 timotimo i was doubtful about it for a very long time, but the new screenshots i've been seeing have some charm to them
13:42 nwc10 that is an interesting choice of name, given http://en.wikipedia.org/wiki/Polari
13:43 nwc10 or maybe that was the point
13:45 brrt maybe.. i hadn't really considered that :-)
13:45 timotimo i've never heard of that, interesting!
13:45 brrt in general i'm pretty happy
13:46 brrt a big benefit for me is the 'accessibility' button on the top bar
13:46 timotimo ah? what's in it for you?
13:46 brrt and just pressing the 'super' button and type-to-search is really handy and well-implemented
13:46 timotimo if you don't mind me asking, of course
13:46 brrt large text and zooming
13:46 brrt alternatively :-) no of course
13:47 timotimo ah
13:47 brrt also i don't really care about advanced window management
13:47 brrt i typically have one or at most two windows open at the same time
13:47 timotimo i was surprised gnome and other environments weren't in a fabulous shape to handle HiDPI displays yet, since they've had accessibility for a long time anyway
13:47 timotimo yeah, these days i mostly do left/right halves of the screen for my windows, but i do sometimes miss having quarters
13:48 timotimo the newest version of xfce, which is what i use, will have that, though
13:48 brrt i never miss it, and when i do, there's emacs
13:48 timotimo hehe
13:49 brrt so yeah, i'm happy
13:49 brrt i do understand where some of the hate is coming from
13:49 brrt but i find that it doesn't really apply to my usecase, so why care?
13:49 timotimo right. i've been hating on it a bit myself, but i should have realized that it's a very self-centered thing to do
13:50 timotimo "gnome3 doesn't work well for me, so i'll proclaim it sucks!"
13:50 timotimo silly timo.
13:51 timotimo do you have tips for where i could spend my energy (related to jit and spesh) better than optimizing argument passing?
13:51 timotimo also, would you also rather see the optimization for TC in arg1 go?
13:52 brrt my hypothesis is that the tmp6 -> correct place dance doesn't really cost a lot
13:52 brrt maybe i'm wrong about that
13:52 timotimo mhh, could be
13:52 timotimo well, modern processors are magical
13:52 brrt i'm preparing a blog post on future JIT improvements
13:53 brrt well... as for what you can do.. i haven't really looked at why the hyper test breaks
13:53 timotimo cool
13:54 timotimo oh? i'm not sure i know about a hyper test breaking
13:58 kjs_ joined #moarvm
14:00 brrt with the elems repr devirt patch? you asked me a few days ago
14:01 timotimo oh
14:01 timotimo aye
14:01 timotimo super weird if you ask me.
14:01 timotimo the only thing i can think of is relying on something spesh doesn't provide, but i put an unconditional "use facts" into the "optimize_repr_op" function of spesh
14:03 brrt hmmm
14:03 brrt the main difference is that the JIT devirtualizes something while spesh never does this, right?
14:03 brrt it could be a spesh bug, is what i'm saying
14:03 brrt but i guess that's what you're saying too
14:05 timotimo well, the jit devirtualizes a repr op only if spesh didn't do it yet
14:05 timotimo so a getattr, for example, or a decont would probably have turned into a p6oget_* by that point
14:05 timotimo however, sometimes we have getattr ops that have a known type but an unknown attribute name
14:06 timotimo in that case, a devirt is helpful
14:06 timotimo and of course there's all the array functions like push and pop that don't get touched by spesh, because the underlying code is too complex to be turned into a simple operation (resizing and such)
14:07 brrt hmm right
14:07 brrt oh, i know how you can spend your time Very Fruitfully
14:07 brrt if you have it to spend
14:07 timotimo i guess i do :)
14:08 timotimo i'm still feeling kind of sad about the fact that i'm not internals-savvy or design-savvy enough to make nativecall as awesome as it could be, JIT-wise
14:10 brrt well, renember the param_[ro][pn]_[inso] business?
14:10 timotimo yes
14:10 brrt these return a struct
14:10 brrt returning a struct is... annoying
14:11 brrt there are two fields i think of relevance
14:11 brrt the result value, and if it is present
14:11 Ven joined #moarvm
14:11 timotimo oh, that seems like a good place to use VMNull vs C-level null instead
14:12 brrt hmm really? i don't see why?
14:12 timotimo well, result value + presence yes/no can be encoded into a simple pointer in that case
14:12 timotimo if the value was "a null", it'll just be VMNull, if it wasn't present it'll be a null pointer instead
14:12 timotimo or am i misunderstanding?
14:13 brrt i dunno if that's going to cause too many semantic changes?
14:14 timotimo aren't we using that internally exclusively?
14:14 brrt but anyway, i'd suggest returning the pressence, passing a register, and settng the value conditionally
14:15 brrt then the required ops can throw if not present, and optional ops can branch if not present
14:15 timotimo this would be a refactoring of how moarvm does these operators and it'd mainly affect interp.c, right?
14:15 timotimo (well, usage-wise, that is)
14:15 brrt e.g. currently we have MVMArgInfo MVM_args_ops_obj(tc, ctx, pos, required)
14:16 brrt i'd change that to MVMint32 MVM_args_pos_obj(tc, ctx, pos, &register)
14:16 brrt but one of the complexities is that these ops do automagic transformations
14:17 timotimo hmm, where do we actually use the flags entry to that struct? can that just be thrown out?
14:18 timotimo transformations, as in vivification and such?
14:19 brrt yes
14:19 brrt autobox/unbox
14:19 timotimo oh?
14:20 brrt and i-to-n transformations and the like
14:20 brrt a lot of things
14:20 timotimo hm, ok
14:20 brrt a map of these transformations would be very helpful
14:20 brrt it's not strictly necessary
14:20 timotimo ah, the autounbox define
14:21 brrt i'll be off, have to go to the vet
14:21 timotimo that's where the flags are used
14:21 timotimo oh, i hope your pet will get better! unless it's just a routine inspection or something
14:21 brrt no, rather sick
14:21 timotimo uh oh
14:21 timotimo get well soon, brrt's pet!
14:21 brrt she thanks you :-)
14:21 * brrt afk
14:25 timotimo i still have some feature work i was interested in building ... udp sockets
14:34 FROGGS[mobile] joined #moarvm
15:10 Ven joined #moarvm
18:18 FROGGS joined #moarvm
18:34 kjs_ joined #moarvm
19:14 brrt joined #moarvm
19:14 * brrt pet is not getting well soon at all, it appears
19:15 timotimo oh no! :(
19:15 timotimo what kind of pet is it? for some reason i seem to recall you have a ferret or something
19:15 timotimo but i could just have dreamt that
19:19 brrt i have 3 rats
19:20 timotimo ah
19:21 brrt dinner &
19:34 brrt well, ferrets and rats sound alike, in name, so that is not crazy :-)
19:35 timotimo :)
19:35 timotimo do they also sound alike in squeaks?
19:42 brrt no. rats hardly ever squeak, except for social purposes
19:42 brrt :-)
19:42 brrt like the way they do in the movies? rats don't do that
19:42 mj41 joined #moarvm
19:42 timotimo yeah, just like cats and dogs
19:43 timotimo as soon as they enter a frame they have to make a sound
19:43 brrt right
19:49 timotimo currently i'm spending a lot of time over a ta friend's house where there's two cats
19:51 timotimo one of them is very easily made to make a sound
20:00 brrt some cats are, yes
20:00 brrt many cats in my neighbourhood are really eager for petting and will meow at you just for walking by
20:11 timotimo this one does a dove-like sound whenever she gets surprised, even if the surprise is very slight
20:11 timotimo it's quite adorable
20:11 timotimo hm, maybe more like a pidgeon sound rather than a dove
20:21 FROGGS timotimo: I managed to get at the 'is inlined' information from within the CStruct
20:23 timotimo oh, great!
20:23 timotimo i'm eager to see how you implemented it
20:38 dalek MoarVM/union: 09746e9 | FROGGS++ | src/ (4 files):
20:38 dalek MoarVM/union: inline CUnions when attr's 'inlined' flag is set
20:38 dalek MoarVM/union:
20:38 dalek MoarVM/union: Before the default was to inline CUnions. Now a trait on the attribute
20:38 dalek MoarVM/union: can set this flag.
20:38 dalek MoarVM/union: review: https://github.com/MoarVM/MoarVM/commit/09746e912d
20:40 FROGGS timotimo: pushed the rakudo part too now
20:49 timotimo mhm
20:49 timotimo good :)
21:15 brrt anyone care to review my next blog post while i'm afk? https://brrt-to-the-future.blogspot.com/b/post-preview?token=60VaT0wBAAA.fZEGpZk5QINALqo-MEpYUA.d7VYsToJv8i3UZY9GZGYow&postId=2452438934221038651&type=POST
21:15 jnthn brrt: I'm tired, but I'll ahve a look :)
21:17 colomon joined #moarvm
21:17 kjs_ joined #moarvm
21:17 TimToady optiizations
21:21 jnthn "Many more optimizations are forbidden by Perl 6 semantics" - I'd put it more like "Many optimizations can not be proven safe at compile time in Perl 6"
21:22 TimToady and the link-time guarantees in the design document are largely NYI
21:23 TimToady but we're supposed to be able to close and finalize classes once we're to link time
21:24 jnthn TimToady: But...I don't really believe in that in a sense.
21:25 jnthn TimToady: If we already pre-comp'd modules to bytecode as we installed them, then the top-level application is allowed to close things...the ship has already sailed.
21:26 TimToady might still provide facts like "I'll never need this guard"
21:26 jnthn That's true
21:26 jnthn Pushing the info down VM-wards may help
21:26 jnthn Further, if we forbid mixing in, we can save a bit of memory per object
21:27 jnthn brrt: "transforming tight loops into SIMD" - yes that's hard, but hyperops on native arrays actually are explicit SIMD
21:27 TimToady plus you might be able to avoid the need for some deopt logic
21:27 jnthn Indeed.
21:28 jnthn I do worry a bit that we're going to find it trick in so far as an application may well use dozens of modules, and one of them somewhere may happen to use mixins on its insides.
21:28 jnthn And closing stuff at application level will bust that module
21:28 jnthn *tricky
21:29 jnthn brrt: It may be worth noting why the JIT we have today is the way it is: was done in GSoC time period, and needed to cope with deoptimization, OSR, and so forth.
21:30 TimToady +1 blame Google :)
21:30 jnthn brrt: And that deopt was certainly needed for it to actually be useful for the kinds of optimizations we want to do for Perl 6, and so that had to take priority over wonderful code-gen - which is what the aim is now.
21:33 jnthn brrt: Given you note we'll keep a lot of the infrastructure (especially around OSR and deopt) in place, I'd word it more like "The expression JIT functions as an extra node type for the existing JIT - though very many things will likely end up using it."
21:34 jnthn brrt: One other opportunity we may get is being able to JIT native calls more easily also :)
21:34 jnthn Anyway, good post. And nice plans. brrt++
21:36 FROGGS brrt++
21:36 FROGGS I understood parts of it \o/
21:39 kjs_ joined #moarvm
21:44 retupmoca joined #moarvm
21:49 leedo joined #moarvm
21:50 TimToady another possible optimization is to identify idempotent sequences of code that can increase the distance between deopt sequence points, at the expense of repeating some calculations
22:18 colomon joined #moarvm
22:20 kjs_ joined #moarvm
22:28 brrt joined #moarvm
22:32 brrt jnthn++ for critical review :-)
22:35 brrt also TimToady++ :-)
22:36 brrt hmm... what would be the real benefit of increasing deopt point distance? aside from moving deopt points out of loops etc
22:36 brrt in general calculation is cheap and memory is expensive though :-)
22:40 TimToady not having to sync things to memory in between mostly
22:41 TimToady alternately, you could have points that say "if you have to deopt here, write these registers to these locations first"
22:41 TimToady how to commit the current transaction, as it were, rather than how to rollback
22:42 brrt that is actually what i'd rather do
22:42 timotimo having fewer deopt points active reduces the amount of registers we have to keep alive in spesh
22:43 brrt eliminating deopt points is at least partly spesh's responsibility i'd think
22:43 TimToady and since idempotence is related to lack of side effects, escape analysis will also play into that
22:43 timotimo sure
22:43 TimToady anyway, just talking in general terms like I know what I'm sayin' :)
22:45 brrt :-) it makes sense
22:45 TimToady my math always had more vigor than rigor, I fear... :)
22:45 brrt and in the jit i really do want to do active restoration sequences (optimisticly)
22:46 brrt but that's.. hard, in general, and wasn't necessary until now
22:46 TimToady careful, or you'll invent STM :)
22:48 TimToady for my part, I think we can do a much better job of caching dynvars than we do
22:48 brrt it's not really the same as STM, is it? i'm not at all familiar with that
22:49 TimToady well, it is transactional, and it has something to do with software and memory :)
22:49 brrt right
22:50 brrt i sometimes wonder whether transactions aren't more difficult to reason about than just the random storm of writes that we'd otherwise have
22:51 TimToady well, I think you'll need to view the random storm that happens between possible deopt points as some kind of transaction, or you'll get erroneous deopts
22:52 TimToady well, or the random storm of register writes that *aren't memory writes, anyway
22:52 TimToady one could view every memory write as a kind of transaction commit
22:52 TimToady but then your registers are just a write-through cache
22:53 TimToady anyway, looking forward to seeing your work in the future, for sure
22:54 brrt i'm looking forward to working on it again, too :-)
22:54 * TimToady goes back to thinking more about dynvar caches
22:57 TimToady thing is, we really only need to store a cache starting at the deepest $*FOO, and deeper frames can just dup a pointer to that cache
22:57 TimToady and if the cache were somehow authoritative, we would never even have to look in the lexpads
22:59 TimToady well, perhaps dup a pointer to the frame that holds the cache, rather, esp if the actual cache were the root of a linked list of authoritative dynvar locations, then if you have to search too far for $*FOO, you just link it into the front of the list
23:01 TimToady also, since there are relatively few dynvar names, they could very easily profit from string interning, even if the language in general doesn't use it
23:02 timotimo mhm
23:02 timotimo i'd like dynvars to become faster, if only for $*OUT
23:02 TimToady indeed
23:03 TimToady that's one of the reasons our IO is so slow
23:05 TimToady using the frames as a linked list of cache entries doesn't seem very...cache friendly
23:08 TimToady a direct link to a dynvar cache attached only to frames that actually declare dynvars seems like it could be more CPU cache friendly, though one would have to take into account allocation costs
23:09 TimToady a resizeable cache in one chunk of memory is probably more CPU cache friendly these days than a linked list
23:10 timotimo if that linked list only links chunks that have been allocated in close proximity, maybe that helps?
23:10 TimToady the degerate case of that is to just copy all the "environmental" locations down as Unix processes do, but that's probably insufficiently lazy for our purposes
23:10 TimToady a cache chunk pool might work, yes
23:11 timotimo i was wondering if mmapping a chunk of memory for every piece of code we jit is a bad idea
23:12 * TimToady doesn't follow the reasoning
23:13 TimToady or were you going back to the deopt thing?
23:13 timotimo nah
23:13 timotimo just running perl6 -e 'say 1' calls mmap 360 times
23:13 TimToady oh, just a new subject then :)
23:14 TimToady this after the lazy deserialization?
23:14 timotimo yes, sorry
23:14 timotimo but i'm now doing something else entirely :P
23:14 TimToady maybe figure out what has to get deserialized, and clump in in one mmap somehow?
23:15 brrt hmmm
23:15 * TimToady should probably do more measurement of dynvar overhead anyway first...
23:15 brrt i hadn't considered mmapping to be such a memory or cpu cost
23:15 TimToady well, syscalls are known to be atrociously slow on most unixen
23:16 brrt that is true. but we execute a lot more code than just 360 mmaps before we get to say
23:17 brrt (although i'll be the first to admit that it is a lot)
23:18 TimToady time perl6-m -e 'say 42'
23:18 TimToady 42
23:18 TimToady real0m0.190s
23:18 TimToady user0m0.135s
23:18 TimToady sys0m0.055s
23:18 TimToady sys time is significant
23:19 brrt fair enough
23:19 brrt but that's startup
23:19 brrt and still it's less than 50%
23:20 TimToady I thought that's what timotimo++ was talking about
23:21 TimToady but a 10% win, say, for coalescing mmaps would be significant
23:21 brrt right
23:22 brrt that's pretty much opposite to what the python folks think, btw :-)
23:22 TimToady well, maybe jnthn++ has already thought about which things should load eagerly vs lazily, but it's just an idea
23:23 japhb brrt: What is "opposite to what the python folks think"?  They don't believe in mmap coalescing?
23:24 brrt they don't believe in making the interpreter more than n% complex for less than n% speedup
23:24 TimToady well, there's something to be said for that point of view too :)
23:24 brrt which is a ... reasonable rule, i'd guess, but also the reason (aside from missing jnthn :-P) they don't have spesh
23:25 TimToady otoh, they don't really believe in tormenting the implementors on behalf of the users quite as much as we do :)
23:26 * TimToady just always wonders about any particular tradeoff whether the OR-ness of it is intrinsic or extrinsic to the actual problem...
23:26 brrt OR or XOR :-P
23:26 TimToady OR xor XOR :P
23:27 brrt but in general if things are hard it's nature's fault, i find
23:27 brrt some things are human problems, i try to avoid these
23:27 TimToady then by all means avoid me :)
23:28 brrt hah, i didn't say humans are problems
23:29 TimToady well, some of us are...
23:32 * brrt sleep &
23:32 TimToady o/
23:32 brrt o/

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