timotimo interesting, we have a few instances of const_s followed by getattrs_ 00:08
dalek arVM: 591d294 | (Timo Paulssen)++ | src/jit/graph.c:
fix bindattrs_*, implement getattrs_*, simplify getattr_*
 00:19
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:24
hum. it kinda seems like it should already do something like that 00:25
could very well be it just can't find the slot with try_get_slot or something like that. oh well. 00:28
01:02 FROGGS_ joined 01:10 avuserow joined 01:27 avuserow joined
dalek arVM: 1157bb4 | (Timo Paulssen)++ | src/jit/graph.c:
implement coerce_In in the jit
 01:50
arVM: e3580a7 | (Timo Paulssen)++ | src/jit/graph.c:
implement div_In in the jit
timotimo tomorrow i'll go for brshift_i and blshift_i 01:52
diakopter those should be the easiest ones ever 02:02
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:48
if it's something simple, I can possibly help up to about 40GB 03:49
07:41 zakharyas joined 08:07 kjs_ joined
sergot hi o/ 08:30
08:41 kjs_ joined
timotimo avuserow: supplying --profile-compile to the compilation of the core setting 09:16
FROGGS pain! I tell ya 09:17
timotimo diakopter: they should be, aye :)
FROGGS I try to register an error handler (a callback) for libxml2, but the signature of that callback has varargs :/ 09:18
timotimo haven't had to do that yet, dunno how dyncall models that 09:32
10:18 kjs_ joined
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
brshift_I and blshift_I are probably more common anyway
well, except maybe if you build tight native code in your perl6 10:20
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:28
but that's probably for later 10:30
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:34
hmm. here i have a const_i64_16 that gets coerced to a num and then compared with the smrt_numify result 10:36
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:37
oh 10:40
actually
i can use the dead code elimination to my advantage 10:41
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
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:42
10:45 kjs_ joined 10:51 FROGGS[mobile] joined
jnthn timotimo: The other way is to look at usages 11:11
If it's 1, you know you're looking at the only usage :)
(that is, that the coerce is the sole consumer of the smrt_numify result) 11:12
11:18 oetiker joined
dalek arVM: 4a86098 | Carlin++ | src/ (4 files):
add wrapper functions to panic if allocation fails
 11:27
arVM: 176cec9 | Carlin++ | / (81 files):
replace malloc with MVM_malloc
arVM: 3819ce2 | Carlin++ | / (68 files):
replace free with MVM_free
arVM: 9e95260 | Carlin++ | src/ (28 files):
replace realloc with MVM_realloc
carlin \o/ yay 11:40
sergot carlin++ 11:53
carlin Stage parse : Memory allocation failed; could not allocate 524288 bytes 12:18
carlin sniffs
it's beutiful
FROGGS[mobile] *g* 12:34
carlin++
moritz you don't have 524k RAM on your box? :-) 12:36
(just kidding, of course)
12:46 FROGGS[mobile] joined 13:10 odc` joined
jnthn I think the first box I programmed might not actually have had that much :P 13:38
How times change...
carlin++ for the patches :)
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
to be fair, we're already spending almost 0% of time on optimization/specialization in many cases :P
jnthn On startup, though, we spend rather longer than that... 13:57
timotimo hm, right
jnthn I'm pondering some threshold tweaks.
carlin jnthn: any chance you could look at my other 2 PRs? No hurry though 14:00
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 arVM: 3e276ba | Carlin++ | src/core/frame.c:
flag is sometimes set to -1 so needs to be signed
MoarVM: 1cf18d2 | Carlin++ | src/core/bytecode.c:
MoarVM: unsigned int offset can never be less than 0
jnthn sorry, dalek 14:03
Anyway, that's one more down
diakopter poor, poor dalek
14:03 dalek joined
jnthn Hm. Is it really sane to expose SIGSEGV as hookable? :) 14:05
nwc10 IIRC it's undefined behaviour for a program to continue after a SEGV 14:06
and a couple of the others
jnthn Well, if you continue then you really better have done something about the situation.... :)
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
so it'll basically immediately continue before the userland code has a chance to run
jnthn Yes, that seems like an exceptionally crazy thing to do for SIGSEGV :)
SIGBUS is probably similar
nwc10: ooc, what does Perl 5 do in terms of signals you can install handlers for? 14:08
nwc10 I can't remember
jnthn ok :)
nwc10 I believe that you can install handler for all of them
carlin perl -e "\$SIG{SEGV} = sub { die 'foo' }; for (;;) {}"
nwc10 no-one said that it's sane
carlin kill -SEGV 8545 14:09
foo at -e line 1
timotimo sending a SEGV manually is cheating :P
jnthn o.O :)
timotimo also, in a signal handler, isn't the stuff you're allowed to do very, very, very limited?
carlin so I should remove the ones we can't realistically deal with? SEGV, BUS, KILL, STKFLT 14:25
timotimo i'd say: allow users to shoot their own foot 14:30
jnthn m: say 10955 - 4848 14:33
camelia rakudo-moar 41d7f7: OUTPUTĀ«6107ā¤Ā»
jnthn m: say (10955 - 4848) * 40
camelia rakudo-moar 41d7f7: OUTPUTĀ«244280ā¤Ā»
timotimo i see numbers ... do i have a reason to cheer? :) 14:34
14:45 itz joined 14:58 itz_ joined 15:03 itz joined 15:48 itz_ joined 15:53 itz joined 16:05 hoelzro_ joined 16:06 [Coke]_ joined, Juerd_ joined 16:09 camelia joined
avuserow timotimo: so far, adding --profile-compile is "only" using 11GB of memory or so 17:30
timotimo oh! 17:31
avuserow been running for 13 minutes of now, though 17:32
17:34 zakharyas joined
avuserow oh, I may not have allocated enough disk space for this. silly installer, allocating 40GB of swap space by default. 17:39
if not, I'll give it more disk space and re-run
17:44 cognome joined 17:49 kjs_ joined 17:56 itz joined 19:00 itz joined
moritz spin.atomicobject.com/2014/09/03/vi...lgorithms/ might be of idle interest 19:06
nine moritz: nice! 19:14
timotimo i may hack this to make it place the addresses along a hilbert curve to get rid of the "line breaks" 19:21
19:23 zakharyas joined 19:28 itz_ joined 19:35 itz joined
avuserow timotimo: this is still running O.o 20:11
I've now seen it use as much as 21GB. It seems to fluctuate a lot.
timotimo :D
i told you :)
avuserow still no idea if it'll have enough disk space to write out the data :( 20:12
timotimo right ;( 20:16
and then it'll be quite interesting to see if any browser whatsoever will be able to render that data out ...
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 :-)
timotimo yeah, but this is already Big Data
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
or at least ideas on where to cut things down
timotimo aye. 20:20
i briefly glanced at the code that generates the data
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 20:47 Ven joined 21:44 colomon 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!