00:05 dalek joined 02:49 dalek joined
nine afl-fuzzy++ 05:38
timotimo++ :) 05:39
05:41 travis-ci joined
travis-ci MoarVM build errored. Timo Paulssen 'uncuddle an else' 05:41
travis-ci.org/MoarVM/MoarVM/builds/154295591 github.com/MoarVM/MoarVM/compare/b...0666638314
05:41 travis-ci left 05:49 lizmat joined 06:49 domidumont joined 06:54 domidumont joined 07:47 zakharyas joined 08:13 TheLemonMan joined
TheLemonMan timotimo, wrt your param checking code, I think the code would look neater by putting the outer if into the for, this way you can avoid writing two similar for 08:42
#145 can be closed as it's been fixed at the rakudo level and roast tests have been submitted 08:43
also #175 seems to be fixed now 09:08
09:26 lizmat_ joined, dalek joined
timotimo i thought the code would be clearer if i separate it out 09:31
dalek arVM: bace47f | LemonBoy++ | src/profiler/heapsnapshot.c:
snprintf returns an int, not a size_t.
 10:11
arVM: 5c7fc80 | lizmat++ | src/profiler/heapsnapshot.c:
Merge pull request #396 from LemonBoy/tautological-compare

snprintf returns an int, not a size_t.
10:47 travis-ci joined
travis-ci MoarVM build passed. lizmat 'Merge pull request #396 from LemonBoy/tautological-compare 10:47
travis-ci.org/MoarVM/MoarVM/builds/154407989 github.com/MoarVM/MoarVM/compare/4...7fc80bc3c1
10:47 travis-ci left 12:41 zakharyas joined 12:43 zakharyas1 joined
timotimo so, you know how python can look for modules in a zipfile that's concanetaned to the binary? 14:31
maybe we should take that route towards making moar-based "fat packs"
16:10 domidumont joined 16:46 brrt joined
brrt timotimo: i agree, that is probably the way to go 16:47
you'd still need a reasonably clever wrapper executable 16:48
and you'd need a statically linked moar (i'd think), or at least, static to our internal dependencies 16:49
lwn.net/Articles/691070/ 16:50
dude says CPython guys will start making and/or using a JIT
personally, i think CPython has painted itself into so many corners on that front that I think it unlikely
also, the claim is that pypy and friends can't deal well with ffi calls 16:52
it's a bit similar to our situation with nativecalls
but... we have some hope of jitting these fast in the future 16:53
TheLemonMan that's a start!
brrt TheLemonMan: if you care, i can explain you the current state of that :-) 16:54
TheLemonMan brrt, I'm all ears :)
brrt basically, i've written the existing JIT, basically as a bolt-on to the spesh framework, about two years ago
sorry, basically twice 16:55
now the existing JIT is very simplistic: it literally translates the spesh graph (an annotated representation of the bytecode) to machine code using a little library called DynASM 16:56
and the thing about that is: there is a literal mapping between moarvm opcodes and JIT output
to such an extent that i can read from the machine code that is generated back into the bytecode 16:57
that's handy for debugging, i've got to say that
but it is a lousy way to generate code, and furthermore, it means that we have no easy ways to do 'lowering transformations'
so if we have an array object, and we know it is an array object, and that has an integer index, then it is still kind of tricky to translate that into efficient bytecode 16:58
stop me if this stops making sense 16:59
so, what i've done, is split the JIT into two stages
the first stage translates the moarvm bytecode into a low-level DAG structure called 'expression trees'
this is a lowering that transforms from MoarVMs memory-to-memory model, to a register-to-register model 17:00
all this while the existing JIT is still in place, mind you 17:01
and the second stage (called 'tiling') transforms those trees (or DAGs) to a linear list of operations
machine code operations
well, function pointers to routines that output machine code, but you get the idea 17:02
had to hack DynASM to do that, because official DynASM doesn't play nice with extended registers in x64
so once i'd done that, i thought i'd just walk that list, invoke its generating functions, and call it a day, but it turns out that register allocation is both essential and tricky 17:03
and that it really wants proper linear order and multiple passes and lookahead, and these things weren't there when i had to stop working on that fulltime 17:04
(because i was in my final year of studying)
anyway, i've more or less continued refactoring bits of the new JIT to get that nice linear order and a proper structure for the register allocator 17:05
once that is done, it's basically good to be merged, and then the real fun starts
because what we can do is take the specialized types and have them insert their own bit of expression code for opcodes 17:06
so nativecall can be lowered at JIT time to any old function call
and array indexes can be lowered to a single instruction
types permitting, of course
TheLemonMan that sounds like an awesome plan! 17:08
brrt other nice bits include: to port the JIT to another arch, for example ARM, we only need to port the tiler and register allocator (or have a data-driven register allocator, which is the actual plan) 17:09
and the tiles
not the tiler
tiler remains the same
it is quite a nice plan if i do say so myself :-)
(and we can do transforming modifications on the 'expression tree' like ... whatsitcalled 17:10
when you remove duplicate computations of the same thing
timotimo brrt: what, pypy can't deal well with ffi calls? is that a joke? 17:12
brrt well, that's not my claim
timotimo pypy already jits ffi calls into the same code a C compiler would
where did that person get their info?
brrt really?
well, then pypy is ahead of us
(as i would expect, really)
i dunno
he's a scientist in a eh... UCB 17:13
focussed on the 'big picture'
timotimo pypy is already ahead of pretty much everyone forever :) 17:14
brrt anyhow, i think the issue with pypy and numpy is, or used to be, that they had their own implementation of numpy called numpypy 17:15
timotimo i think you were looking for "common expression extraction" or something?
that's right
brrt and their vectorization just isn't as good as the C and FORTRAN compiler's
timotimo i contributed a tiny bit of code to numpypy
brrt ah, yes, that's the one
common subexpression elimination
timotimo yes!
brrt CSE is cool. although not a definite optimization, because it increases register pressure 17:16
can be a done with a bottom up traversal and a hash table
i'll leave the rest to you :-P 17:17
'an exercise for the reader'
the literal LWN quote is: "The first consequence that Smith described is that, for libraries like NumPy, there is a "catch-22". If it needs to be fast for CPython, it has to be written in C, but if it needs to be fast for a JIT, you cannot use C. He showed a simple mysum() function that totaled up the elements in an iterable. If it is passed a Python object like list(range(N)), the JIT knows what it is and can do lots of optimizations. But if it is passed a NumP 17:21
y array, which is "opaque C stuff", the JIT doesn't understand it, so it will have trouble even achieving the performance of a non-NumPy version on a JIT-less CPython. "
that is pretty much certainly not true, but whatever 17:22
timotimo do you know of the CSE band? :)
brrt i do not know 17:23
timotimo i bet if you use CSE for your band, you'll not be making catchy songs 17:24
brrt hahahahaha
17:24 domidumont1 joined
brrt well, perhaps better than the deflate band 17:24
timotimo hah 17:26
brrt anyway, the latest latest bit is that i've finally started working on the register allocator, that i finally have a good theoretical basis for doing that, that, in other words, i'm an idiiot who underestimated the scope of the project 17:32
17:35 cygx joined
cygx timotimo: perhaps they meant that pypy cannot across the FFI boundary 17:35
timotimo that'd be true, then 17:36
but neither can a C compiler, really
cygx Graal/Truffle (basically the same thing as PyPy with partial evaluation instead of tracing, cf stefan-marr.de/papers/oopsla-marr-d...valuation/ )
where did the rest of that sentence go? 17:37
Graal/Truffle can do such optimizations by implementing a C as well as LLVM bitcode interpreter
timotimo then you'll have to keep the source around for things you want to ffi? 17:38
cygx if you want to do inlining/partial evaluation/... across the FFI boundary, yes 17:39
timotimo if so, i'm unwilling to keep calling that FFI :)
cygx (in practice, probably LLVM bitcode, not C source code) 17:40
17:44 brrt joined
brrt why not bytecode interpretation 17:45
it isn't that hard, it's not like it's a friggin huge interface
and they have the manpower to do it
however, one has to ask oneself whether any of that is the point
timotimo you mean interpreting the actual x86 machine code? 17:48
brrt aye
why not
timotimo right ... 17:49
maybe we'll end up being the first ones to be crazy enough? we'll implement it for moarvm :P
brrt if you're so adamant to be faster than calling c
hahaha
we have a reputation for crazy to uphold
... i'm done with internet technology news, though 17:52
the frequency of times that i read something that begins interesting and ends with 'oh god, not this again' is too damn high
timotimo yes, oh lord
brrt oh lord?
timotimo tech news sites 17:53
jnthn I don't think that was meant as an honorific :P
brrt no, neither did i
jnthn Though I like how it can be parsed that way :)
brrt but maybe i was coming accross as eh.. oh well
jnthn has his weekly day of Moar / Perl 6 hackery tomorrow
brrt \o/
what's on the menu this time
jnthn Same as the last few weeks, trying to robustify concurrency related things. :) 17:54
timotimo here's an amusing one
Program received signal SIGFPE, Arithmetic exception.
0x00007ffff771e9e5 in deserialize_repr_data (tc=0x6047c0, st=0x609030, reader=<optimized out>)
at src/6model/reprs/P6opaque.c:1063
brrt amuse us
timotimo 1063 if (cur_offset % spec->align) {
brrt how
timotimo the fuzzer found that :)
:D
brrt and spec->algin can be zero how 17:55
timotimo yes, how indeed.
$2 = {inlineable = 0, bits = 0, align = 0, boxed_primitive = 0, can_box = 0, is_unsigned = 0 '\000'}
apparently: "uninitialized"
oh, apparently the fuzzer went ahead and just set the align value to 0 in the serialized blob
and that's how it asplodes
just a case of us not putting a check against 0 there to fail with "that's obviously BS." 17:56
mighty AFL finds every single flaw, and then some.
brrt hmmm 17:59
yeah, arguably that is a flaw and wants a check 18:00
18:37 utat joined 18:39 domidumont joined
jnthn Phew, I think I might have finished writing up my grant report... 18:46
timotimo the kind that goes on your blog? 18:47
or is there a separate kind you send off to TPF directly?
#3 0x00007ffff75aef6c in MVM_interp_run (tc=tc@entry=0x6047c0, initial_invoke=0x0, invoke_data=0x1) 18:48
how does that end up with initial_invoke being null?
when called from MVM_vm_run_file
[Coke] I'm pretty sure most reports to the tpf on most grants are publically blogged
timotimo but it then goes on to call toplevel_initial_invoke anyway 18:49
anyway, it's going on to frame_force_to_heap a null pointer, but i wonder where the earliest point is that we can spot this wrongness 18:51
jnthn timotimo: The TPF kind that hopefully leads to payment :) 18:54
Yes, it will appear publicly
timotimo :D 18:56
jnthn dinner; bbl 19:00
dalek arVM: 9267528 | timotimo++ | src/6model/reprs/P6opaque.c:
don't allow zero alignment in p6opaque storage spec
 19:25
arVM: edd5839 | timotimo++ | src/core/bytecode.c:
index check lexicals when reading static flags
JimmyZ github.com/MoarVM/MoarVM/issues/234 # it would be nice if someone can fix it :) 19:55
SEGV bug
jnthn Hm, does it for me too 19:57
Will have a look in the morning :) 19:59
JimmyZ thanks 20:00
20:14 Ven joined 21:00 TheLemonMan joined
TheLemonMan JimmyZ, wrt #234 I think it's due a poor interaction between libuv and the exception handler, when an exception is raised you're basically longjmp'ing from a libuv callback to the opcode dispatch loop 21:04
eg: ptpb.pw/UOuH 21:05
21:26 lizmat joined
timotimo i suppose i can have a local patch to make that "crash" "not a crash" but a fail, so that i can get more "real" crashes when i run afl the next time 23:17
refering to the initial invoke thing where the frame is 0x0
23:27 TimToady 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!