github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:06 Geth left 02:03 frost-lab joined 07:10 domidumont joined
nwc10 good *, #moarvm 07:16
07:57 zakharyas joined
MasterDuke nine: github.com/MoarVM/MoarVM/blob/mast...ze.c#L1957 here i assume you mean? 08:00
nine MasterDuke: yes, that block has 2 early returns 08:08
08:09 domidumont left
MasterDuke yeah, just glancing through it nothing sticks out as to why infix:<**> would exit early 08:10
the 'after' of infix:<**> isn't very big, though `Bytecode size: 1025 byte` is probably still too big to inline 08:14
jnthn Much too big 09:14
nwc10 such big | so uninlineable | bother 09:15
MasterDuke jnthn: have you seen github.com/rakudo/rakudo/pull/4320 ? 09:16
09:19 dogbert11 joined
jnthn Well, saw the description at least. Seems like it makes some cases faster and some cases slower? 09:19
MasterDuke yeah, positive exponents faster, negative ones slower (the positive case speedup decreases as the exponent increases though, since more time is spent in the actual pow_I, but i haven't confirmed if the converse is true for negative exponents) 09:21
09:21 dogbert17 left
jnthn Oh, but we're forcing a bunch of cases through Num that we weren't before 09:22
That seems like it'll change results
Or at least risk losing precision?
MasterDuke well, it passes a spectest 09:23
jnthn Still makes me a bit uneasy
nwc10 Num to do what operation? 09:24
jnthn I'm certainly not a numerics expert, but it feels risky just out of the fact that given n, 1 / n as a Rat can hold more precision than 1 / n as a double, because an entire double is 64 bits, but the denominator of the Rat is alone 64 bits 09:25
The significand of the double is only 53 bits 09:26
nwc10: See the change proposed in github.com/rakudo/rakudo/pull/4320/files
nwc10 thanks
MasterDuke it just seems a little crazy that we're only using the Num return capability of pow_I to signal an error case 09:28
i'm certainly even less of a numerics expert, so please keep the comments/review/suggestions coming 09:31
jnthn Is it only ever used for error cases? 09:32
If you want to try and get it below the inline limit, extracting the error handling part is likely to be a win 09:33
MasterDuke currently, yes. pow_I returns a Num on (over/under)flow or when the exponent is negative 09:34
but right now we negate a negative exponent and then manually construct the Rat 09:35
ah, got the negative case slowdown to only ~3.1s 09:36
by using more nqp:: ops, but bytecode size is unchanged 09:37
jnthn Yeah, I think always passing a positive to pow_I is probably the right way to do this 09:38
nwc10 stuff in $other that I need to pay attention to
but I don't get that 1/ bit - it originates in commit 563abdd46845d70483a21180c817de516003309c
jnthn I do note that it checks b > 0 in two different places
In the original code
Which seems a bit wasteful too
09:38 linkable6 left
nwc10 oh, ah, yes I do 09:38
09:39 linkable6 joined
MasterDuke yeah, if we're going to always pass a positive exponent then i'd work to not do that twice 09:39
09:42 dogbert17 joined
MasterDuke might make sense to change the nqp op, can simplify the moarvm implementation then 09:42
until/unless we switch to gmp, and then additionally use their rationals 09:43
09:45 dogbert11 left 09:58 MasterDuke left, MasterDuke joined
MasterDuke jnthn: oh, back to inlining, why does spesh end up in github.com/MoarVM/MoarVM/blob/mast...ze.c#L1957 instead of saying it can't inline infix:<**> because it's too big? 10:01
jnthn If it's in there, we haven't even figured out what we're calling 10:05
Which is a pre-requisite for inlining
There's two ways we can know what we're calling 10:06
MasterDuke i see messages about identity getting inlined *into* infix:<**>
jnthn 1. Statistically, a given static frame almost always shows up
2. We've proven that the code object is a constant
2 is always preferable because we don't need an extra guard 10:07
But 1 gets us inlining of things like closures where the code object is a closure clone, for example.
The code path you asked about happens when 2 is the case
MasterDuke there is a type specialization of infix:<**>: Callsite 0x7f3e2a886840 (2 args, 2 pos) ... Positional flags: obj, obj ... Which received 291 hits (100% of the 291 callsite hits) 10:08
heh, gist.github.com/MasterDuke17/95314...04fef337c3 increases the bytecode size to 4358? 10:10
11:16 zakharyas left
MasterDuke pushed a newer commit to github.com/rakudo/rakudo/pull/4320 that speeds up both positive and negative exponents, but keeps the behavior of only passing positive exponents to pow_I 11:20
lizmat MasterDuke: did you try to not use \a \b but $a $b ? then you could lose the nqp::decont() s 11:30
MasterDuke i haven't 11:31
11:31 frost-lab left
lizmat also: perhaps put the Failure.new branch into a separate sub / R:Internals method reducing the bytecode size of the infix:<**> code itself 11:31
MasterDuke i tried that 1.5 versions ago and it didn't make a difference 11:32
lizmat or at least put it's .new outside of the condition
MasterDuke but, i also noticed bytecode size changed with the moarvm alway-log-deconts commit reverted
lizmat anyways, that would be things I would try 11:33
MasterDuke and since i'm not entirely sure what's going to happen with that commit, wasn't too worried about bytecode size, since it's currently *way* above the inline limit 11:34
lizmat also: did you consider splitting code paths completely on b being >= 0 ? 11:36
MasterDuke 5th version that does that just about to be pushed
pushed 11:37
bunch of different versions in github.com/rakudo/rakudo/pull/4320 now, tldr; can keep original behavior wrt negative exponents and still be faster for both positive and negative exponents, but (still) nowhere near small enough to inline 11:51
11:52 domidumont joined
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/04/13/2021-...irst-conf/ 12:52
12:56 zakharyas joined
MasterDuke neither NQP nor Rakudo ever use nqp::pow_I for the Num value (i.e., they only over pass in positive exponents), other than to signify overflow. what about changing its implementation to expect positive exponents and instead return just an Int type object on overflow? then all the nqp::istype($foo, Num) could instead be !nqp::isconcrete($foo) and 14:25
MoarVM's MVM_bigint_pow could be simplified
greppable6: nqp::pow_I
greppable6 MasterDuke, 1 line, 1 module: gist.github.com/cafb15405328489b39...9329c768c7
MasterDuke only positive values used there ^^^ 14:28
jnthn Are there not different kinds of error that it singals with nan/+inf/-inf? 14:29
MasterDuke yeah. but we never use them and instead figure out in rakudo 14:30
all rakudo ever checks for is istype(Num) 14:32
MVM_bigint_pow returns -inf or +inf, but not nan 14:34
and for negative exponents we just use pow(), libtommath doesn't support them 14:36
jnthn Ah, but we can recreate whether it's +inf or -inf back in Raku land anyway... 15:11
Yeah, then the simplification seems reasonable to me
MasterDuke cool. not entirely sure how much it will speed things up, but i don't think it will be a terribly time consuming experiment to try 15:13
jnthn Even if it doesn't, it's a nice simplification? 15:17
MasterDuke hopefully. simplification in the other direction would be pow_I to return a Failure with the appropriate Exception inside, but i don't think we can do that, right? 15:19
arg, bootstrapping in nqp bites again 15:48
lizmat Failure, I'd say no
but throwing an exception and catching that with nqp::handle maybe ? 15:49
MasterDuke but is that going to be any faster than the current checking done in rakudo?
jnthn isconcrete is a pretty cheap check 15:57
We could also maybe stick logging on the pow_I op so that we log its result and then can do guard and maybe toss out the error branch if we rarely hit 15:58
it
That could get it below the inline size
MasterDuke btw, returning a type object is just `return MVM_repr_alloc_init(tc, int_type);`, correct? 15:59
jnthn No, it's just `return int_type->st->WHAT;` 16:02
MasterDuke thanks 16:03
cog /join #typescript 16:24
oops
16:27 zakharyas left
lizmat cog: you traitor, you! :-) 16:40
jnthn I suspect a lot of the things typescript is commonly used for (web frontend) are things you simply can't use Raku for today. :) 16:48
nine I guess we can let this one slide....for now :D 16:49
lizmat actually, it appears that documentable is actually using coffescript 16:51
dinner& 16:55
sena_kun lizmat, it does because we have no normal code highlighters available other than this one. :S 16:57
18:10 domidumont left 19:15 MasterDuke left, MasterDuke joined
cog lizmat, if we want to succeed, we must do like Python and connect to the rest of the world. Here I attempt to write a raku parse tree browser using svelte. 19:28
lizmat ++cog 19:29
cog Too bad the best minds are too busy with optimising raku and MoarVM for lack of manpower 19:31
Speaking of connecting to the rest of the world, the jnthn++ talk mentioned in your weekly seems promising. 19:33
lizmat yes, it is! 19:34
cog I hope some day someone will port the grammar engine to wasm. It could be a success independent of raku like PCRE independent of Perl. 19:43
19:44 zakharyas joined
cog Speaking of connecting I just discovered an old and probably well known Eric Raymond article on why he dropped Perl. Like him about the same time, I wrote some code using Perl and TCL/TK for the front end. It was not pretty. www.linuxjournal.com/article/3882 19:52
lizmat where has the time gone :-) 19:55
nwc10 MasterDuke perhaps some code to run through the various checkers:
$ r 'my %h = "a" .. "e" Z=> 1..5; for %h.keys { %h{$_~$_} = 42 }'
concatenate requires a concrete string, but got null
does so in about 1 in 10 times for me
MasterDuke dogbert17 is also great at this 19:56
cog In the mean time some guy also realised the Perl limitations and threw mugs at a wall. Hopefully not at Larry Wall.
lizmat no BDFLs where hurt in that incident :-) 19:59
cog Sveltes has a raku slang mindset. Messing with CSS, Dom and typescript/js slangs to create components. 20:00
dogbert17 lizmat, MasterDuke: you called :) gist.github.com/dogbert17/53ac5d32...42a60dc8cf 20:16
lizmat conclusion? 20:17
dogbert17 good question, the valgrind error only show up when something goes wrong, but why it wants to print this error is still a myster (to me) 20:20
*mystery 20:21
MasterDuke arg. i misspell 'nqp' as 'npq' and get `Cannot find method 'package_at_key' on 'BOOTHash': no method cache and no .^find_method` which is of no help. i'd be a fan of specially casing that error 20:28
lizmat same for nap ? 20:29
that's a common error I make
m: nap:say("foo")
camelia 5===SORRY!5=== Error while compiling <tmp>
Undeclared routine:
nap:say<foo> used at line 1
lizmat but the error at least is less LTA
MasterDuke m: nap::say("foo") 20:30
camelia Could not find symbol '&say' in 'GLOBAL::nap'
in block <unit> at <tmp> line 1
MasterDuke nqp: nap::say("foo")
camelia Cannot invoke this object (REPR: P6opaque; NQPMu)
at <tmp>:1 (<ephemeral file>:<mainline>)
from gen/moar/stage2/NQPHLL.nqp:1946 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/NQPHLL.nqp:2151 (/home/camelia/rak…
MasterDuke nqp: npq::say("foo")
camelia Cannot invoke this object (REPR: P6opaque; NQPMu)
at <tmp>:1 (<ephemeral file>:<mainline>)
from gen/moar/stage2/NQPHLL.nqp:1946 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:eval)
from gen/moar/stage2/NQPHLL.nqp:2151 (/home/camelia/rak…
lizmat I guess about the same in nqp :-)
MasterDuke i get the error i copied when compiling rakudo 20:31
dogbert17 lizmat: the fact that you're changing the hash while iterating its keys, couldn't that be problematic? 20:37
lizmat well, yes, that may be the case...
but it was my understanding that nwc10 had fixed any breakage in the iterator, when keys are added 20:38
if that understanding is wrong, then I guess it's a case of DIHWIDT
dogbert17 try this variant a couple of times my %h = "a" .. "e" Z=> 1..5; for %h.keys { say $_; %h{$_~$_} = 42 }; say %h 20:39
lizmat or otherwise, maybe we should make .keys on Associative be eager by default, then served by a lazy iterator
wow, ASSIGN-POS appearing as name ??
dogbert17 I got BIND-KEY once 20:40
lizmat keys.eager never fails, right ? 20:41
so that is at least a workaround
dogbert17 perhaps we should check with nwc10 20:42
but yes eager works
MasterDuke there are a couple combinations of options wrt infix:<**> and pow_I: just change how overflows are reported, disallow negative exponents, special case certain values in moarvm, special case certain values in rakudo 20:45
the benefit to special casing certain values (e.g., 0, 1, 2) in rakudo is that you can skip most to all of the error handing required for pow_I. the downside is infix:<**> will get bigger 20:48
the benefit to special casing certain values (e.g., 0, 1, 2) in moarvm is that you can skip some of the overhead of actually calling the libtommath function. the downside is that for every call to pow_I you pay the cost of the extra conditionals 20:51
interestingly, the libtommath function has no special casing itself, but the gmp function does (there is still some benefit to doing the special casing in moarvm before calling the gmp function, just less so than for libtommath) 20:55
21:00 zakharyas left 21:21 dogbert11 joined 21:25 dogbert17 left 22:03 dogbert11 left 22:11 dogbert11 joined 22:18 dogbert11 left, dogbert11 joined 22:28 dogbert11 left 22:29 dogbert11 joined 22:36 dogbert17 joined 22:38 dogbert11 left 22:40 dogbert11 joined 22:43 dogbert17 left, dogbert17 joined 22:46 dogbert11 left 22:57 dogbert17 left 22:58 dogbert17 joined 23:52 MasterDuke left

Powered by Cro and the Raku® Programming Language.

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

Thank you!