00:02 woosley joined 00:08 cognome joined 00:09 cognome joined 00:34 cognome joined 01:14 FROGGS_ joined 06:35 _sri joined
sergot hi o/ 06:51
nwc10 \o 06:52
07:11 kjs_ joined 07:21 zakharyas joined 08:09 brrt joined 08:31 kjs_ joined 08:41 JimmyZ joined
JimmyZ good afternoon, #moarvm 08:41
FROGGS hi JimmyZ
08:41 brrt joined
JimmyZ hello FROGGS 08:42
brrt \o JimmyZ 08:43
just the person i need :-)
i need to really really be certain
JimmyZ o/ brrt
brrt do we /want/ divide-by-zero to crash or do we want to throw an exception
i.e. hardware exception
or software exception
JimmyZ I don't know, maybe we can ask jnthn++ :P 08:44
brrt also, is round-to-negative-infinity for integer division specced
without jnthn all is panic :-P
JimmyZ we are talking about native int
not Int :P 08:45
brrt hmm
no i know 08:46
basically, i'm okay with a 'safety brackets are off' approach to natives
but that means you'll have to catch /native/ hardware exceptions too
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
brrt fair enough
but i'd want some consensus on that :-) 08:48
i'm indifferent about it
JimmyZ this conforms to TimToady++'s fast division, methinks
brrt fair enough 08:49
what about the rounding behaviour then :-)
JimmyZ I don't know... but for native int, I wish it behaves like C. :P 08:51
brrt hmm 08:53
but C might differ between architectures
as in, i really suspect there is a reason for the logic in interp.c 08:54
although
if that is so
then the logic would never be correct
uhm
JimmyZ TimToady, jnthn: how do think about it? 08:58
09:26 JimmyZ_ joined 10:01 kjs_ joined 10:24 zakharyas joined
jnthn Good evening o/ 10:31
nwc10 Good UGT heresy
jnthn++ # profiler 10:32
jnthn noticed TimToady++ made some spec commits on native division, and wonders if those cover whta was being discussed some hours ago... 10:33
nwc10: Oh...have folks been up to great good with it? :) 10:34
nwc10 jnthn: strangely, not as much as one might have hoped
can I --profile NQP code? 10:47
jnthn Sure
nwc10 oh, yes, by putting after nqp.moarvm
jnthn bbi10
10:50 kjs_ joined
timotimo jnthn: the spec change was just to turn the "return a Failure for div by 0" into a straight exception 11:04
the call to failure caused our optimizations to bail, making a tight loop in example code very costly
jnthn yes, i twould... 11:06
Well, is Rakudo itself guarding that now?
timotimo gimme a sec 11:09
no, we rely on the vm to throw an exception
from inside nqp::mod_i
not sure if the jvm and parrot backends do that, but supposedly that commit went through spec testing
brrt jnthn: these spec commits are exactly what is up 11:10
:-)
jnthn Well, I'm not sure the VM dying with sigfpe is the way to go...
brrt i /think/ that is what parrot does 11:11
(i.e. dying with sigfpe)
one could argue that we should catch signals but threads
and windows
i.e. translate signals to exceptions 11:12
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
So that if it's not zero there is no branch
(e.g. by noticing we need such code, making a label, then right at the end of code-gen attaching that exceptional path)
brrt that's pretty much what i did yesterday :-)
jnthn ah, ok 11:15
brrt except that the exception-throwing is inline
and what you're saying.. we could do that in principle
jnthn Yeah, that means we have to jump...
(in the normal case)
brrt uhuh
i agree that this is suboptimal
jnthn Which is avoidable, which can be cheaper
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.
And elide the check.
brrt you're asking for things that the jit graph can't really express yet :-0
:-)
which goes to show how much work is still left to be done :-) 11:17
although, now that i think about it, we /could/ do that now 11:19
timotimo aye, we'll need many more changes to do more amazing optimizations 12:04
though ... we'll probably have to see if we can do some nice things at the spesh level, too 12:05
i'm very curious how we'll do the "hypers on native arrays will turn into sse instructions" thing 12:06
brrt har har 12:07
har-dee-har-har
timotimo hm?
brrt we're quite far away from expressing that
is what i'm saying
timotimo yeah :S
we also don't have these native arrays yet ;)
brrt exactly 12:08
timotimo and if the ints are not packed tightly, i don't think sse would work well
brrt no, you'll need contigous blocks before you can do that
if we have native arrays and real-codegen and a host of other things
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
timotimo you said you had an epiphany related to phi nodes and how to do set removal?
brrt not on spesh level, but on register-allocation level, yes
timotimo thought so, yeah 12:10
brrt and i mean register-assignment not allocation
timotimo mhm
i really wonder how expensive that stuff ends up being
brrt register allocation is this subtly different thing wherein you assign a register for a loop or so
sets?
timotimo yes
excessive sets
brrt but set removal kind of follows out of register assignment
timotimo right 12:11
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?
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
if you set a num to a different register, you have two different copies you can mutate individually
brrt for the cpu level, object/string/int just go into gprs, and num go into sse registers
timotimo if you have an object in two registers, they are "by reference"
brrt i see 12:14
timotimo maybe that's what has ruined jnthn's and my early attempts at set removal?
brrt yes, in that sense the algorithm would have to take a different approach
timotimo at least in my approach it didn't
(this was spesh-level back then)
brrt how do you handle deopts? 12:15
timotimo hope and pray :)
i wasn't handling deopt properly at all back then
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 13:18 brrt joined 13:53 kjs_ joined 14:10 odc joined
jnthn I don't think I've tried the set removal patch again since fixing dead code elim's deopt issues... 14:22
carlin if conditions that are always true: github.com/MoarVM/MoarVM/pull/132 14:33
14:35 woolfy joined
timotimo in C, char is a signed byte? 14:36
in that case, we'll probably want to check for < 0 instead
brrt yes
char is signed byte, this bytes many people
timotimo instead of removing the check, that is
jnthn Yeah, github.com/carbin/MoarVM/commit/24...41c12a3b6b is wrong 14:37
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. :)
timotimo yup
jnthn Others looks sane to me.
dalek arVM: 459436a | Carlin++ | src/ (3 files):
Fix implicit declaration of function warnings

