04:02 FROGGS__ joined 06:02 dalek joined 06:28 dalek joined
nwc10 timotimo: yes, t/nqp/59-nqpop.t already had the relevant test 07:27
which is now failing on MoarVM (rather than causign ASAN to barf) 07:39
so (obviously) something still isn't quite right 07:47
and I'm not 100% certain what is truth, and what the bug is
07:58 Ven joined 08:05 oetiker_ joined 08:06 oetiker joined 08:12 Ven joined 08:34 salva joined 08:45 zakharyas joined
timotimo oh, let me see 08:46
nwc10 I assume that parrot and the JVM pass that test, but I've not tested this. Nor have I looked at the docs to figure out whether the test is consistent with them 08:47
but it's, um, interesting (and slightly troubling) that what feels like rather basic NQP behaviour wasn't tested.
*or* tickled by anything later
timotimo yeah, that value is certainly wrong 08:49
nwc10 I'm glad that you've got more headspace to investigate this issue than I have. 08:50
08:50 zakharyas1 joined
timotimo it seems like a part of the code expects the start argument to be where it starts from, going leftwards 08:51
and the test seems to think the start is where it should go to from the right
the docs say "Begin searching at $pos if specified, otherwise start from the last position."
08:52 kjs_ joined
nwc10 The perl 5 tests for rindex are in perl5.git.perl.org/perl.git/blob/HE...op/index.t 08:52
not sure if there's anything useful to steal from there 08:53
because the docs do sound a bit under-specified.
but I need to figure out if I'm about to screw up git filter-branch
timotimo well, git filter-branch will always let you go back to the way it was before with the git reflog 08:54
nwc10 yes, but the filter might take an hour, so I'd prefer to maximise my chance of getting it right
08:54 zakharyas1 joined
timotimo hah 08:55
i was looking at an index test
and not an rindex test
clever me
nwc10 use more 'coffee'?
timotimo and now i've been using -e ' ... ' and inside the code there were ' ' already, which my shell ate 08:58
so it was comparing NQPMu with NQPMu
dalek arVM: 7bb98ef | timotimo++ | src/strings/ops.c:
starting too far right isn't automatic -1

but we do have to cap the index to a rightmost maximum.		 08:59
timotimo ^- test fixed, logic restored
nwc10 timotimo++ 09:05
09:11 donaldh joined 09:40 virtualsue joined 09:45 brrt joined
brrt \o 09:45
dalek arVM: cd85ea1 | nicholas++ | src/6model/reprs/P6bigint.h:
In the P6bigint body union, the flag most only be first for 64 bit Big Endian.

