Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-02-06

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

All times shown according to UTC.

Time Nick Message
00:00 timotimo that's right.
00:00 jnthn And could easily make for internal frag.
00:00 timotimo sure. maybe we should build an mp_init that'll get the initial size passed to it
00:01 timotimo aren't we treating mp_int as immutable anyway?
00:08 * timotimo goes to bed
00:14 * jnthn also
00:59 jnap joined #moarvm
01:23 jnap joined #moarvm
02:59 flussence joined #moarvm
03:31 flussence joined #moarvm
04:40 cognominal joined #moarvm
04:50 lue joined #moarvm
05:20 colomon joined #moarvm
06:38 cxreg joined #moarvm
07:00 FROGGS joined #moarvm
07:04 dagurval joined #moarvm
07:26 nwc10 jnthn: looks like you got the one I was hitting
07:27 nwc10 thanks
07:28 FROGGS ohh, clearly I need to backlog
07:28 FROGGS good morning
08:30 odc joined #moarvm
09:15 nwc10 jnthn++ # better than 30Gb of RAM
09:18 jnthn nwc10: yay
09:18 jnthn nwc10: Does that mean we can apply the refs_frames on STables fix?
09:19 nwc10 I believe so
09:19 nwc10 works on my machine
09:19 nwc10 not sure how much it does/doesn't speed things up
09:19 nwc10 having trouble measuring it reliably
09:19 nwc10 but go for it, although the commit message I had about "previous commit" is now a bit wrong
09:19 nwc10 was going to try the big GC change now
09:19 jnthn It was on the mailing list, yes?
09:19 nwc10 but low on sleep (couldn't sleep)
09:19 nwc10 not sure :-)
09:20 nwc10 jnthn: was definately here: http://paste.scsys.co.uk/299937
09:21 nwc10 but "previous commit" is actually bbf922e66fd7e71ef529f1624c5cdd57e3b6d90a
09:21 jnthn ah, didn't see it on the list
09:21 jnthn Thanks
09:21 nwc10 and at least one of the ohters you found was being concealed by the bug
09:21 jnthn Ugh...
09:21 nwc10 I hadn't sent it yet, because I wasn't sure that it worked
09:21 nwc10 it does now
09:21 nwc10 yes, Ugh :-(
09:21 nwc10 the torture is good at finding missing temproots
09:21 nwc10 and reasonable at write barriers
09:21 nwc10 but its "memory" is limited
09:22 * jnthn was glad to not have to get up early today
09:28 jnthn Well, just got a CORE.setting build in 60.5s, which I *think* may be lowest I've seen so far.
09:28 nwc10 one check on Linux suggested it used a tad less max memory for the setting
09:35 jnthn New best spectest time also... 296s.
09:35 nwc10 OK, so it is a win. GOod
09:35 nwc10 how fast is Hello World now? :-)
09:38 jnthn C:\consulting\rakudo>timecmd perl6-m -e "say 'Hello, world'"
09:38 jnthn Hello, world
09:38 jnthn command took 0:0:0.27 (0.27s tota
09:38 jnthn C:\consulting\rakudo>timecmd perl -E "use Moose; say 'Hello, world'"
09:38 jnthn Hello, world
09:38 jnthn command took 0:0:0.22 (0.22s tota
09:39 nwc10 they still win. :-(
09:39 nwc10 at least, "this week"
09:40 dalek MoarVM: bd1186f | nicholas++ | src/gc/roots.c:
09:40 dalek MoarVM: Should not use REPR() on an STable.
09:40 dalek MoarVM:
09:40 dalek MoarVM: The code was buggily assuming that every collectable was an Object when
09:40 dalek MoarVM: checking to see if Objects referenced frames. Not all collectables are
09:40 dalek MoarVM: Objects, but by chance of how Objects and STables are laid out in memory,
09:40 dalek MoarVM: REPR() on an STable would give a pointer to a sufficienty valid Object
09:40 dalek MoarVM: that the code didn't fail. However, a side effect of this was the code
09:40 dalek MoarVM: ends up thinking that every STable is an Object that references frames,
09:40 dalek MoarVM: and hence need to be tracked in gen2roots[]. This slows things down, and
09:40 dalek MoarVM: concealed several bugs, fixed in previous commits.
09:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bd1186f761
09:40 jnthn I think the other thing you're working on will have more impact on performance.
09:41 jnthn Since we can probably allocate around 10% more objects per GC run.
09:41 jnthn And get better cache locality due to smaller objects.
09:45 nwc10 git submodules-- # really mess with my rebase workflow
09:54 nwc10 MoarVM build time is still More Than Awesome
10:07 nwc10 jnthn: I should have found this one for you last night: http://paste.scsys.co.uk/300516
10:07 nwc10 still not sure if memcpy() is the best idea - maybe an explicit loop?
10:07 nwc10 but that's micro-optimisign
10:07 nwc10 er, memset()
10:09 jnthn Yeah, go for clarity for now. Actually, the bytecode assembler is by a long way the fastest bit of compilation right now anyway.
10:09 jnthn So it really is micro. :)
10:10 nwc10 when I'm cleaning this code up, should I take out the assert()s?
10:11 jnthn There's no cost to an optimized build to leave them in?
10:11 nwc10 I think one might need to define -DNDEBUG to remove them
10:12 jnthn If you think they'll be helpful for future debugging, I don't mind them staying.
10:12 jnthn OK, if we do that to then they can stay.
10:12 nwc10 I think that they will
10:26 jnthn 24th
10:26 jnthn oops
10:27 FROGGS 25rd
10:50 masak 26st
10:52 nwc10 jnthn: incoming to the list. enjoy :-)
10:56 nwc10 "this week" :-)
10:57 dalek MoarVM/nwc10/feature/gc-header-shrink: d713ab9 | nicholas++ | src/gc/collect.c:
10:57 dalek MoarVM/nwc10/feature/gc-header-shrink: In process_worklist(), assert() that various assignments are unneeded.
10:57 dalek MoarVM/nwc10/feature/gc-header-shrink:
10:57 dalek MoarVM/nwc10/feature/gc-header-shrink: Also assert that if the pointer is in to-space already, it is never marked as
10:57 dalek MoarVM/nwc10/feature/gc-header-shrink: gen2.
10:58 moritz for the convenince of the moarvm hackers, I've imported all those patches into a branch
10:58 moritz ... and killed dalek :-)
10:58 nwc10 thanks
10:58 dalek joined #moarvm
10:58 nwc10 there were only 10
10:59 moritz dalek doesn't rate-limit
10:59 moritz and freenode kicks :-)
11:00 dalek MoarVM: 96e503b | nicholas++ | src/mast/compiler.c:
11:00 dalek MoarVM: In form_string_heap(), ensure that the padding bytes are initialised.
11:00 dalek MoarVM:
11:00 dalek MoarVM: Whilst we never read this memory, it's useful to ensure it is initialised,
11:00 dalek MoarVM: otherwise valgrind (and similar tools) will rightly complain that we're
11:00 dalek MoarVM: writing garbage to disk.
11:00 dalek MoarVM:
11:00 dalek MoarVM: With this change, compiling the setting runs without error under valgrind.
11:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/96e503b986
11:11 FROGGS nice!
11:11 FROGGS nwc10++
11:13 jnthn nwc10: Did you include a patch to add -DNODEBUG?
11:13 nwc10 jnthn: no.
11:13 nwc10 can I delegate that to FROGGS? :-)
11:14 FROGGS wut?
11:14 FROGGS so, every assert() should be #ifndef'd by NODEBUG ?
11:15 FROGGS is it common to use NODEBUG instead of the opposite?
11:16 nwc10 FROGGS: no, look at /usr/include/assert.h
11:16 jnthn FROGGS: No, you just need to add the define
11:16 nwc10 if you define NDEBUG
11:16 jnthn I dunno how things are on MSVC by default
11:16 nwc10 not NODEBUG
11:16 FROGGS ahh
11:16 jnthn OK
11:16 jnthn CORE.setting memory consumption is less :)
11:16 nwc10 that was the plan.
11:17 nwc10 "I love it when a plan comes together"
11:17 FROGGS and it gets built in like no time?
11:17 nwc10 (I'll skip the cigar. Could i just have a whisky instead?)
11:17 nwc10 but not right now as I feel a bit crap
11:17 FROGGS no cigar no whisky, sir
11:17 jnthn nwc10: And...you finally broke 1 minute CORE.setting build time on my box \o/
11:17 nwc10 Awesome
11:17 nwc10 you'll have lots of time for bloggage :-)
11:17 jnthn And a little time off startup too
11:17 jnthn Down to 0.24s.
11:18 nwc10 Moose still wins?
11:18 jnthn By 0.02s.
11:18 nwc10 getting there. But would it be easier to send patches to knobble Moose? :-)
11:18 nwc10 don't tell anyone
11:18 jnthn lemme do a spectest time :)
11:19 FROGGS jnthn: what perl is that you're using for the moose test?
11:20 * FROGGS guesses it is an ActiveState 5.14 or so
11:24 jnthn Another 7s off
11:24 jnthn 289s.
11:24 jnthn And it may be the asserts are running
11:24 nwc10 probably
11:24 nwc10 and those non-inline functions
11:24 nwc10 which could probably go
11:25 jnthn FROGGS: yeah, looks like
11:26 FROGGS jnthn: before you blog about MoarVM beating Moose, let us compare the timings against a 5.18 or better, okay? :o)
11:26 jnthn nwc10++
11:26 jnthn This is great work.
11:26 jnthn Also I see 5MB more off memory use of a single Rakudo.
11:26 FROGGS and then again, our threads suck *g*
11:26 * FROGGS hides
11:26 jnthn FROGGS: We're not beating it yet. :)
11:27 jnthn FROGGS: But yes, if we're going to say that it'll need careful analysis.
11:27 jnthn FROGGS: What's the status on char name lookup stuff? You gave up debugging it for now?
11:28 FROGGS yes, I gave up
11:28 FROGGS :/
11:28 FROGGS maybe I can continue after a diakopterish brainstorming
11:28 FROGGS lunch &
11:29 nwc10 got through NQP on an x86 Debian system
11:29 nwc10 so runs on both kinds of OS and both kinds of architecture :-)
11:29 jnthn ;)
11:38 nwc10 I don't know how good our "timing" setup is.
11:38 nwc10 In that, objects are (I think) often larger than a CPU cache line
11:39 nwc10 and flags is accessed often, but serialisation context not so often
11:39 nwc10 so I wondered if putting that union at the start would help reduce L1 cache misses a tad
11:40 jnthn Hm, interesting thought...
11:40 nwc10 x86 Linux max RSS for setting down by 6.8%
11:40 jnthn It'd be sort-of nice to do away with ->sc entirely
11:41 jnthn I'm just not sure how best to do it.
11:41 jnthn I mean, we'd have to maintain a huge lookup table somewhere.
11:41 nwc10 I don't know if it wins you anything
11:41 jnthn Could use a flag bit for "is it in an SC" I guess
11:41 jnthn It wins you another pointer off every runtime-created object...
11:42 nwc10 I don't know if the forwarder can share memory with anything else, during GC rns
11:45 jnthn Well, you evacuate the entire object before writing ->forwarder into the old one...
11:45 nwc10 OK. You still need the falgs
11:45 nwc10 flags
11:45 jnthn Right
11:46 jnthn But you can use the body
11:46 nwc10 so you're talking about re-using the space for the REPR or the STABLE
11:46 nwc10 or yes, the body
11:46 jnthn You know a collectable is either an object or an STable.
11:46 jnthn So then there's always at least a pointer's worth in the body, even if it's a type object
11:47 jnthn A full NQP build is now 50s and a Rakudo one 92s on my box.
11:47 nwc10 I seem to be fighting with rsync on the x86 machine
11:47 nwc10 (which is http://cpan.etla.org/ )
11:47 nwc10 so I can't get an idea of CPU change
11:50 jnthn +    MVM_CF_IN_GEN2_ROOT_LIST = 32,
11:50 jnthn +
11:50 jnthn +    /* GC has found this object to be live. */
11:50 jnthn +    MVM_CF_SECOND_GEN_LIVE = 64
11:50 jnthn Mighta been more consistent to name the second flag MVM_CF_GEN2_LIVE :)
11:50 nwc10 yes, I didn't think of that.
11:51 * nwc10 goes for noms
11:52 jnthn Really happy about the cleanup in +    MVM_CF_IN_GEN2_ROOT_LIST = 32,
11:52 jnthn +
11:52 jnthn +    /* GC has found this object to be live. */
11:52 jnthn argh
11:53 jnthn Really happy about the cleanup in 3ca1fcd74 also.
12:10 timotimo o/
12:10 timotimo i see we're improving speed and memory usage today
12:21 timotimo when exactly do we need to look at the sc anyway? only when we want to serialize out some stuff, right?
12:23 jnthn There's the SC write barriers too
12:23 timotimo ah, that's for reposession?
12:23 jnthn But that doesn't need the SC itself
12:24 jnthn At least, in the common "it's not in one" case
12:24 jnthn timotimo: Correct
12:24 timotimo the most optimal thing we could do is to only store the sc in the objects if we know we're meaning to serialize out what we're building at the end :P
12:32 jnthn Anyway, I think that there's probably bigger wins to be had for now.
12:32 timotimo probably
12:33 * timotimo casts Summon Bigger Fish
12:37 * jnthn needs to do a few more $dayjob things for a bit
12:38 tadzik timotimo: ask and you shall receive :P http://3.bp.blogspot.com/_QcNJfTQTukE/TK-78gmnwdI/AAAAAAAAAF0/Uec0EpW4En8/s1600/trade4.JPG
12:38 timotimo hehe.
12:40 nwc10 jnthn: problem I see with "big hash" is that it's probably 3 pointers of storage for every SC pointer saved
12:40 nwc10 best hack I could think of over lunch was
12:40 nwc10 0) wait until we have inline functions so that we can assert a bunch of sanity
12:41 nwc10 1) for nursery objects, store the SC in the pointer before the object. This avoids issues about moving
12:41 nwc10 2) for oversized objects, store the SC in the pointer before the object. This just makes life simpler
12:41 nwc10 3) for everything gen2, have two sets of storage, one for things with SC, one for things without
12:41 nwc10 oh, and typing this in, I guess
12:41 nwc10 "store the SC in the pointer before it" which is simpler than the plan I had
12:42 nwc10 but I'm not going to hack on this this month. Or maybe next.
12:46 jnthn *nod*
12:46 jnthn Yeah...it's trickier to get a win on this.
12:52 nwc10 but it feels like a hack
12:53 nwc10 and there's probably cleaner low hanging fruit to be plucked
12:53 jnthn indeed
14:14 jnthn Pro tip: before wondering why your benchmark is so slow, make sure it doesn't contain an infinite loop.
14:14 jnthn Even the CLR doesn't do *those* fast...
14:14 nwc10 :-)
14:19 jnap joined #moarvm
14:20 * masak .oO( why does that joke never get old? because it never terminates! )
14:36 jnthn Typically, I managed to get the infinite loop in the locking code, not the lock-free code...
14:39 moritz lock-free xor loop-free
14:49 ggoebel1114 joined #moarvm
14:51 jnthn walk &
14:53 timotimo run &
15:04 tadzik sleep &
15:05 FROGGS work &
15:11 masak eat, pray, love &
15:22 jnthn ..
15:22 moritz &&&
15:24 * jnthn now has beer in le fridge again :)
15:30 nwc10 yay!
15:30 nwc10 I have me in the bed, because that feels the best place
15:30 nwc10 jnthn: had a thought on the way home - hiding the SC *before* the collectable doesn't work, as the code needs to march through the nursery based on size
15:30 nwc10 but hiding it at the end would work
15:31 nwc10 the complication is that you have to know at allocation time whether you need a space for a SC
15:31 nwc10 (could just arrange for everything in the nursery to have space for one, and tidy up at gen2 promotion)
15:31 nwc10 all feels like a hack
15:31 nwc10 improving code gen, unblocking Panda and unblocking Star seem to be more important
15:32 nwc10 $
15:34 jnthn Yeah. If it's speed and memory wins we're after, the Int improvements are more worthwhile.
15:35 jnthn And yes, code-gen improvements.
15:37 timotimo lol, i jogg'd
15:57 FROGGS *g*
16:20 colomon joined #moarvm
17:03 rurban_ joined #moarvm
17:46 cognominal joined #moarvm
18:14 dalek MoarVM: 22cfff8 | nicholas++ | src/gc/collect.c:
18:14 dalek MoarVM: In process_worklist(), assert() that various assignments are unneeded.
18:14 dalek MoarVM:
18:14 dalek MoarVM: Also assert that if the pointer is in to-space already, it is never marked as
18:14 dalek MoarVM: gen2.
18:14 dalek joined #moarvm
18:15 dalek MoarVM: e05bf62 | jnthn++ | build/setup.pm:
18:15 dalek MoarVM: Define NDEBUG in optimized builds.
18:15 dalek MoarVM:
18:15 dalek MoarVM: Means that we will not check assert()s introduced in recent commits in
18:15 dalek MoarVM: optimized builds.
18:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e05bf62e73
18:18 dalek MoarVM: 0f2077b | jnthn++ | src/ (5 files):
18:18 dalek MoarVM: Rename a flag for consistency.
18:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0f2077b980
18:20 jnthn nwc10: Failed to find a way your work wasn't an improvement, so it's in. Also did the NDEBUG thing and the flag rename I mentioned earlier.
18:26 nwc10 Cool, thanks for tidying it up
18:28 jnthn Thanks for doing the hard work :)
18:28 nwc10 thanks for the couple of key insights and fixes that got me unstuck
18:32 FROGGS joined #moarvm
18:35 * PerlJam idly wonders if TPF would sponsor work on moarvm via the hague grants
18:36 PerlJam (of course, that presumes also that there is some hague money left)
19:04 camelia joined #moarvm
19:17 nwc10 does anyone have a good idea of what things block Panda working on Moar? And what things block Star?
19:17 FROGGS NativeCall blocks Star
19:17 nwc10 it's a bit frustrating that Moar isn't able to take its place alongside Parrot as a first class backend for "end users"
19:18 FROGGS and I'd guess that openpipe might block panda
19:18 nwc10 ah
19:18 nwc10 and sockets?
19:18 FROGGS ohh, yeah
19:22 jnthn yeah, and sockets
19:23 jnthn And our handful of failing tests
19:27 nwc10 so it's not massive, but 3 parts are quite hard
19:27 nwc10 and likely to scare peope away from attempting them
19:28 FROGGS I hope that openpipe will be done this weekend
19:28 nwc10 and then Panda can be tested with local tarballs?
19:29 FROGGS I dunno
19:29 nwc10 OK. I'll stop asking stupid questions :-)
19:29 FROGGS hehe
19:29 FROGGS :o)
21:03 dalek MoarVM/jnthn_bigint_opt: dd8c35e | jnthn++ | src/ (3 files):
21:03 dalek MoarVM/jnthn_bigint_opt: Start holding mp_int * in P6bigint.
21:03 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/dd8c35e71e
21:04 timotimo but i had code to do that, too
21:04 timotimo you didn't need to re-do that
21:04 jnthn oh...
21:05 jnthn I...didn't think it was working?
21:05 timotimo too late now
21:05 timotimo it works all right
21:05 timotimo it's essentially the same thing you have now plus a bit of WIP stuff that doesn't work at all yet
21:05 jnthn oh...
21:05 jnthn OK.
21:05 * jnthn is trying to do little steps towards working
21:06 jnthn as in, working 32-bit storage
21:07 timotimo oh
21:07 timotimo i have that, too
21:07 timotimo sorry about forgetting that
21:07 timotimo er ... that is ... i have a union that does the thing on 32bit and 64bit systems and little/big endian
21:08 jnthn Yeah, I more meant actually storing stuff that way?
21:09 timotimo yeah, that i do not have yet
21:09 jnthn Anyway, gimme a bit more time...I'll see if I can get this working-ish.
21:09 timotimo it seemed like a huge blob of work without a good handle to pull at
21:09 timotimo or a loose thread to start unraveling the whole thing at
21:11 jnthn Yeah, that's kinda why I've jumped in. I could see it was being a frustrating amount of effort, when I'd hoped it would be a relatively isolated and not horrible task.
21:11 dalek MoarVM/wip-openpipe: a594b94 | (Tobias Leich)++ | src/io/procops.c:
21:11 dalek MoarVM/wip-openpipe: disable hacky :rp/:wp switch
21:11 dalek MoarVM/wip-openpipe: review: https://github.com/MoarVM/MoarVM/commit/a594b945ef
21:11 dalek MoarVM/wip-openpipe: 03647f4 | (Tobias Leich)++ | src/io/procops.c:
21:11 dalek MoarVM/wip-openpipe: openpipe spawns using a shell
21:11 dalek MoarVM/wip-openpipe: review: https://github.com/MoarVM/MoarVM/commit/03647f47ec
21:11 dalek MoarVM/wip-openpipe: 9652087 | (Tobias Leich)++ | src/io/procops.c:
21:11 dalek MoarVM/wip-openpipe: disable ipc communication, this blows up on windows
21:11 dalek MoarVM/wip-openpipe: review: https://github.com/MoarVM/MoarVM/commit/9652087f67
21:11 dalek MoarVM/wip-openpipe: e92e012 | (Tobias Leich)++ | src/ (2 files):
21:11 dalek MoarVM/wip-openpipe: use uv_process_close on windows (instead of waitpid)
21:11 dalek MoarVM/wip-openpipe: review: https://github.com/MoarVM/MoarVM/commit/e92e012085
21:12 FROGGS C:\MoarVM>perl6-m -e "say +qx{dir}.lines"
21:12 FROGGS 39
21:12 FROGGS $ perl6-m -e 'say +qqx{ls}.lines'
21:12 FROGGS 49
21:13 jnthn \o/
21:13 FROGGS jnthn: I decided to make qx{} work and care about IO::Pipe later
21:13 jnthn ok :)
21:13 FROGGS so we can only read its stdout atm
21:14 FROGGS I'll deal with upcoming issues when panda needs more functionality :o)
21:14 timotimo sounds great, though!
21:15 FROGGS would be nice if someone could review the branch in MoarVM and rakudo
21:15 FROGGS https://github.com/MoarVM/MoarVM/compare/wip-openpipe
21:15 FROGGS https://github.com/rakudo/rakudo/compare/wip-openpipe
21:17 FROGGS I am too tired to spot any issues
21:18 FROGGS so everybody please be extra careful
21:37 dalek MoarVM/jnthn_bigint_opt: 4078a7c | jnthn++ | src/ (3 files):
21:37 dalek MoarVM/jnthn_bigint_opt: Introduce union for holding smallint in P6bigint.
21:37 dalek MoarVM/jnthn_bigint_opt:
21:37 dalek MoarVM/jnthn_bigint_opt: Not using the smallint part yet.
21:37 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/4078a7cb0e
21:37 dalek MoarVM/jnthn_bigint_opt: 8e9761e | jnthn++ | src/6model/reprs/P6bigint. (2 files):
21:37 dalek MoarVM/jnthn_bigint_opt: Teach a few things to handle smallint case.
21:37 dalek MoarVM/jnthn_bigint_opt:
21:37 dalek MoarVM/jnthn_bigint_opt: We never actually create that case yet, so really we can only test the
21:37 dalek MoarVM/jnthn_bigint_opt: checking code doesn't get false positives so far.
21:37 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/8e9761efb3
21:39 lizmat_ joined #moarvm
22:12 dalek MoarVM/jnthn_bigint_opt: b930b29 | jnthn++ | src/math/bigintops.c:
22:12 dalek MoarVM/jnthn_bigint_opt: Make get_bigint complain if it sees a smallint.
22:12 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/b930b295c3
22:12 dalek MoarVM/jnthn_bigint_opt: 182960c | jnthn++ | src/6model/reprs/P6bigint.c:
22:12 dalek MoarVM/jnthn_bigint_opt: Start producing smallint for empty and box cases.
22:12 dalek MoarVM/jnthn_bigint_opt:
22:12 dalek MoarVM/jnthn_bigint_opt: At this point, everything fails in an orderly way, with "Incomplete
22:12 dalek MoarVM/jnthn_bigint_opt: smallint handling!". The task from here is just to fix things until
22:12 dalek MoarVM/jnthn_bigint_opt: we never see this error again. :-)
22:12 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/182960c2dd
22:29 dalek MoarVM/jnthn_bigint_opt: d1246e5 | jnthn++ | src/math/bigintops.c:
22:29 dalek MoarVM/jnthn_bigint_opt: Handle smallint in bigint to/from string.
22:29 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/d1246e5394
22:30 jnthn That's the first 5 of 60-bigint.t passing again. :)
22:32 timotimo i would love to continue your work now, but i've contracted quite a sizable headache today
22:32 jnthn timotimo: I'll do a little bit more, then :)
22:32 timotimo so i'm taking the next tram home and getting a bunch of sleep
22:32 jnthn timotimo: Get well soon
22:33 timotimo i'll give it my all
22:34 timotimo actually i'll have to wait another 10 minutes
22:34 timotimo so i'll let dalek make me happy with good news :3
23:28 dalek MoarVM/jnthn_bigint_opt: 5e5e592 | jnthn++ | src/6model/reprs/P6bigint.h:
23:28 dalek MoarVM/jnthn_bigint_opt: Fix "fits in 32 bits" test.
23:28 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/5e5e592776
23:28 dalek MoarVM/jnthn_bigint_opt: 90160f3 | jnthn++ | src/math/bigintops.c:
23:28 dalek MoarVM/jnthn_bigint_opt: Add smallint handling to various basic ops.
23:28 dalek MoarVM/jnthn_bigint_opt:
23:28 dalek MoarVM/jnthn_bigint_opt: Gets us up to 8 passing tests in NQP's 60-bigint.t. Also adds much of
23:28 dalek MoarVM/jnthn_bigint_opt: the infrastructure we will need to do the rest.
23:28 dalek MoarVM/jnthn_bigint_opt: review: https://github.com/MoarVM/MoarVM/commit/90160f362b
23:30 jnthn timotimo: Hopefully I've done enough so far to show a way forward.
23:31 jnthn timotimo: Some things we'll likely want to take the force_bigint approach on.
23:32 timotimo thank you, that seems like a good foundation to work with
23:32 timotimo i'll hit the hay now
23:33 jnthn Rest well, feel better.
23:33 timotimo that's the plan, anyway :)
23:33 jnthn :)
23:34 timotimo how do you feel about using the mp_foobar_d forms if we have a big int and a smallint?
23:35 timotimo it *might* not be safe depending on the data format used for mp_digit, though
23:35 timotimo but we might get around allocating a bigint in a bunch of cases where we do things with one big and one small int
23:36 timotimo imagine a for loop that adds 1 in every iteration and starts in the big integer range, for example
23:37 timotimo anyway. mandatory bedrest now :P
23:40 jnthn timotimo: We *could* but I thought the code was already involved enough with the two cases.
23:40 timotimo that's true. there'd have to be measurements.
23:40 jnthn timotimo: And I think that case will be quite rare too
23:41 timotimo maybe it'd also be something worth considering in the specializer
23:41 timotimo if that's possible at all in a non-tracing jit type of deal
23:41 jnthn Doing a loop up to 2147483647 is rather large...
23:41 timotimo oh well. now that you phrase it that way :)
23:41 * timotimo disappears in a puff of optimism
23:42 jnthn o/

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