Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-09-03

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

All times shown according to UTC.

Time Nick Message
00:08 timotimo interesting, we have a few instances of const_s followed by getattrs_
00:19 dalek MoarVM: 591d294 | (Timo Paulssen)++ | src/jit/graph.c:
00:19 dalek MoarVM: fix bindattrs_*, implement getattrs_*, simplify getattr_*
00:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/591d294993
00:24 timotimo tomorrow i can probably teach spesh to turn getattrs_* and bindattrs_* into getattr_* and bindattr_* and give them hints, or a spesh cache.
00:25 timotimo hum. it kinda seems like it should already do something like that
00:28 timotimo could very well be it just can't find the slot with try_get_slot or something like that. oh well.
01:02 FROGGS_ joined #moarvm
01:10 avuserow joined #moarvm
01:27 avuserow joined #moarvm
01:50 dalek MoarVM: 1157bb4 | (Timo Paulssen)++ | src/jit/graph.c:
01:50 dalek MoarVM: implement coerce_In in the jit
01:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1157bb440b
01:50 dalek MoarVM: e3580a7 | (Timo Paulssen)++ | src/jit/graph.c:
01:50 dalek MoarVM: implement div_In in the jit
01:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e3580a7c9b
01:52 timotimo tomorrow i'll go for brshift_i and blshift_i
02:02 diakopter those should be the easiest ones ever
03:48 avuserow timotimo: what command are you trying to run that needs tons of memory? I might be able to spin up a large machine at $work
03:49 avuserow if it's something simple, I can possibly help up to about 40GB
07:41 zakharyas joined #moarvm
08:07 kjs_ joined #moarvm
08:30 sergot hi o/
08:41 kjs_ joined #moarvm
09:16 timotimo avuserow: supplying --profile-compile to the compilation of the core setting
09:17 FROGGS pain! I tell ya
09:17 timotimo diakopter: they should be, aye :)
09:18 FROGGS I try to register an error handler (a callback) for libxml2, but the signature of that callback has varargs :/
09:32 timotimo haven't had to do that yet, dunno how dyncall models that
10:18 kjs_ joined #moarvm
10:19 timotimo at this point, it seems like i'm just hunting ops that have very few bails across the existing code as a whole
10:19 timotimo brshift_I and blshift_I are probably more common anyway
10:20 timotimo well, except maybe if you build tight native code in your perl6
10:28 timotimo i wonder how we can put the "are the arguments to this bigint op both smallbigints? if so, just do the peration quickly, otherwise call the c function" into the jit without implementing every bigint op twice: once for a smalling/bigint, once for an only bigint
10:30 timotimo but that's probably for later
10:34 timotimo jnthn: remember the thing about "smart numify + coerce n to i", how can i make sure the num register won't survive until the next deopt point without doing a scan for it?
10:36 timotimo hmm. here i have a const_i64_16 that gets coerced to a num and then compared with the smrt_numify result
10:37 timotimo but the const is just "-1", so it could just as well have been an unbox int thingie (if that's supported by the object we're trying to numify)
10:40 timotimo oh
10:40 timotimo actually
10:41 timotimo i can use the dead code elimination to my advantage
10:41 timotimo if i think only the int will be used, i can make the smrt_numify unbox an int and create the num with a coerce_in and if the num isn't used at all, the coerce will just be killed
10:42 timotimo but i don't know when to prefer the int and when to prefer the num in the "general" case (as in: the object can unbox an int or a num)
10:45 kjs_ joined #moarvm
10:51 FROGGS[mobile] joined #moarvm
11:11 jnthn timotimo: The other way is to look at usages
11:11 jnthn If it's 1, you know you're looking at the only usage :)
11:12 jnthn (that is, that the coerce is the sole consumer of the smrt_numify result)
11:18 oetiker joined #moarvm
11:27 dalek MoarVM: 4a86098 | Carlin++ | src/ (4 files):
11:27 dalek MoarVM: add wrapper functions to panic if allocation fails
11:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4a86098f1a
11:27 dalek MoarVM: 176cec9 | Carlin++ | / (81 files):
11:27 dalek MoarVM: replace malloc with MVM_malloc
11:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/176cec9fd8
11:27 dalek MoarVM: 3819ce2 | Carlin++ | / (68 files):
11:27 dalek MoarVM: replace free with MVM_free
11:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3819ce2877
11:27 dalek MoarVM: 9e95260 | Carlin++ | src/ (28 files):
11:27 dalek MoarVM: replace realloc with MVM_realloc
11:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9e95260a3b
11:40 carlin \o/ yay
11:53 sergot carlin++
12:18 carlin Stage parse      : Memory allocation failed; could not allocate 524288 bytes
12:18 * carlin sniffs
12:18 carlin it's beutiful
12:34 FROGGS[mobile] *g*
12:34 FROGGS[mobile] carlin++
12:36 moritz you don't have 524k RAM on your box? :-)
12:36 moritz (just kidding, of course)
12:46 FROGGS[mobile] joined #moarvm
13:10 odc` joined #moarvm
13:38 jnthn I think the first box I programmed might not actually have had that much :P
13:38 jnthn How times change...
13:38 jnthn carlin++ for the patches :)
13:56 timotimo i'd also like to have a way to turn a const_n into a const_i if it's sensible, but that seems much more peepholey than what we're doing so far
13:56 timotimo to be fair, we're already spending almost 0% of time on optimization/specialization in many cases :P
13:57 jnthn On startup, though, we spend rather longer than that...
13:57 timotimo hm, right
13:57 jnthn I'm pondering some threshold tweaks.
14:00 carlin jnthn: any chance you could look at my other 2 PRs? No hurry though
14:02 jnthn Ah, I thought 132 had an issue when I looked yesterday, but now I see I misread and the ascii.c issue was actually corrected in this version.
14:02 dalek MoarVM: 3e276ba | Carlin++ | src/core/frame.c:
14:02 dalek MoarVM: flag is sometimes set to -1 so needs to be signed
14:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3e276ba953
14:02 dalek MoarVM: 1cf18d2 | Carlin++ | src/core/bytecode.c:
14:02 dalek MoarVM: unsigned int offset can never be less than 0
14:03 jnthn sorry, dalek
14:03 jnthn Anyway, that's one more down
14:03 diakopter poor, poor dalek
14:03 dalek joined #moarvm
14:05 jnthn Hm. Is it really sane to expose SIGSEGV as hookable? :)
14:06 nwc10 IIRC it's undefined behaviour for a program to continue after a SEGV
14:06 nwc10 and a couple of the others
14:06 jnthn Well, if you continue then you really better have done something about the situation.... :)
14:07 jnthn I'm quite certain userland code ain't in such a position.
14:07 timotimo aye. but what we do when you tap a signal is to put that into a queue or something for another thread to handle it
14:07 timotimo so it'll basically immediately continue before the userland code has a chance to run
14:07 jnthn Yes, that seems like an exceptionally crazy thing to do for SIGSEGV :)
14:07 jnthn SIGBUS is probably similar
14:08 jnthn nwc10: ooc, what does Perl 5 do in terms of signals you can install handlers for?
14:08 nwc10 I can't remember
14:08 jnthn ok :)
14:08 nwc10 I believe that you can install handler for all of them
14:08 carlin perl -e "\$SIG{SEGV} = sub { die 'foo' }; for (;;) {}"
14:08 nwc10 no-one said that it's sane
14:09 carlin kill -SEGV 8545
14:09 carlin foo at -e line 1
14:09 timotimo sending a SEGV manually is cheating :P
14:09 jnthn o.O :)
14:09 timotimo also, in a signal handler, isn't the stuff you're allowed to do very, very, very limited?
14:25 carlin so I should remove the ones we can't realistically deal with? SEGV, BUS, KILL, STKFLT
14:30 timotimo i'd say: allow users to shoot their own foot
14:33 jnthn m: say 10955 - 4848
14:33 camelia rakudo-moar 41d7f7: OUTPUT«6107␤»
14:33 jnthn m: say (10955 - 4848) * 40
14:33 camelia rakudo-moar 41d7f7: OUTPUT«244280␤»
14:34 timotimo i see numbers ... do i have a reason to cheer? :)
14:45 itz joined #moarvm
14:58 itz_ joined #moarvm
15:03 itz joined #moarvm
15:48 itz_ joined #moarvm
15:53 itz joined #moarvm
16:05 hoelzro_ joined #moarvm
16:06 [Coke]_ joined #moarvm
16:06 Juerd_ joined #moarvm
16:09 camelia joined #moarvm
17:30 avuserow timotimo: so far, adding --profile-compile is "only" using 11GB of memory or so
17:31 timotimo oh!
17:32 avuserow been running for 13 minutes of now, though
17:34 zakharyas joined #moarvm
17:39 avuserow oh, I may not have allocated enough disk space for this. silly installer, allocating 40GB of swap space by default.
17:39 avuserow if not, I'll give it more disk space and re-run
17:44 cognome joined #moarvm
17:49 kjs_ joined #moarvm
17:56 itz joined #moarvm
19:00 itz joined #moarvm
19:06 moritz http://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/ might be of idle interest
19:14 nine moritz: nice!
19:21 timotimo i may hack this to make it place the addresses along a hilbert curve to get rid of the "line breaks"
19:23 zakharyas joined #moarvm
19:28 itz_ joined #moarvm
19:35 itz joined #moarvm
20:11 avuserow timotimo: this is still running O.o
20:11 avuserow I've now seen it use as much as 21GB. It seems to fluctuate a lot.
20:11 timotimo :D
20:11 timotimo i told you :)
20:12 avuserow still no idea if it'll have enough disk space to write out the data :(
20:16 timotimo right ;(
20:16 timotimo and then it'll be quite interesting to see if any browser whatsoever will be able to render that data out ...
20:18 avuserow yeah, might not even be feasible to load the entire page into memory on many machines, much less do any javascript stuff
20:18 vendethiel b-but I thought angular was web scale :-)
20:18 timotimo yeah, but this is already Big Data
20:19 avuserow it'll still be interesting to see how large it is, and maybe some information can be gathered using a streaming json parser or something...
20:19 avuserow or at least ideas on where to cut things down
20:20 timotimo aye.
20:20 timotimo i briefly glanced at the code that generates the data
20:20 timotimo it does have to walk a tree to sum up the times, so i'm not quite sure how to cut the call graphs down to size ...
20:46 colomon joined #moarvm
20:47 Ven joined #moarvm
21:44 colomon joined #moarvm

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