Makes clang a tiny little bit happier		 14:39
arVM: 216b415 | jonathan++ | src/ (3 files):
Merge pull request #121 from carbin/noise-functions

Fix implicit declaration of function warnings
timotimo using clang's static analysis tools would probably be a good thing for moarvm
dalek arVM: 9056d44 | Carlin++ | 3rdparty/libtommath/ (2 files):
use arc4random on platforms that support it

This fixes MVM_bigint_rand not being random on the various BSDs due to broken rand() implementations on those platforms		 14:40
arVM: c629ef5 | jonathan++ | 3rdparty/libtommath/ (2 files):
Merge pull request #119 from carbin/master

use arc4random on platforms that support it
arVM: d155b9f | Carlin++ | src/core/exceptions.c:
Fix conversion warnings in exceptions.c

This file is now exceptionless compiling with clang		 14:41
arVM: f73877a | jonathan++ | src/core/exceptions.c:
Merge pull request #122 from carbin/noise-exception

Fix conversion warnings in exceptions.c
carlin how's this?: github.com/carbin/MoarVM/commit/db...0cb9b20c1d 14:52
brrt seems-better-to-me 14:54
i still have to figure out why the getcodeobj JIT breaks 14:55
timotimo is still somewhat stubbornly hoping for param_* to be implemented soon 14:56
brrt hahaha 14:57
i know i know
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
brrt basically, i want to remove the dispatching from those ops
right now if you look at src/core/args.c, there's basically a bunch of dispatching macro's
but in fact, if you know the type you want - which you do - you can remove about half them 14:59
half of them
it seems
and that should speed stuff up
interpreter and jit both
timotimo would that mean we'll get more instructions for those param_* ops that would be the result of spesh?
brrt uh, no, not really 15:00
the other 'issue' i see with the current params_* implementation is that 15:01
you basically have this path between what's provided and what is desired
i.e. you may provide an int, and want a string
well, we can do that
timotimo ah, that's partially the big "autounbox" thing? 15:02
brrt yes
but the current implementation is basically a greedy hardcoded search
timotimo mhm
brrt and autobox too, btw
timotimo ah, indeed
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
none of this is a problem as in 'broken'
timotimo ah, d'oh
15:03 JimmyZ joined
brrt especially as nearly everything in perl6 is an object 15:03
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 ;)
brrt but i think you can see that ehm... i don't have a single good solution for this 15:06
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?
brrt no, that's not really it i think
for another thing, i really think the required flag is a waste in that function 15:08
no reason the interpreter can't throw if it expected something and didn't get it
in optional ops the interpreter must jump too, right?
timotimo ah, hm.
brrt but what i don't know is what the tradeoffs were in writing it in this fashion 15:09
long story short
i'm overly cautious perhaps
timotimo mhm
brrt but personally i care more about segfaults than having them anyway
timotimo %) 15:10
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
but i can be totally wrong about that
whereas a segfault may mean that we have a bug lurking somewhere that needs a good smash 15:12
jnthn m: say $*TZ 15:18
camelia rakudo-moar 72852f: OUTPUT«0␤»
15:21 mj41 joined
brrt afk 15:24
diakopter m: say $*TZ 15:53
camelia rakudo-moar 72852f: OUTPUT«0␤»
timotimo camelia should really use a CTCP Time on the caller to get the proper timezone. 15:54
diakopter m: $^ # Form module? LTA error?
camelia rakudo-moar 72852f: OUTPUT«===SORRY!=== Error while compiling /tmp/ndJEtD7klG␤Unsupported use of $^ variable; in Perl 6 please use Form module␤at /tmp/ndJEtD7klG:1␤------> $^⏏ # Form module? LTA error?␤»
TimToady that's more of a #perl6 issue 15:59
16:25 Ven joined 17:06 tgt joined 17:52 Ven joined 19:22 Ven joined 19:26 Ven_ joined 20:00 FROGGS joined 21:18 donaldh joined 21:36 itz_ joined 21:40 btyler joined 21:41 ggoebel111118 joined, itz joined 21:42 donaldh_ joined 21:46 itz joined 22:10 avuserow joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!