Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-08-22

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

All times shown according to UTC.

Time Nick Message
01:13 lizmat joined #moarvm
01:47 ilbot3 joined #moarvm
01:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:14 lizmat joined #moarvm
04:13 lizmat joined #moarvm
05:19 lizmat joined #moarvm
07:37 lizmat joined #moarvm
07:44 lizmat joined #moarvm
08:19 JimmyZ hmm, it'd be nice p6bigint take 64bit as small int, intead of 32bit
08:19 timotimo if you can make it happen, i'd be +1
08:20 ShimmerFairy I thought it did already, for 64-bit arches of course. Huh.
08:25 timotimo we had to have a flag somewhere in the p6int that differentiates
08:57 nwc10 you can probably do 63 bit int, and use the bottom bit as a flag, assuming that pointers are better than 2 byte aligned.
08:58 nwc10 but it's not clear if the complexity is worth it.
09:12 rurban_ joined #moarvm
09:29 JimmyZ nwc10: the reason I want 64bit for small int is that I can throw from unbox_i if there is  a bigint flag
09:48 lizmat joined #moarvm
10:16 timotimo right, then you wouldn't have to check if the bigint contained is actually small enough for a 64bit register
10:17 Ven joined #moarvm
11:38 FROGGS_ joined #moarvm
11:51 brrt joined #moarvm
12:00 brrt good *
12:03 JimmyZ \o brrt
12:08 Ven joined #moarvm
12:12 Ven joined #moarvm
12:26 ShimmerFairy joined #moarvm
13:19 jnthn If you have 63 bits for little big ints you still have the "doesn't answer for free if it's going to fit in a 64-bit register" problem and so have probably only made things more complex than they are today for no real simplification.
13:21 brrt joined #moarvm
13:22 ShimmerFairy I'd rather just count limbs for bigint-too-big checking, assuming limbs are evenly divisible by small ints (or vice versa)  :)
13:23 jnthn ShimmerFairy: You have to check if it's a little big int anyway before yo can safely ask how many limbs :)
13:23 jnthn ShimmerFairy: So you get the fast-path for 32-bit things for free
13:25 JimmyZ m: use nqp; say(unbox_i(-1e35));
13:25 camelia rakudo-moar edffe0: OUTPUT«===SORRY!=== Error while compiling /tmp/suGhG7xCrN␤Undeclared routine:␤    unbox_i used at line 1␤␤»
13:25 ShimmerFairy jnthn: I suspect we can assume everything's in multiples of 8 bits though, right? :)  (that is, no weird situation like 32-bit limbs and 36-bit native ints)
13:25 JimmyZ m: use nqp; say(nqp::unbox_i(-1e35));
13:25 camelia rakudo-moar edffe0: OUTPUT«This type cannot unbox to a native integer␤  in block <unit> at /tmp/spGkYfveXs:1␤␤»
13:25 jnthn ShimmerFairy: I can't promise you much about the limbs :)
13:26 jnthn JimmyZ: That's a Num, so it certainly can't unbox as a native int :)
13:26 jnthn ShimmerFairy: I think it may be something odd like 28 bits or so
13:26 jnthn ShimmerFairy: You'll have to look at the libtommath code for answers, I suspect
13:27 ShimmerFairy If there's a chance you can have 4-bit limbs and 5-bit native ints (for illustration, I'd hate that computer if real), then you'd have to be sure to check the "maybe limb" (the limb that can fit in a native up to a point) and check if it goes over its limit
13:27 JimmyZ m: use nqp; say nqp::unbox_i(-1e35)
13:27 camelia rakudo-moar edffe0: OUTPUT«This type cannot unbox to a native integer␤  in block <unit> at /tmp/H8tgw7B6de:1␤␤»
13:27 ShimmerFairy m: use nqp; say nqp::unbox_i(-1e35.Int)
13:27 camelia rakudo-moar edffe0: OUTPUT«0␤»
13:27 JimmyZ hmm ,what is GLR one
13:28 jnthn ShimmerFairy: Well, the robust way is just to keep mp_ints around for the positive and negative limit and compare
13:28 jnthn ShimmerFairy: Which is what I'd probably do, and leave profiling to tell us if that's really not fast enough
13:28 ShimmerFairy jnthn: I admittedly don't know what libtommath provides, so I could only think up the generalized solution :)
13:29 ShimmerFairy ("generalized" as in "library-agnostic", in this case)
13:30 ShimmerFairy I've only looked at gmp before concerning bigints, but never actually used it :P
13:48 vendethiel joined #moarvm
13:50 dalek MoarVM: 4108c94 | FROGGS++ | src/6model/reprs/P6bigint.c:
13:50 dalek MoarVM: throw "cannot unbox" when bigint is too large
13:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4108c94766
14:11 Util_ joined #moarvm
14:20 JimmyZ joined #moarvm
14:20 nwc10 jnthn: yes, agree on complexity. I wrongly assumed that the reason for the question was about storing a larger range without hitting bigints. Not about simplifying unboxing in the common case.
14:31 brrt joined #moarvm
14:37 tadzik joined #moarvm
14:40 dalek MoarVM/even-moar-jit: e3aa05c | brrt++ | src/jit/ (2 files):
14:40 dalek MoarVM/even-moar-jit: Add missing breaks and flag negation
14:40 dalek MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e3aa05cca0
16:27 brrt left #moarvm
17:36 zakharyas joined #moarvm
18:29 rurban_ joined #moarvm
21:10 vendethiel joined #moarvm
21:14 zakharyas joined #moarvm
22:39 vendethiel joined #moarvm
22:58 TEttinger joined #moarvm

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