The intent is that the flag value (0xFFFFFFFF) is in the lower 32 bits of the function pointer. On 64 Big Endian systems, the existing code implemented this correctly, by storing the 32 bit value first, the 32 bit flag second. But for 32 bit Big Endian systems the flag must come first (just like all Little Endian systems), because otherwise the 32 bit value and 32 bit pointer share the same memory, and writing the flag doesn't cause set the lower bits of the pointer)		 09:57
jnthn o/ brrt 09:58
FROGGS nwc10: all your patches are applied now? 10:03
nwc10 I *think* so. 10:04
I was confused earlier.
brrt \o jnthn :-) 10:05
(WINDOWS OMG :-o)
they call it a 'server edition' even
jnthn Just wait for MoarVM Enterprise Edition :P 10:07
nwc10 MEE too
Rewrite 6ae0c1f808dc44ea9bbf9b0b41fb14cb9427e271 (40820/40820)
...
real 55m34.943s
(being my rewrite) 10:08
user 13m8.229s
sys 26m52.721s
that was the git filter-branch at work that I said would take a while.
timotimo not bad, an hour!
nwc10 that was only an env-filter
the tree based one took 5 hours on fewer commits.
timotimo phew
jnthn Wow
nwc10 I forget whether I did that on my desktop (SSD) on the dev box (older, and I believe spinning rust) 10:09
jnthn 5 horus is a heck of a lot
nwc10 it's the main chunk of work history, from 2006
timotimo if you have enough RAM, the hard drive doesn't matter ;)
and if you "git fsck" first, everything will be compressed into packed, indexed files
nwc10 I was feeling rather wary of any of that, because partly I'm doing it to get rid of a bunch of grafts 10:10
timotimo ah
fair enough
maybe git fsck has a "dont-delete-anything" mode for just compressing stuff ;) 10:11
nwc10 I assume that it wouldn't have screwed up
but the local checkout will go away at some point
so I wasn't worried about *it* 10:12
brrt (lol @ MoarVM Enterprise Edition) 10:15
timotimo well, there's commercial JVMs that have some extra optimizations or tunings or support or something 10:17
nwc10 I'm only aware of one offhand: www.azulsystems.com/products/zing/whatisit 10:18
but this is not anything I track carefully.
brrt anyway, i'm not sure if this is a proper time to discuss it, but how badly do we (= the community) want JIT improvements for MoarVM? 10:19
and also, which JIT improvements do we want most?
nwc10 on that, I think, get the x86_64 JIT reasonably good before considering any other
brrt i agree 10:20
nwc10 (and ARM is a more logical second than x86)
brrt i also agree on that
nwc10 I think you said that right now it does a lot of pointless loads and stores
brrt yes
nwc10 because the infrastructure can't cope
brrt if you wish, i could probably show you a sample
nwc10 I think getting them out feels like the first "big project"
brrt it's also a very large project since it'd be a rewrite in a sense
nwc10 I don't know x86_64 (itself) so I'm happy to take it as a given
brrt do you know x86?
nwc10 no 10:21
ARM
brrt x86_64 is basically the same just with larger registers
well, there's very little magic about it (i find that very nice about asm in general)
nwc10 can you hand edit enough JIT code to give a number (or numbers) for what sort of speedup it woudl give?
brrt hmm
that would not work, i think
or i should make specially contrived examples 10:22
nwc10 it would be very useful for any sort of grant prospoal
"somewhat real world" usually stands up best
brrt but the JIT inserts pointers to run-time constants
nwc10 and "grant proposal" is an answer to "how much"
brrt right
in my ideal scenario, having a more machine-reified representation would also make it possible / easier to efficiently implement all sorts of jit level type optimisations 10:24
timotimo i've still got no idea how we'll make NativeCall representation/invocation friendlier to the JIT ... 10:26
at the moment we're not even speshing anything close to the piece of code that contains the "nativecallinvoke" operation 10:27
brrt well, my simple suspicion is that you'd convert the nativecallinvoke operation to a MVMJitCall node
prefixed by any number of pre-conversions
timotimo yeah, but we can't reach it yet
brrt hmm
but to be honest i have no idea how nativecall is currently implemented 10:28
timotimo don't worry too much about this; it's probably something jnthn might have a design for
jnthn I think we hang it off invokespec 10:30
timotimo in perl6 land we compose a role with a native callsite box target onto a sub or method and implement the postcircumfix:<( )> method to nqp::nativecall on self and its configuration
brrt but that brings me back to my earlier point....
timotimo "we hang it" or "we should hang it"?
jnthn We should hang it :)
We have it easy now, though. NativeCall lives in the Rakudo repo 10:31
So we can do these kinds of changes without too much upheavel.
timotimo hm, where does extra data go for invocation specs and such?
brrt we need (or should i say, the JIT would need) a better representation to easily represent such things
in the REPR i think?
jnthn Well, the invoke stuff hangs off the STable 10:32
But you can keep the information itself inside of the NativeCall REPR as is the case today
The invoke spec is the linkage between the two, but it makes "this is a native call, look at it" less opaque
timotimo OK, so we'll be invoking an object that boxes a NativeCall repr'd MVMObject? 10:33
FROGGS we are not invoking it directly, arnt we? 10:34
jnthn timotimo: We already are, but then we have a method postcircumfix:<( )> level of indirection in the way
Note that we still do need something like that
timotimo yeah, i was sketching out, in my mind, how we'd get rid of the postcircumfix:<( )> in the middle
FROGGS we have a native callsite, pull out libname, symbol, params and return type, and then make the call using dyncall
jnthn It needs to look like indy in that sense: a callsite that you do setup work on the first time, and then update the callsite
And of course, we dont JIT/spesh until stuff is hot 10:35
So by the time we do those things, it'll already have been set up
That's the way multi call spesh works, btw: the unoptimized, interpreted code primes the caches, and spesh just looks at those.
On JIT stuff in general, I agree largely with brrt that we need an extra step in there that lets us produce much better machine code. 10:36
brrt i'm not *entirely* sure how to represent that just yet 10:37
jnthn *However*, I'd be inclined to split the work into: 1) design/build the new JIT expression tree thingy, 2) switch over to using it in the simplest way possible, still emitting the loads and stores we do today, to make sure it works at all, then (3) take advantage of it
brrt fwiw, i mentally resolved the LLVM discussion by noting that LLVM is very far removed from either MoarVM bytecode and (any) machine code, and thus not very ideal to represent the moarvm jit in 10:38
jnthn So that it's not One Huge Rewrite where all the bugs in all the things have to be found together
brrt nods
that is basically the root of my plan too, to allow the expression trees to be 'just nodes' in the whole graph
jnthn That's kinda even better, perhaps :) 10:39
brrt and then to gradually convert all the nodes into the tree
jnthn *nod*
brrt but that may be easier said than done
jnthn Just need to be careful when you optimize about 1) GC safe points, and 2) deopt points
brrt optimization is still very far away as far as i see it now 10:40
jnthn Well, I mean more eliding the loads/stores
brrt right, yeah
jnthn Some of them matter for correctness.
brrt that's not conceptually hard to do though, since you already have to track the location of each variable
jnthn *nod*
Getting it wrong does lead to really hard bugs. 10:41
brrt nods with intense agreement
as far as my availability goes, i think i'll be fully available after may, at least until august and maybe further; also quite unable to go on a holiday 10:42
timotimo i'd still like to find a good design for code that gets triggered by deopt points
10:42 kjs_ joined
timotimo maybe a "store deopt target and branch" and later a "load deopt target and do the deopt" would bracket the code 10:43
brrt timotimo, please elaborate 10:44
jnthn brrt: Then probably we should get rolling with a grant app in April, so it's ready by end of May
brrt ok, that's a good idea
timotimo brrt: currently, a bunch of registers are being kept alive by a requirement to have the proper value set in them at the time a deopt point is hit 10:45
brrt: but often, those registers just contain a copy of the value of another register, because that's what the original code-gen made and after deopt all registers have to be proper 10:46
jnthn figures he really better spend some time writing his slides...which are about time...
timotimo jnthn: Gutes Gelingen! :)
brrt again presenting? :-)
ah, i see
10:47 rurban joined
brrt that seems like a tricky thing 10:47
but on the other hand, one that would be doable at spesh time, no?
timotimo yes
at some points, spesh will keep const_s calls in the code just because the deopt'd code expects a string constant in a register 10:48
and world object lookups, too
jnthn Note it only does it *if* the thing is used the other side of a deopt boundary 10:51
timotimo oh? how do we figure that out? 10:52
brrt via the ssa i guess
or
whait
wait
hmmm
timotimo hm. well, the SSA at the time when we do the facts discovery actually just represents the original code
brrt do we have a used_after flag or something? that would backpropagate
timotimo so that *would* work, hmm.
hm. there's a "facts->deopt_idx == current_deopt_idx" in there that decides between whether to up the usage by 1 or 2 per actual usage 10:54
maybe that ought to be <= instead of ==?
jnthn The trick is actually that we boost usage counts
However, some guards go unused
And I think at present we don't go back and decrement usage counts again when a guard is unused. 10:55
timotimo oh, that could be something 10:56
dalek Heuristic branch merge: pushed 27 commits to MoarVM/cpp by FROGGS 11:04
brrt lunch & 11:05
11:10 zakharyas joined 11:38 colomon joined 11:39 Ven joined 11:55 kjs_ joined 13:01 kjs_ joined 13:04 Ven joined
timotimo how do we feel about a configure option for moarvm that activates --march=native? 13:16
13:17 kjs_ joined 13:20 brrt joined
brrt what does march=native do? 13:22
timotimo it enables a few optimizations for your specific CPU and also sets the cache size to optimize for to what your machine has 13:23
brrt ah, ok :-) 13:25
14:25 kjs_ joined 14:43 FROGGS[mobile] joined 15:18 njmurphy joined 15:31 kjs_ joined
[Coke] (grant proposal) as a TPF GC member, I'd love to see some perl 6 grant requests come in. (backlogging) 15:58
jnthn That might be the first time somebody used GC on this channel and didn't mean Garbage Collector... :) 15:59
[Coke]: Is there some timing on the TPF side we should be aware of?
[Coke] jnthn: it has changed recently, one moment. 16:01
www.perlfoundation.org/rules_of_operation - every two months.
jnthn [Coke]: Mostly, if brrt++ was intersted in a grant for doing stuff in June..August, when do we need to apply... :) 16:02
[Coke] there may also be Hague grant dollars left, that's outside my zone.
jnthn Ah, eval process in May
[Coke]: Sure, guess it's nice TIMTOWTDI :)
flussence for anyone curious about what march=native does *exactly* - gist.github.com/flussence/176895499d7211ee1cce 16:57
17:22 donaldh joined 18:23 kjs_ joined 18:53 kjs_ joined 18:56 vendethiel joined 19:47 kjs_ joined 20:33 rurban joined 20:40 kjs_ joined 21:50 kjs_ 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!