00:31 vendethiel joined 00:59 ggoebel7 joined 01:03 vendethiel joined 02:49 ilbot3 joined 03:34 leedo joined 04:08 vendethiel joined 07:44 FROGGS joined 07:48 domidumont joined 07:54 domidumont joined 08:02 zakharyas joined
dalek arVM: 94b1b63 | FROGGS++ | README.markdown:
state that gcc on Windows® works too
 08:18
08:59 vendethiel joined 09:35 virtualsue joined 09:46 brrt joined 09:51 vendethiel joined 10:36 vendethiel joined 10:59 vendethiel joined 11:02 brrt_ joined 11:09 virtualsue joined 11:17 virtualsue joined 12:08 virtualsue joined 12:27 vendethiel joined 12:38 virtualsue joined 12:40 leont joined 12:42 vendethiel- joined 12:53 ilbot3 joined 13:08 vendethiel joined 13:58 vendethiel joined 14:36 virtualsue joined 14:46 vendethiel joined 15:50 vendethiel joined 16:31 vendethiel joined 16:34 virtualsue joined 16:54 vendethiel joined 17:06 kjs_ joined 17:18 kjs_ joined 17:19 vendethiel joined
jnthn is back home, after a 5 hour trip that turned into an 11 hour trip... :/ 17:47
timotimo bleh. damn those planes
17:48 kjs_ joined
jnthn Yeah... 17:48
6 hour delay on a 2 hour flight
TimToady welcome home, anyway 17:50
jnthn Yes, nice to be back...and to be staying here for a good while :)
leont I know that feeling :-( 17:51
TimToady understands completely, having been right on the ragged edge over the holidays himownself
leont "You have 5 hours delay, here is a €10 coupon, it can almost buy you a decent breakfast" 17:52
jnthn Wow, you got a coupon! 17:53
At least KBP has free wifi... :)
17:53 patrickz joined
jnthn Anyways, tomorrow will be swallowed by recovering from the journey, visiting lawyer, and most likely a tedious but important errand. 17:55
And after that I'll probably start to ease myself back into things...slooowly. :)
timotimo +1 on the "sloooowly" bit :)
do you already have a list of "things i'd love to optimize first"? ;) 17:56
jnthn Well, -Ofun will probably be doing some stuff down at Moar level :) 17:57
timotimo how -Ofun does it feel to guide me while i'm hopelessly bumbling around at the NQP level? :P 17:58
jnthn (Improving invocation performance, looking at using PICs for type data collection, showing spesh/JIT work off to a background thread, etc.)
*shoving
timotimo right now, spesh/jit only accounts for sub 10% on most workloads i've tried :P 17:59
jnthn I've not really kept up at all with what's happened in the last weeks. :)
Hey, we're normally happy with 10% ;)
I was pondering that thread being a general "service" thread and pushing finalization off to it also. 18:00
To get GC times down some.
timotimo ah, yes, finalization
jnthn Anyway, no shortage of ideas, at least... :)
timotimo aye
i was hoping i could perhaps tackle the "lexical refs prevent inlining" problem 18:01
jnthn Having spent the last however many months mostly chasing semantic bugs down ahead of 6.c, I'd be quite happy to be focusing on something other than that for a bit, anyways. :) 18:02
timotimo but i have not looked at the code actually yet
yeah, definitely
jnthn (lexicalref) Yeah, that's a cop out. :) The point was that inlining of things getting passed them can often make them go away :) 18:03
timotimo i had been looking at a little benchmark of a eratosthenes sieve and using Int was faster than int
jnthn But it was a bit tricky to get the analysis right, let alone the transform. :)
So it got punted.
timotimo you mean the analysis and transform inside spesh? 18:04
jnthn Yes
timotimo right; for an operator that doesn't "is rw" in the argument list, though, it'd be lovely if we didn't take a ref 18:05
jnthn yeah, indeed :)
timotimo the "Int" version had things like <, + and such inlined, the int version ... nothing at all :|
jnthn There's plenty of inter-routine even-when-we-don't-inline info that it'd be nice to ponder 18:06
timotimo oh, would we need such a mechanism to say "we don't have rw in the signature"? i thought it'd be accessible by the same parts the inliner looks at anyway
18:07 vendethiel joined
jnthn Not sure it'll be a complex mechanism, I just think it's worth formalizing a little how it's done. 18:07
Escape analysis might want such things :)
timotimo ooooh
but that's spesh-level, not qast level
which is where i'm looking right now 18:08
jnthn Ah 18:11
timotimo er, "looking right now" is ... overpromising
jnthn Well, Rakudo's inliner should really be inlining ==, <, > and the like on native ints.
It was a one point, I thought. Maybe we lost that.
timotimo yeah, it stopped doing that when we introduced lexicalrefs 18:12
i thought i whined about it often enough? ;)
jnthn Um...yeah, you did, I ignored it 'cus my plate was full
Now it's...uh...well, folks didn't fill it up again yet :P
timotimo :D 18:13
bbiab
as i said, i'm hoping i could maybe make it work again, but it'll definitely require a bit of guidance
this time around i'll try to only ask you when i've rubber-ducked someone else, so i don't bug you more than necessary 18:14
jnthn It's something we'd really like to get working again :) 18:15
18:23 patrickz joined
JimmyZ welcome back, jnthn :) 18:27
timotimo jnthn: is there any reason to keep takeclosure calls "as early as possible" rather than putting them "as late as possible"? 18:33
i should make a measurement if it actually makes a difference in the cases i'm thinking of 18:45
18:54 kjs_ joined 18:55 TimToady joined
JimmyZ jnthn: irclog.perlgeek.de/moarvm/2016-01-08#i_11853242 # Do we need to re-order it? 19:00
19:01 vendethiel joined 19:05 domidumont joined
[Coke] (optimizations) I don't know how hard it would be to test optimizations (and where does it make sense to test them? a separate test suite run by rakudo but owned by moar?), but if we don't test, we'll backslide again. 19:11
(make opttest in rakudo that works like spectest but on a different repo) 19:12
timotimo it'd seem like we'd need a flag for every optimization to turn it on or off? or would it be enough to test --optimize=0 vs --optimize=3 ? 19:19
some optimizations depend on others, too
[Coke] we could go the compiler route (give everything a command line switch) or the friendly route (we know what works together, here's a few simple options). 19:20
I lean towards few options, because then we can cheat. 19:21
dalek arVM: 2c69687 | (Jimmy Zhuo)++ | src/core/oplist:
mark flattenropes, graphs_s and codes_s as DEPRECATED
 19:47
jnthn Ain't the regex engine using flattenropes? 19:48
JimmyZ jnthn: I found it's needless
jnthn Why? 19:49
19:49 kjs_ joined
jnthn The regex engine could do with strings it can cheaply scan 19:49
JimmyZ jnthn: because before chars op don't need call flattenropes op 19:50
jnthn ??
That's entirely not the point of it.
The point is to turn the string into a flat buffer that's really cheap to index into. 19:51
timotimo jnthn: could this be the right place to look? github.com/rakudo/rakudo/blob/nom/....nqp#L1021 - perhaps here i'd have to check for int or intref and so on?
jnthn What replaces graphs_s and codes_s?
Is graphs_s just a dupe of chars?
JimmyZ jnthn: yes
jnthn And codes_s? 19:52
JimmyZ and codes_s not used anywhere
jnthn Rakudo really should be using it for .codes
I wonder how it implements that today...
timotimo isn't _s usually the one that has a literal string argument?
jnthn No, just means "works on a string" 19:53
timotimo ok
jnthn const_s works that way
timotimo ah
jnthn Anyway, I think the only one of those deprecations I agree with is graphs_s
Which it turns out is a dupe...probably.
JimmyZ github.com/perl6/nqp/commit/3af6e6f49d
jnthn JimmyZ: Rejected.
JimmyZ jnthn: see ^^^
jnthn Yes, graphs_s can go 19:54
JimmyZ jnthn: and I found codes_s is not used even in nqp and rakudo
jnthn But flattenrpoes stays
Yes, but you're noticing things and then drawing dumb conclusions.
multi method codes(Str:D:) returns Int:D { 19:55
#?if moar
self.NFC.codes
That should really use codes
We just didn't get around to doing that.
JimmyZ jnthn: so codes_s will be useful, but not now?
jnthn Right
And flattenropes is useful now. 19:56
Consider ($foo ~ $bar) ~~ /.../
timotimo flattenropes means we can't regex-match things created with the x operator without allocating lots of memory? 19:57
jnthn timotimo: You can't rely on that anyway 19:58
timotimo OK
jnthn And it's a bit contrived
Whereas "I just concatenated some things together I got in over a socket, and want to see if I can parse out a full message" is pretty common 19:59
JimmyZ jnthn: why not move flattenropes code to chars op, since we may do nqp::chars($foo ~ $bar);
jnthn Why could we do that?
We already keep the number of chars cached 20:00
We don't need to flatten
Anyway, the answer is no, flattenropes stays.
As does codes_s
timotimo a quick comment about my link above, jnthn?
m: my int $foo; sub test(int $a is rw) { say $a.WHAT }; test($foo); 20:01
camelia rakudo-moar 42a583: OUTPUT«(Int)␤»
timotimo how did i get IntLexRef from .WHAT again ...
jnthn It'd have to be .VAR.WHAT I think
JimmyZ jnthn: ok, I just can't understand it :P , from github.com/perl6/nqp/commit/3af6e6f49d , flatten $tgt is only used by chars op
timotimo oh, of course
m: my int $foo; sub test(int $a is rw) { say $a.VAR.WHAT }; test($foo); 20:02
camelia rakudo-moar 42a583: OUTPUT«(IntLexRef)␤»
timotimo m: use nqp; my int $foo; sub test(int $a is rw) { say $a.VAR.WHAT; say nqp::isint($a); say nqp::isint($a.VAR) }; test($foo);
camelia rakudo-moar 42a583: OUTPUT«(IntLexRef)␤0␤0␤»
timotimo neither of those give 1 for isint?
jnthn JimmyZ: Note that it flattens in-place.
timotimo: No, since that's more about "can I unbox it to a native int" or so 20:03
timotimo does "that" refer to isint or the link to trial_bind i put in the channel? 20:04
JimmyZ jnthn: irclog.perlgeek.de/moarvm/2016-01-08#i_11853242 # Do we need to re-order it?
jnthn timotimo: isint
timotimo OK; that'd mean isint isn't enough for the trial binder, because if there's an is rw, it won't ever give 1 20:05
but i'm not sure what's the right wording to make it acceptable. is istype IntLexRef correct?
jnthn JimmyZ: Well, I'd been keeping it ordered partly 'cus I was concerned about whether compilers would be smart enough to realize it can become a jump table if we out-of-order it, and partly 'cus it just seemed sensible. It may be worth checking if the first is true.
timotimo hm. more something like is its archetype lexref and its nativetype the right one 20:06
jnthn (I don't know; I'd hope MSVC is good enough for it not to matter, for example)
(And GCC/Clang use computed goto...)
JimmyZ jnthn: I tested it, MSVC is good enough 20:07
jnthn OK, good to know.
Well, and bad in that we don't get a cheap MSVC speed-up :P
Anyway, don't feel strongly on it
JimmyZ not sure about tinycc etc
jnthn If somebody patches them to fix the ordering, I'm fine with that. But I'm not going to rush to do it myself :) 20:08
timotimo mhh, that's a clever one-liner for finding out the ordering
dalek arVM: 4f86f20 | (Jimmy Zhuo)++ | src/core/oplist:
some ops won't be DEPRECATED
 20:09
JimmyZ 04:09 here ,good night 20:10
jnthn JimmyZ++ # thanks
'night o/
timotimo gnite JimmyZ
jnthn Time for a stroll, after all day cooped up in an airport...then probably rest. :) Will be about a bit tomorrow, I expect. :) 20:11
timotimo sure 20:12
have a good one!
20:49 patrickz joined
hoelzro Frame_N in a MoarVM dump roughly corresponds to an MVMFrame deserialized by deserialize_context, right? 22:48

Powered by Cro and the Raku® Programming Language.

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

Thank you!