00:29 jnap joined 00:58 btyler joined 01:34 FROGGS_ joined 03:16 btyler joined
timotimo is push_o among the bailers because it needs to go indirectly through the repr and the jit just doesn't have a template for repr ops yet? 09:22
09:43 vendethiel- joined
jnthn I think there's a MVM_repr_push_o it could call or something like that 11:43
timotimo ah, yes, there is 12:22
probably the same for atpos and atkey
jnthn aye 12:24
timotimo only very few bails for those all in all, but it's probably still interesting 12:27
any reason beside "we didn't need it yet" that there is no repr_pop_o? 12:31
jnthn "we didn't need it yet" :) 12:33
timotimo adds them
them == all the _* variants
12:35 itz_ joined 12:37 FROGGS joined 12:41 carlin joined
dalek arVM/moar-jit: 4eb29f4 | (Timo Paulssen)++ | src/ (3 files):
create repr_pop_* and expose them to the jit
12:42
timotimo 100% of atpos_o ops have now continued to immediately bail on an ifnonnull 12:51
FROGGS timotimo: you're helping out brrt? 12:53
timotimo i just got a little bit intrigued
FROGGS :o) 12:54
jnthn I'm sure brrt doesn't mind the help :)
FROGGS timotimo++
jnthn is tempted to hack on it a bit too at times :)
timotimo well, he better implement ifnonnull now. it's gone up to the 2nd place of bails in the setting compilation 12:55
only 91 bails behind getattr_s
jnthn Is there not an MVM_repr_ wrapper for that one too? :)
timotimo seems like i'd have to make one.
jnthn k 12:56
Well, 'tis do-able
timotimo timo-able :)
will be afk for a bit now, though
FROGGS jnthn: that NQPArray thingeny in all about comfort these days, right? 12:58
jnthn: I just wonder how to solve my $*W.find_symbol problem... 12:59
jnthn Well, it means we can do method calls...
Yeah, I'm not sure. I mean, nqp::hllize(nqp::list(...), 'nqp') or so may do it 13:00
oh, or...
Just write a sub nqplist(*@foo) is export { @foo } somewhere in NQP code, and use it... :) 13:01
FROGGS ahh...
:o)
jnthn++
13:12 colomon_ joined, ggoebel111118 joined 14:19 zakharyas joined
timotimo okay, i'm back to building the getattr_s method 15:00
i don't really see an example of how to pass a constant string to a c function from the jit 15:01
technically i should be able to just take the address of the string literal and push it in as a pointer 15:05
i don't really know the proper way to pass a literal int as an address value; is it just a regular number for the assembly code emitted? 15:07
jnthn "as an address value"? 15:13
timotimo erm
well, the function expects to be passed an MVMString *
i have an index into the compunit's literal table 15:14
since that should be immovable (yes?), i should be able to just dereference that MVMString
but the jit doesn't seem to have a passing type "literally this pointer" yet
it does have "this int64 literal", though. i wonder if i can just use that and be done with it
diakopter what about on 128-bit addressing platforms 15:15
timotimo psst!
oh hey it's you!
hi there :)
diakopter prehi
timotimo how are you doing? 15:16
diakopter ++ 15:17
you?
timotimo i'm doing okay 15:18
"++" sounds very good, i'm glad to hear that :)
diakopter eh, until it rolls over
timotimo as you can see, i'm not well trained in these little details ... 128bit addresses, numerical overflows, ... 15:19
diakopter :p
timotimo have you had time to catch up with moarvm changes since we last talked?
diakopter I've been watching the commit messages
so, fwiw. :) 15:20
actually I've been reading most of the diffs too 15:21
timotimo i hope you'ven't just come here to complain about my poor code quality ;) 15:22
diakopter I didn't think I'd done that 15:23
timotimo well, thankfully jnthn is always quick to point out what i'm doing wrong
and i hope i'm learning from the experience 15:24
[Coke] diakopter: hi 15:25
diakopter oyoy
15:31 carlin joined
timotimo diakopter: is the jit going a way you approve of? 15:33
i only remember talk about "being able to in-line repr functions" back at the RaNIW, which we are now able to do thanks to spesh + jit 15:34
diakopter heh, I dunno.. I'd think so
timotimo glad to hear it :)
lizmat diakopter++ for giving a sign of life 18:01
FROGGS diakopter: hi :o) 18:04
18:36 zakharyas joined
timotimo will be very excited to see when jnthn releases the new string stuff 18:50
FROGGS timotimo: must be at any minute now :P 18:57
timotimo yup, i'm holding my breath! if he doesn't release it now, i'll pass out! what a cunning plan! 19:03
jnthn :P 19:04
timotimo passes out 19:08
d sfgggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
jnthn timotimo: Patch probably coming in the next 30 mins or so 20:10
20:11 cognominal joined
timotimo oooh, cool! 20:12
so now i'm wondering ... will it do away with ropes or keep them? will it implement a proper hashing approach for ascii strings? 20:14
jnthn I've not taken on the hashing *yet* 20:15
timotimo i'm glad that it sounds like you're going to :)
i used to have that one approach that ended up failing and being a terrible mess
dalek arVM/strref: 9384917 | jnthn++ | src/io/procops.c:
Just use empty string constant, not make an empty.
21:12
MoarVM/strref: 6eaf6aa | jnthn++ | / (29 files):
MoarVM/strref: Significantly overhaul the strings code.
MoarVM/strref:
MoarVM/strref: Introduce a grapheme iterator, along with a codepoint iterator (that
MoarVM/strref: is just an alias to the same thing). Go with a flat approach to the
MoarVM/strref: strands, which greatly simplifies traversal of a string and should do
MoarVM/strref: a little better CPU-cache wise. Actually use strands in concatenation,
MoarVM/strref: substring, joining, and repeat operations.
MoarVM/strref:
MoarVM/strref: This patch does enough to get NQP and Rakudo building and passing the
MoarVM/strref: sanity tests with the new approach; spectest looks good too. Still a
timotimo wow, that's a huge diff 21:13
jnthn Yeah...it's one of those "break everything then put it back together" refactors 21:15
timotimo break everything together :) 21:16
i'm glad it passes all the stuff
want me to benchmark it tomorrow or something?
jnthn Yes, plesae. :) 21:18
timotimo and then we'll get getattr_s and ifnonnull tomorrow when brrt is back :D 21:20
jnthn Yes, I'm hopeful the next week will be an interesting one in jit-land. 21:22
timotimo oh, are we close to a release again? :)
jnthn On Thu
So moar-jit wont' make it into this one 21:23
I just meant we're only so many things off it making a difference to benchmarks.
timotimo aye 21:24
ow my ears
(parents watching the football game) 21:25
jnthn Yes, for the correct team too \o/ 21:27
timotimo got cool ideas for spesh before the release? except for the tough topic of common subexpression elimination or loop hoisting or stuff like that? 21:28
we could do some constant folding in spesh land
jnthn Well, "week before release" is probably the time to be fixing stuff rather than doing new opts :)
timotimo d;aaw 21:29
21:30 vendethiel joined
timotimo you're right of course, though 21:31
21:34 vendethiel joined
jnthn I got a graph out 21:54
timotimo you got a ... what? 21:59
jnthn The shape of the concat benchmarks on Moar is now a lot better
timotimo oh yeah! :D
jnthn I'm currently seeing if I can get bench to do a 2014.06 on the graph too
timotimo you'll just have to put rakudo-moar/2-14.06 into the commandline for "compar" 22:01
jnthn Well, need to time before I can compare :) 22:05
timotimo ah, of course 22:08
jnthn Bad news is parse-json didn't run, so I've a bug to hunt yet. 22:11
timotimo ah, but it's good we found it that way :) 22:13
jnthn jnthn.net/perl6/bench/2014-07-13.html 22:42
Overall, it's been a good month for Rakudo performance.
I need to look into trim_string, though. 22:43
It's the only one where we've gotten worse.
Well, and the json-parse bug I already know about.
timotimo what the ... 22:44
how did we get all this performance?
jnthn Well, think about what's landed
OSR
The string thing I've just been doing
The for range optimization.
timotimo ah, for range, i thought that was already in last month
jnthn Improved inlining. :)
It was apart from it didn't work on the benchmarks 22:45
timotimo and OSR, too. but i realize now that that's still fairly recent
jnthn 'cus of the extra parens.
timotimo that was an amusing bug 22:46
jnthn Provided 2014.08 brings us JIT, that should be another boost. 22:47
timotimo oh yeah 22:48
jnthn Still plenty to do.
timotimo a jit that doesn't bail on almost every non-trivial piece of code :)
jnthn But the progress over a year is quite good.
timotimo jit won't be improving the memory usage, though :(
jnthn Especially given the graphs are log graphs...
No, true.
timotimo well, piecewise loading of the setting would be a *huge* help, whenever that ends up happening 22:49
i'd almost claim that'd solve all our troubles
it'd be at least a 10x improvement
for simple one-liners
nothing near a cpython or perl5 process, but still a great win
[Coke] m: { my $a = 3; sub blah() { $a++}}; blah;blah;blah.say 23:01
camelia rakudo-moar b25b86: OUTPUT«===SORRY!=== Error while compiling /tmp/Vm5ui2Jp7h␤Undeclared routine:␤ blah used at line 1␤␤»
[Coke] how can I get visibility to that sub outside that block? 23:02
(S02-names-vars/variables-and-packages.t)
vendethiel our sub ?
m: { my $a = 3; our sub blah() { $a++}}; blah;blah;blah.say
camelia rakudo-moar b25b86: OUTPUT«===SORRY!=== Error while compiling /tmp/87MVVARBnM␤Undeclared routine:␤ blah used at line 1␤␤»
vendethiel eh.
jnthn our, and then &OUR::blah() on the outside.
The lexical scoping rules on sub calls are very, well, lexical... But the typo catching is worth it :) 23:03
vendethiel thinks it indeed is :o) 23:08
dalek href="https://moarvm.org:">moarvm.org: eee7f57 | Carlin++ | roadmap.html:
fix typo in roadmap --> s/Repalcement/Replacement
23:30
href="https://moarvm.org:">moarvm.org: 69ba63c | jonathan++ | roadmap.html:
Merge pull request #5 from carbin/patch-1

fix typo in roadmap --> s/Repalcement/Replacement
23:34 raiph joined
jnthn 'night 23:58