01:14 colomon joined 01:17 vendethiel joined 01:48 ilbot3 joined 02:22 colomon joined 02:45 colomon joined 04:09 flaviusb joined 06:18 FROGGS joined 07:26 zakharyas joined 08:09 FROGGS_ joined 09:16 Ven joined 09:53 Ven joined 10:39 colomon_ joined 12:08 brrt joined
brrt \o 12:08
timotimo: for all cases of non-jitting, bindexception* to sp_bind_* ops is a pessimization 12:09
which is probably why they haven't been implemented
yet
hadn't
anyway 12:10
i'd appreciate it if we split the question 'why does this not inline' from the question 'lets implement JIT ops' 12:11
so as to keep the patch set as small as can be achieved
timotimo yes, sorry, i got a bit carried away putting all my stuff into the same branch ;) 12:12
why is sp_bind_* a pessimization? 12:13
brrt because (in the interpreter) when you do, e.g. bindexmessage, the compiler already knows the offset of ex->body.message, hence it does not need to be encoded, much less interpreter 12:17
interpreted
the JIT eliminates that difference, of course
but for the interpreter it increases bytecode size
timotimo oh
so i shouldn't jit these into sp_bind_*, instead i should do it directly in the jit?
brrt and runtime 12:18
no
i'm just explaining why it probably had not been done yet
timotimo "i shouldn't spesh"*
ah
well, what i was really asking for was why the sp_bind_* ops have not yet been implemented at all :)
brrt although, one could indeed implement the conversion in in the jit only
12:18 Ven joined
timotimo not sure what you mean 12:20
brrt the translation from bindexmessage to sp_bind_* could be implemented in src/jit/graph.c, (in jit graph building step) rather than in src/spesh/optimize.c 12:24
timotimo hm
is that convenient?
brrt but, it doesn't matter much now, since i'm supposed to start translating it all to a magic optimisation format two weeks from now
no
timotimo right 12:25
and we also jit the majority of frames directly after speshing
brrt if we can, we do
timotimo we should can
brrt yes 12:27
anyway
my question is
what would it take to turn the jit_throw_ops into something mergeable 12:28
timotimo the branch, yeah?
i'll cherry-pick some stuff out of it and possibly rebase -i the stuff out of the branch itself 12:29
brrt yes, if you could, that'd be very nice :-) 12:50
also, to resume (haha) the discussion of a few days back
i think somebody who can, in fact, dive into a complex codebase and apply fixes and changes and consider their whole impact 12:51
as you (timotimo) have surely proven to have
then yes, that is certainly a valuable skill indeed
timotimo fair enough i suppose :S 12:52
brrt on the flip side of that is that simply stating 'i've worked on the perl6 optimization infrastructure' is very likely not to convince recruiters, or at least to be answered with 'but how many years of .NET/PHP/Java experience do you have?'
timotimo fair enough
brrt us techies know that this is an irrelevant question, but one that will be asked anyway 12:53
timotimo but i'm a de techie :P
brrt these days i consider a resume (cv) to be a tool to get interviews, no more no less
timotimo mhm
brrt and, lastly, and i wonder why i even have to say it :-P 13:03
the *difficulty* of any job is not (directly) related to its *value*
least of all the difficulty to you
timotimo i know it's logical, but it doesn't make sense to my brain 13:04
brrt no one is asking you to be mr spock :-) 13:07
timotimo mhm
brrt by the way, 'Fair enough' is not shorthand for 'You may be right, but I don't believe you anyway' :-P 13:11
timotimo haha 13:12
i can only speak for one part of my understand-machine
the other part(s?) are famously broken in some respects :) 13:13
brrt well... :-) 13:19
anyway, i can't help you too much with that from this distance
timotimo of course
there's no emergency yet ;)
brrt fair enough :-) 13:21
timotimo i have some violently spammy debug output code for spesh inlining; i wonder if i should throw it out? 13:22
brrt it shouldn't go to master, no 13:23
timotimo of course not
brrt but for debugging, why not
timotimo actually, the spesh dump could highlight ops that prevent inlining, so that part could go (and you can also see what would prevent a frame from being inlined even if nothing tries to inline it at all
i'm afraid i'm adding and adding to the spesh dump
brrt that's ok, for what it's worth
timotimo no clue if others would find the things helpful 13:24
brrt thinks it likely that someone will
better to have a bit too much information than a bit too little
timotimo at least through the table of logged values i figured out that something sidesteps the int cache
brrt wonders 13:27
timotimo feel free to wonder with me; this issue seems to stump me
brrt if one is implementing a printf-style or string-cat thing
timotimo something builds P6int-repr'd things without using MVM_box_int
oh, you're wondering about something else entirely 13:28
brrt is it better to a): pre-calculate the required length and write everything in a single buffer
or b): just go ahead and use a dynamic-growing array
yes
haha :-)
timotimo damn. i thought we were a team! :P
brrt hmmm
that is a bit weird, yes
and you're certain these are P6Int objects? 13:29
timotimo it surely prevents spesh from realizing that the logged values are *actually* equivalent
well, they have that repr and i've also extracted the numerical values
brrt how.. large is this intcache thing, anyway 13:30
maybe something like inc?
or arithmetic in general
timotimo inc works on int register
brrt inc_i 13:31
timotimo the intcache has 14 slots or something; it has its own .h and .c file
brrt lemmesee
timotimo on my laptop i have the code that prints out a P6int's value, i believe 13:32
BBIAB 13:33
brrt ok
13:41 Ven joined
timotimo so it was really 16 slots for 4 different types 14:20
in the intcache
but you probably also figured it out yourself already
brrt yes, that i did :-) 14:43
anyway
possibly different type objects?
possibly a question of cache-too-small? 14:44
timotimo the cache caches values 0 through 15 i think
so no, cache too small isn't it; especially since the values i saw were mostly 0 and 1
brrt hmmpf 14:47
many frustrate
timotimo agreed 14:48
maybe the logic of returning integer values that get boxed go around MVM_box_int?
brrt possibly, yes 14:52
timotimo that'd be a very big source for this, if it is that case
can you take a quick look?
we might also be forgetting to record allocations for the profiler in this regard 15:08
brrt hmm i can not really take much of a look right now 15:13
timotimo that's okay 15:14
i'll be out and about getting food and doing other errands for the next hour(?)
brrt arithmetic ops don't do any intcaching, i think 15:22
see src/math/bigintops.c
my suspicion is that that is your problem
but /me afk
15:22 brrt left
[Coke] integration/advent2013-day14.t failed on the last daily run on non-jit, but worked on JIT. 15:40
FROGGS it is a flapper 15:42
16:32 vendethiel joined 17:56 FROGGS joined 17:57 vendethiel joined
timotimo brrt, i found a gist with the p6int situation: gist.github.com/timo/1883a8c4287650f38925 17:58
dalek arVM/jit_throw_ops: 643c0fd | timotimo++ | src/spesh/dump.c:
[speshdump] in log table, show p6int value and concreteness
 18:00
