Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-08-28

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

All times shown according to UTC.

Time Nick Message
00:02 woosley joined #moarvm
00:08 cognome joined #moarvm
00:09 cognome joined #moarvm
00:34 cognome joined #moarvm
01:14 FROGGS_ joined #moarvm
06:35 _sri joined #moarvm
06:51 sergot hi o/
06:52 nwc10 \o
07:11 kjs_ joined #moarvm
07:21 zakharyas joined #moarvm
08:09 brrt joined #moarvm
08:31 kjs_ joined #moarvm
08:41 JimmyZ joined #moarvm
08:41 JimmyZ good afternoon, #moarvm
08:41 FROGGS hi JimmyZ
08:41 brrt joined #moarvm
08:42 JimmyZ hello FROGGS
08:43 brrt \o JimmyZ
08:43 brrt just the person i need :-)
08:43 brrt i need to really really be certain
08:43 JimmyZ o/ brrt
08:43 brrt do we /want/ divide-by-zero to crash or do we want to throw an exception
08:43 brrt i.e. hardware exception
08:43 brrt or software exception
08:44 JimmyZ I don't know, maybe we can ask jnthn++ :P
08:44 brrt also, is round-to-negative-infinity for integer division specced
08:44 brrt without jnthn all is panic :-P
08:44 JimmyZ we are talking about native int
08:45 JimmyZ not Int :P
08:45 brrt hmm
08:46 brrt no i know
08:46 brrt basically, i'm okay with a 'safety brackets are off' approach to natives
08:46 brrt but that means you'll have to catch /native/ hardware exceptions too
08:47 brrt and taken further, you might argue that you want native rounding behavior
08:47 JimmyZ actually, I 'd like  hardware exception( for native int ), if users want software exception, the users can catch it by themself
08:47 brrt fair enough
08:48 brrt but i'd want some consensus on that :-)
08:48 brrt i'm indifferent about it
08:48 JimmyZ this conforms to TimToady++'s fast  division, methinks
08:49 brrt fair enough
08:49 brrt what about the rounding behaviour then :-)
08:51 JimmyZ I don't know... but for native int, I wish it behaves like C. :P
08:53 brrt hmm
08:53 brrt but C might differ between architectures
08:54 brrt as in, i really suspect there is a reason for the logic in interp.c
08:54 brrt although
08:54 brrt if that is so
08:54 brrt then the logic would never be correct
08:54 brrt uhm
08:58 JimmyZ TimToady, jnthn: how do think about it?
09:26 JimmyZ_ joined #moarvm
10:01 kjs_ joined #moarvm
10:24 zakharyas joined #moarvm
10:31 jnthn Good evening o/
10:31 nwc10 Good UGT heresy
10:32 nwc10 jnthn++ # profiler
10:33 * jnthn noticed TimToady++ made some spec commits on native division, and wonders if those cover whta was being discussed some hours ago...
10:34 jnthn nwc10: Oh...have folks been up to great good with it? :)
10:34 nwc10 jnthn: strangely, not as much as one might have hoped
10:47 nwc10 can I --profile NQP code?
10:47 jnthn Sure
10:47 nwc10 oh, yes, by putting after  nqp.moarvm
10:47 jnthn bbi10
10:50 kjs_ joined #moarvm
11:04 timotimo jnthn: the spec change was just to turn the "return a Failure for div by 0" into a straight exception
11:04 timotimo the call to failure caused our optimizations to bail, making a tight loop in example code very costly
11:06 jnthn yes, i twould...
11:06 jnthn Well, is Rakudo itself guarding that now?
11:09 timotimo gimme a sec
11:09 timotimo no, we rely on the vm to throw an exception
11:09 timotimo from inside nqp::mod_i
11:09 timotimo not sure if the jvm and parrot backends do that, but supposedly that commit went through spec testing
11:10 brrt jnthn: these spec commits are exactly what is up
11:10 brrt :-)
11:10 jnthn Well, I'm not sure the VM dying with sigfpe is the way to go...
11:11 brrt i /think/ that is what parrot does
11:11 brrt (i.e. dying with sigfpe)
11:11 brrt one could argue that we should catch signals but threads
11:11 brrt and windows
11:12 brrt i.e. translate signals to exceptions
11:14 jnthn I guess one solution i shave the JIT check if it's zero and branch to something that throws an exception if so.
11:14 jnthn So that if it's not zero there is no branch
11:14 jnthn (e.g. by noticing we need such code, making a label, then right at the end of code-gen attaching that exceptional path)
11:14 brrt that's pretty much what i did yesterday :-)
11:15 jnthn ah, ok
11:15 brrt except that the exception-throwing is inline
11:15 brrt and what you're saying.. we could do that in principle
11:15 jnthn Yeah, that means we have to jump...
11:15 jnthn (in the normal case)
11:15 brrt uhuh
11:15 brrt i agree that this is suboptimal
11:15 jnthn Which is avoidable, which can be cheaper
11:16 brrt ok, i have an idea of how to do that
11:16 jnthn Oher thing is that if we're dividing by a constant, we can see that in facts.
11:16 jnthn And elide the check.
11:16 brrt you're asking for things that the jit graph can't really express yet :-0
11:16 brrt :-)
11:17 brrt which goes to show how much work is still left to be done :-)
11:19 brrt although, now that i think about it, we /could/ do that now
12:04 timotimo aye, we'll need many more changes to do more amazing optimizations
12:05 timotimo though ... we'll probably have to see if we can do some nice things at the spesh level, too
12:06 timotimo i'm very curious how we'll do the "hypers on native arrays will turn into sse instructions" thing
12:07 brrt har har
12:07 brrt har-dee-har-har
12:07 timotimo hm?
12:07 brrt we're quite far away from expressing that
12:07 brrt is what i'm saying
12:07 timotimo yeah :S
12:07 timotimo we also don't have these native arrays yet ;)
12:08 brrt exactly
12:08 timotimo and if the ints are not packed tightly, i don't think sse would work well
12:08 brrt no, you'll need contigous blocks before you can do that
12:08 brrt if we have native arrays and real-codegen and a host of other things
12:09 timotimo it'd end up being a full copy into a packed space, then a calculation and a copy back
12:09 brrt then for one thing, we'll have an enormous speed boost just from that
12:09 timotimo you said you had an epiphany related to phi nodes and how to do set removal?
12:09 brrt not on spesh level, but on register-allocation level, yes
12:10 timotimo thought so, yeah
12:10 brrt and i mean register-assignment not allocation
12:10 timotimo mhm
12:10 timotimo i really wonder how expensive that stuff ends up being
12:10 brrt register allocation is this subtly different thing wherein you assign a register for a loop or so
12:10 brrt sets?
12:10 timotimo yes
12:10 timotimo excessive sets
12:10 brrt but set removal kind of follows out of register assignment
12:11 timotimo right
12:12 brrt as in, when you assign a value to be held in a cpu register, and set copies the value to another moar register, then that just means the cpu register now holds the value for the other moar register too
12:12 timotimo will we have to treat object/string register and int/num registers differently for set deduplication, btw?
12:13 brrt depends on which level you want to do that, but for spesh yes, since the GC sees them as different
12:13 timotimo not only that
12:13 timotimo if you set a num to a different register, you have two different copies you can mutate individually
12:13 brrt for the cpu level, object/string/int just go into gprs, and num go into sse registers
12:13 timotimo if you have an object in two registers, they are "by reference"
12:14 brrt i see
12:14 timotimo maybe that's what has ruined jnthn's and my early attempts at set removal?
12:14 brrt yes, in that sense the algorithm would have to take a different approach
12:14 timotimo at least in my approach it didn't
12:14 timotimo (this was spesh-level back then)
12:15 brrt how do you handle deopts?
12:15 timotimo hope and pray :)
12:15 timotimo i wasn't handling deopt properly at all back then
12:16 brrt well.... that would kill it too
12:16 timotimo jnthn probably did, but i didn't look closely at the code, i believe
12:24 kjs_ joined #moarvm
13:18 brrt joined #moarvm
13:53 kjs_ joined #moarvm
14:10 odc joined #moarvm
14:22 jnthn I don't think I've tried the set removal patch again since fixing dead code elim's deopt issues...
14:33 carlin if conditions that are always true: https://github.com/MoarVM/MoarVM/pull/132
14:35 woolfy joined #moarvm
14:36 timotimo in C, char is a signed byte?
14:36 timotimo in that case, we'll probably want to check for < 0 instead
14:36 brrt yes
14:36 brrt char is signed byte, this bytes many people
14:36 timotimo instead of removing the check, that is
14:37 jnthn Yeah, https://github.com/carbin/MoarVM/commit/248fcf3bd7aea3cd499aac2c670e6c41c12a3b6b is wrong
14:38 timotimo haven't looked at the other diffs yet
14:38 jnthn Should use MVMuint8 or MVMint8 in the code to make it clearer, thus avoding the confusion. :)
14:38 timotimo yup
14:38 jnthn Others looks sane to me.
14:39 dalek MoarVM: 459436a | Carlin++ | src/ (3 files):
14:39 dalek MoarVM: Fix implicit declaration of function warnings
14:39 dalek MoarVM:
14:39 dalek MoarVM: Makes clang a tiny little bit happier
14:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/459436a468
14:39 dalek MoarVM: 216b415 | jonathan++ | src/ (3 files):
14:39 dalek MoarVM: Merge pull request #121 from carbin/noise-functions
14:39 dalek MoarVM:
14:39 dalek MoarVM: Fix implicit declaration of function warnings
14:39 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/216b415dbc
14:39 timotimo using clang's static analysis tools would probably be a good thing for moarvm
14:40 dalek MoarVM: 9056d44 | Carlin++ | 3rdparty/libtommath/ (2 files):
14:40 dalek MoarVM: use arc4random on platforms that support it
14:40 dalek MoarVM:
14:40 dalek MoarVM: This fixes MVM_bigint_rand not being random on the various BSDs due
14:40 dalek MoarVM: to broken rand() implementations on those platforms
14:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9056d44be0
14:40 dalek MoarVM: c629ef5 | jonathan++ | 3rdparty/libtommath/ (2 files):
14:40 dalek MoarVM: Merge pull request #119 from carbin/master
14:40 dalek MoarVM:
14:40 dalek MoarVM: use arc4random on platforms that support it
14:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c629ef5912
14:41 dalek MoarVM: d155b9f | Carlin++ | src/core/exceptions.c:
14:41 dalek MoarVM: Fix conversion warnings in exceptions.c
14:41 dalek MoarVM:
14:41 dalek MoarVM: This file is now exceptionless compiling with clang
14:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d155b9fa96
14:41 dalek MoarVM: f73877a | jonathan++ | src/core/exceptions.c:
14:41 dalek MoarVM: Merge pull request #122 from carbin/noise-exception
14:41 dalek MoarVM:
14:41 dalek MoarVM: Fix conversion warnings in exceptions.c
14:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f73877a0df
14:52 carlin how's this?: https://github.com/carbin/MoarVM/commit/db3ee52f3cf25872f7a4b6a8331f4e0cb9b20c1d
14:54 brrt seems-better-to-me
14:55 brrt i still have to figure out why the getcodeobj JIT breaks
14:56 * timotimo is still somewhat stubbornly hoping for param_* to be implemented soon
14:57 brrt hahaha
14:57 brrt i know i know
14:58 brrt maybe jnthn++ can provide some ideas
14:58 timotimo i don't want to annoy you too much ... i'm just being a little kid about this :P
14:58 brrt basically, i want to remove the dispatching from those ops
14:58 brrt right now if you look at src/core/args.c, there's basically a bunch of dispatching macro's
14:59 brrt but in fact, if you know the type you want - which you do - you can remove about half them
14:59 brrt half of them
14:59 brrt it seems
14:59 brrt and that should speed stuff up
14:59 brrt interpreter and jit both
14:59 timotimo would that mean we'll get more instructions for those param_* ops that would be the result of spesh?
15:00 brrt uh, no, not really
15:01 brrt the other 'issue' i see with the current params_* implementation is that
15:01 brrt you basically have this path between what's provided and what is desired
15:01 brrt i.e. you may provide an int, and want a string
15:01 brrt well, we can do that
15:02 timotimo ah, that's partially the big "autounbox" thing?
15:02 brrt yes
15:02 brrt but the current implementation is basically a greedy hardcoded search
15:02 timotimo mhm
15:02 brrt and autobox too, btw
15:02 timotimo ah, indeed
15:03 brrt also, basically if you have an object that can box an int and a num, for example, then the autounbox will get the int only (iirc), even if you wanted the num
15:03 brrt none of this is a problem as in 'broken'
15:03 timotimo ah, d'oh
15:03 JimmyZ joined #moarvm
15:03 brrt especially as nearly everything in perl6 is an object
15:04 brrt so you don't pass natives directly that often
15:04 timotimo nearly everything in perl6, but not necessarily everything in a performance-tuned piece of code ;)
15:06 brrt but i think you can see that ehm... i don't have a single good solution for this
15:07 brrt other than just changing the signatures and not caring about the implementation itself
15:07 timotimo and a "shoddy" first stab at implementing a few of these ops in the jit would be too much duplicated work, i suppose?
15:07 brrt no, that's not really it i think
15:08 brrt for another thing, i really think the required flag is a waste in that function
15:08 brrt no reason the interpreter can't throw if it expected something and didn't get it
15:08 brrt in optional ops the interpreter must jump too, right?
15:08 timotimo ah, hm.
15:09 brrt but what i don't know is what the tradeoffs were in writing it in this fashion
15:09 brrt long story short
15:09 brrt i'm overly cautious perhaps
15:09 timotimo mhm
15:09 brrt but personally i care more about segfaults than having them anyway
15:10 timotimo %)
15:11 brrt since - and this is totally unscientific guesswork from my part - if we couldn't spesh the arguments, that probably means we get a lot of different types, and we're going to end up deopting really often
15:11 brrt but i can be totally wrong about that
15:12 brrt whereas a segfault may mean that we have a bug lurking somewhere that needs a good smash
15:18 jnthn m: say $*TZ
15:18 camelia rakudo-moar 72852f: OUTPUT«0␤»
15:21 mj41 joined #moarvm
15:24 * brrt afk
15:53 diakopter m: say $*TZ
15:53 camelia rakudo-moar 72852f: OUTPUT«0␤»
15:54 timotimo camelia should really use a CTCP Time on the caller to get the proper timezone.
15:54 diakopter m: $^ # Form module? LTA error?
15:54 camelia rakudo-moar 72852f: OUTPUT«[31m===[0mSORRY![31m===[0m Error while compiling /tmp/ndJEtD7klG␤Unsupported use of $^ variable; in Perl 6 please use Form module␤at /tmp/ndJEtD7klG:1␤------> [32m$^[33m⏏[31m # Form module? LTA error?[0m␤»
15:59 TimToady that's more of a #perl6 issue
16:25 Ven joined #moarvm
17:06 tgt joined #moarvm
17:52 Ven joined #moarvm
19:22 Ven joined #moarvm
19:26 Ven_ joined #moarvm
20:00 FROGGS joined #moarvm
21:18 donaldh joined #moarvm
21:36 itz_ joined #moarvm
21:40 btyler joined #moarvm
21:41 ggoebel111118 joined #moarvm
21:41 itz joined #moarvm
21:42 donaldh_ joined #moarvm
21:46 itz joined #moarvm
22:10 avuserow joined #moarvm

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