arVM/debugspam_inlining: 8f4a9d1 | timotimo++ | src/ (3 files):
lots of logging for inlining (and what prevents it)
timotimo i have to teach all the bigint ops about intcache, eh? 18:08
at least many of them are implemented with macros
18:17 Peter_R joined
timotimo hum. 18:18
when i want to defer the allocation of the p6int after deciding whether or not the ints are big ints or small big ints ... 18:19
i'll have to get_bigint_body twice in a row :\
because what if the object has moved
would it be sane to check the gc sequence number before and after the allocation?
and now i have something for autoboxing ints 18:31
can't get it to work properly :\ 18:34
ah, unexpected unions 18:37
now i kind of wish for a slot for -1 in the int cache
i'll run a spec test and push 18:39
this includes a bunch of cherry-picks from jit_throw_ops
(onto master)
since this is about unboxing a return_i into an invoke_o, i suspect the spec tests would blow up extremely early if there was something wrong 18:40
[Coke] pushed. 18:41
ww
timotimo i'm glad you routinely check #moarvm :) 18:42
18:44 brrt joined
timotimo cool, spec tests only have the long-known flappers 18:48
dalek arVM: cf42d3d | timotimo++ | src/spesh/dump.c:
[speshdump] show argument guards directly below callsite
 18:49
arVM: f0d721b | timotimo++ | src/spesh/dump.c:
output number of spesh & log slots and a log table in spesh dump
arVM: 1512f6d | timotimo++ | src/spesh/optimize.c:
since spesh slots are immutable pointers, we can re-use them
arVM: b79854e | timotimo++ | src/spesh/optimize.c:
remove debug output
18:49 vendethiel joined
timotimo huh. MVM_bigint_div calls get_bigint_body twice, then roots the objects it gets the bodies from and then allocates 18:56
masak when I stringify -0e0 in Rakudo-on-Moar, what code is it that runs in MoarVM that creates that string? 18:57
closest I get to finding it is an .add_core_moarop_mapping in src/vm/moar/QAST/QASTOperationsMAST.nqp:QAST
er, s/:QAST//
timotimo what's the name of that op?
quite possibly coerce.c's MVM_coerce_n_s 18:58
ah, boxing ints for slurpy positionals doesn't go through the int cache yet 19:04
19:14 vendethiel joined
dalek arVM: 9da66bc | timotimo++ | src/core/intcache.c:
sacrifice 15 for -1 in the int cache. -1 is very popular!
 19:16
arVM: 45381f0 | timotimo++ | src/core/args.c:
ints for slurpy positional go through int cache
timotimo still some leaks, though i more or less don't want to give all bigint ops intcache treatment 19:17
brrt at this point i should probably note that i was wrong just now 19:21
bigints don't go to the cache
but bigints aren't P6int but P6bigint
FROGGS src/core/args.c:578:17: warning: passing argument 3 of ‘MVM_intcache_get’ makes integer from pointer without a cast [enabled by default] 19:22
box_slurpy_pos_int(tc, type, result, box, arg_info.arg.i64, reg, int_box_type, "int", set_int);
^
src/core/intcache.h:7:12: note: expected ‘MVMint64’ but argument is of type ‘struct MVMObject *’
MVMObject *MVM_intcache_get(MVMThreadContext *tc, MVMObject *type, MVMint64 value);
^
timotimo: ^^
timotimo no! what did i do?!
i built it locally ... whaaaat?
FROGGS it is just a warning
timotimo thank you
yes, but it's very wrong
FROGGS aye
timotimo i must have confused the argument order
FROGGS dump.c also warns 19:23
dalek arVM: b71f428 | timotimo++ | src/core/args.c:
very, very wrong variable in this case
timotimo yes, it does 19:24
because i was too lazy to cast things i know are the right type. i'll fix that now
FROGGS if all goes well I'll create a new branch today
timotimo oh, it's the const/not const thing 19:25
dalek arVM: 3377c87 | timotimo++ | src/spesh/dump.c:
get rid of a warning in dump about constness of strings
 19:26
timotimo a new branch for the restricted thingie? 19:27
FROGGS aye 19:29
timotimo cool 19:33
19:56 vendethiel joined
dalek arVM/restricted: 4f660d6 | FROGGS++ | src/ (4 files):
add VM level op restrictions for safe code evaluation

The goal is to safely evaluate foreign code, without fearing that this code can read your data from disk or create or delete files etc. To enable these op restrictions either declare a contextual called
  $*RESTRICTED or set the environment variable MVM_UNSAFE_DISABLE=1.		 19:59
FROGGS $ perl6 -e 'sub foo { use nqp; say nqp::open("sekrit", "r") }; { my $*RESTRICTED; foo() }' 20:00
Operation 'open_fh' is not allowed in a restricted environment
in sub foo at -e:1
masak timotimo++ # MVM_coerce_n_s 20:11
I think the gist of that one is that it delegates to sprintf, which in turn knows 0e0 from -0e0 20:16
so my question becomes: in C, what's a good way to tell (n64) -0 from 0? 20:19
20:22 vendethiel joined
hoelzro does MoarVM mmap bytecode files for some reason? 20:38
I have a hunch on why panda install JSON::Tiny gets angry 20:39
brrt possibly, yes, hoelzro 20:43
hoelzro hmm, maybe that's why there's a segfault when the panda mbc files are being overwritten...
20:43 cygx joined
cygx o/ 20:44
masak: math.h comes with a signbit macro
masak ooh 20:45
what would that mean in code?
cygx if(n == 0 && signbit(n)) puts("n is a negative zero"); 20:46
masak perfect. I can work with this.
cygx++
cygx masak: what's the use case, if I may ask?
masak rt.perl.org/Ticket/Display.html?id=125216 20:48
though I may have a solution in pure Perl 6, so I'm asking mostly out of interest.
cygx what about <TimToady> eqv and === on floaters should probably just compare chunks of memory 20:49
masak that aligns with what I want to do.
there's still the small issue of translating it into actual implementation.
(also see nwc10++'s later warning)
cygx masak: I don't think MoarVM supports long double, so not an issue 20:51
IIRC, the x86 MS CRT dropped support for them altogether
*x64 20:52
dalek arVM/jit_throw_ops_2: fc28f88 | timotimo++ | src/ (3 files):
jit throw[cat]{dyn,lex,lexotic}

currently hangs execution.		 20:54
cygx or more precisely: they dropped support for the x87 stack in favour of SSE and map long double to double
brrt very rebase
as rightly they should cygx
20:55 dalek joined
cygx brrt: it's not as clear cut - there are users who relied on that extra precision... 20:56
brrt timotimo: do you know anything we want to do before we merge jit_throw_ops_2
always users and their requirements :-P
timotimo dunno
i think it's all right
brrt although i'd think sse could do 128bit?
i'm kind of reluctant to merge because i'm not *quite* ready to deal with any fallout this night 20:59
20:59 vendethiel joined
timotimo k 21:00
i totally forgot to start on the blogpost! 21:01
glad it's not yet 3am :)
though i feel sufficiently tired already
cygx brrt: doesn't SSE just do vector operation, ie no extended precision? 21:04
brrt hmm, wikipedia says you're right 21:05
anyway, i'm off for tonight 21:08
\o
21:08 brrt left, brrt joined 21:47 cygx left 22:26 ggoebel joined 22:42 colomon joined
timotimo oh, you didn't post on your blog about the grant application yet 23:19
i was about to check if it's beginning, middle or end of this month (or was it next month?) when you'll start on the grant work 23:20
so it could go into the weekly
oh well, it'll be fine regardless

Powered by Cro and the Raku® Programming Language.

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

Thank you!