| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:49 evalable6 left, linkable6 left 00:51 evalable6 joined, linkable6 joined 01:05 cog joined 01:16 japhb joined 01:58 MasterDuke left 02:02 Voldenet joined, Voldenet left, Voldenet joined 05:37 frost-lab joined
nwc10 good *, #moarvm 06:00
06:07 domidumont joined 07:00 MasterDuke joined
nwc10 jnthn: did you see this -- The results of the comparison supportour argument from Sect. 2 that MyPy and PyType are essen-tially two different type systems. For most major program-ming languages, such a finding would come as a shock, soit is somewhat surprising to find Python in this situation 07:03
gah, PDF copy-paste eats spaces sometimes
also for what they tested, there were a lot of errors. They wondered if annotations are being used more as documentation than actual type checking. And of course, it doesn't help that there's no runtime type checking. 07:04
MasterDuke jnthn: yeah, when i tried with MVM_SPESH_BLOCKING the difference between an un-used where and no where disappeared 07:30
07:49 zakharyas joined 09:10 Kaeipi joined
nwc10 r: say 1e23 09:11
camelia Error while reading '/home/camelia/p6eval-token': Permission denied at /home/camelia/rakudo-j-inst/bin/ line 10.
nwc10 r: say 1e23-9.9999999999999992e+22 09:12
camelia 0
nwc10 today, this is not my favourite number.
if you format it with %15g, it comes out as 1e23. %16g or %17g gives the other representation.
MasterDuke jnthn: question you probably have some idea about 09:17
Geth MoarVM: MasterDuke17++ created pull request #1470:
Simplify pow_I and change to never return Nums
jnthn 10:02
MasterDuke: That's odd, I can imagine it being inlined, but if it's not being...that's strange 10:03
MasterDuke yeah, there's some more chat over in #raku-dev 10:05
10:08 MasterDuke left 10:09 MasterDuke joined 11:17 zakharyas left 11:22 moritz_ is now known as moritz 12:34 demostanis[m] joined 12:35 demostanis[m] left
lizmat [14:37:37] <demostanis[m]>Saying this here as I can't write in #moarvm, it looks like MoarVM/libatomic_ops is outdated, it would be great to either use the original repo or to merge some PRs (such as 12:39
jnthn Uh...why can't they write here? 12:42
MasterDuke i assume because there's no matrix bridge to here? 12:43
if that's what the [m] after their name means
12:45 demostanis[m] joined, demostanis[m] left
MasterDuke dogbert17: ping, you're good at testing the 3rdparty bumps, looks like libatomicops is a bit out of date of upstream 12:45
tellable6 MasterDuke, I'll pass your message to dogbert17
MasterDuke yeah, it's a matrix thing. "You do not have permission to post to this room. I'm using matrix." 12:46
jnthn: btw, how does one "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"?
nine MasterDuke: think MVM_spesh_log_* calls 12:48
jnthn MasterDuke: Approximately 1) add the :logging (or is it :log) attribute in the oplist and re-generate, 2) tweak the interpreter to perform the result type logging just like ops like getlex_o do, 3) see if you already see it in the spesh stats, 4) probably tweak facts.c (again getlex_o is a good pattern to follow) 12:49
I think the optimizer will then have the facts and do the right thing
MasterDuke thanks. not sure how much more time i'll have today, but will play around with that when i can 12:50
jnthn btw, I realized that smart stringify and smart numify in NQP can eventually go away in favor of new-disp :) 12:53
Less special cases!
MasterDuke but while we're on the subject, does anybody have an opinion re the pow_I op (via its MVM_bigint_pow) ignoring the sign of the exponent and always returning base**|exponent| ? vs doing the negation in nqp/rakudo if required?  they might still have to check the sign of the exponent to decide how to interpret the response, but could at least
unconditionally call pow_I
interesting, new-disp brings all sorts of goodness to the table 12:54
jnthn: btw, will there be any sort of performance change wrt constants for parameters? e.g., multi a($b, 1) { ... }; multi a($b, $c) { ... }; 12:55
jnthn That's the same situation as `where` 12:56
So will get the same benefits as discussed in the blog post
nwc10 fewer special cases vs less pedantry. Oops. :-) 12:57
MasterDuke any possibility for extra optimization of the constant case?
jnthn I think we already code-gen it a bit better 12:59
Oh, you're thinking if the constants match? Hmm. Interesting.
"Not yet" :) 13:00
MasterDuke heh
.oO( I should make less of these English mistakes... )
sena_kun jnthn, but do you really want to prefer other language mistakes... 13:08
nwc10 jnthn: add it to you Czech list of resolutions?
jnthn Czech doesn't do this countable/uncountable silliness, so far as I can tell :P 13:09
MasterDuke i've always found that in interesting rule because of how it potentially conflicts with number theory. e.g., "there are fewer people in the office than in the kitchen" is relatively easy to get correct, and so is "i'd rather have less poverty in the world", but "there are fewer real numbers than there are functions mapping real number to real 13:14
numbers" sounds correct even though both things are uncountable
nwc10 that's a good point. 13:16
jnthn I dunno why I seem to lack the intuition to use "fewer" that many folks apparently have, despite being a native speaker. Wonder if some dialects are less into it than others... 13:17
nwc10 that sounds like a plausible explanation 13:18
lizmat yes, stuff like that can differ in dialects
speakers the local dialect here do not find it strange to refer to their wIve with the local equivalent of "him" or "it" 13:19
MasterDuke ha
13:27 frost-lab left 13:38 zakharyas joined
nine MasterDuke: got it 14:34
MasterDuke oh? 14:35
do tell
Geth MoarVM/propagate_spesh_facts_after_guard_elimination: 74505ce54d | (Stefan Seifert)++ | src/spesh/optimize.c
Propagate spesh facts after optimizing away a guard

When we optimize a guard into a set (for in the hopes of it getting eliminated later on), we missed the opportunity to copy the facts from the source register. This lead to missed optimization opportunities like not inlining a function, because we didn't know that we actually knew the callee.
MasterDuke ha, not a huge change code-wise. does it now say it can't inline infix:<**> because it's too big? 14:42
nine Doesn't actually help with infix:<**> because that's still too large to inline, but we knew that.
At least it's now sp_fastinvoke_o r3(6), r5(1), liti16(0) # [002] could not inline 'infix:<**>' (3541) candidate 0: bytecode is too large to inline
MasterDuke does it help that example at all, even if the inline still isn't happening? 14:43
ooo, it does. locally i see it decreasing from 4.2s to 3.7s 14:45
Can NOT inline infix:<**> (3543) with bytecode size 320 into  (1): target has a :noinline instruction - ins: getlexstatic_o 14:46
nine 1.84x speedup (2.821623668s vs. 5.199049401s) 14:47
sena_kun Wow, that's a nice improvement.
nine my values are on master
rakudo master 14:48
MasterDuke hm, you do have better hardware, right?
sena_kun I know you folks know it, but still a little remainder to try to keep the master in a nice state before release.
nine sena_kun: come on.... pretty much all I do is fix bugs and especially regressions :) 14:49
sena_kun nine, you are doing a really outstanding work, it's just me trying to be extra careful not to dis-communicate about state of things in some silly way. :)
nine just having fun with you.... I appreciate having a dilligent release manager very mcuh 14:50
MasterDuke heh. now i need to go back and re-test rakudo master vs my branch 14:53
(unrelated, but i see that from-posix-nanos and term:<now> can't be inlined either. both because `target has a :noinline instruction - ins: speshresolve`) 14:56
oh, but not a big deal here, they aren't called frequently. they do get inlined when called in a loop 14:59
cog I don't know if their other tools to search issues in many GitHub repoa. But there is viscode notebook extension that does just that demonstrated at about the 10minute of that video. 16:21
Probably useful to search at once in Rakudo/nqp/MoarVM/roast 16:22
lizmat re release: I think the decont logging PR will need to be reverted before release 16:44
as it appears to generally slow down things *and* make things less stable
sena_kun lizmat, please do. 16:56
lizmat sena_kun: I would if I'd be 100% sure what to revert exactly, as some changes followed the PR 16:57
MasterDuke ^^ ??
17:11 Kaeipi left 17:22 domidumont left 17:26 Kaiepi joined
Geth MoarVM: 9481289950 | (Stefan Seifert)++ | src/core/interp.c
Revert "Always log the type coming out of an nqp::decont"

This reverts commit 9b94bab9eb2803e19c4616a4b0d163d96e41cd1b.
The commit is associated with a number of slow downs or even crashes. While it is most probably innocent by itself and just uncovered other existing issues, revert it for the upcoming release to buy us time to investigate thoroughly.
nine lizmat: ^^^
18:12 zakharyas left
MasterDuke nine: after that revert, but with your facts change applied, i get `Can NOT inline infix:<**> (3543) with bytecode size 458 into  (1): bytecode is too large to inline` on my branches 18:19
lizmat I will bump MoarVM and NQP, so sena_kun can do a blin ? 18:37
MasterDuke sure 18:44
18:47 lucasb joined
sena_kun thinks it's time to ping our awesome vrurg for a blin run, alas not him 19:34
19:59 MasterDuke left, MasterDuke joined
nwc10 you wait for ages and then three, er four seem to come along together. So we have Ryū, grissu-exact, errol3 and dragonbox 20:08
MasterDuke hadn't heard about the last two. better in some way than ryu? 20:09
nwc10 possibly. I'm still trying to figure this out.
moon-child iirc ryu needs really big lookup tables
otoh unicode needs _huge_ lookup tables and no one bats an eye so ¯\_(ツ)_/¯
nwc10 dragonbox is linked from the grissu-exact github README - this was not hard to find.
but you have to be looking since that change was made. 20:10
MasterDuke looks like dragonbox is C++17, which might make it a no-go for moarvm? is there a policy on use of c++? 20:12
moon-child I'm sure it could be reimplemented if it were that much better than others 20:13
nwc10 that was my assumption - and hoping to find someone else who had already done this under a suitable licence
moon-child I like ryu 20:14
it's permissively licensed c, and completely portable
nwc10 This is probably the most important thing. The marginal gains of anything else are not worth it. We have finite time. 20:16
japhb Is ryu what we're using now? 20:17
nwc10 no, it's grissu3 with a fallback to sprintf("%17g", ...)
and it turns out that
r: 1e23
camelia WARNINGS for <tmp>:
Useless use of constant floating-point number 1e23 in sink context (line 1)
WARNINGS for <tmp>:
Useless use of constant floating-point number 1e23 in sink context (line 1)
nwc10 r: say 1e23
camelia 9.999999999999999E22
japhb Oof
nwc10 that that fallback isn't correct :-)
japhb Sigh
nwc10 printf %15g woudl be fine for this one 20:18
so I figured that as the bug fix seemed to be "replace sprintf with dtoa"
MasterDuke japhb: btw, did you see ?
[Coke] "release manager"++. I don't think I've ever had someone in that role at a $DAYJOB until this place and it definitely makes a difference!
nwc10 it might be better to use something else, as I knew something else exists
japhb m: use nqp; my @a = nqp::abs_i(nqp::sub_i(nqp::time(),nqp::time())) xx 1000; say @a.min # Transfer of conversation about nqp::time performance from #cro, code from lizmat++
camelia 20
japhb Wait what
lizmat that's weird? 20:19
hnm... my debian box is still at 2021.3
so looks like a MacOS thing then 20:20
japhb MasterDuke: I don't have an SO account either. Heck, I didn't have a Reddit account until lizmat++ nerd-sniped me earlier this week. :-)
MasterDuke whoops, "Our original evaluation of Errol against the prior work of Grisu3 was erroneous. The evaluation indicates a 2x speed improvement over Grisu3. However, corrected performance measurements show a 2x speed loss to Grisu3." 20:21
lizmat 2436
is the lowest nqp::time interval I get on MacOS
japhb OK, at least that indicates my intuition wasn't completely broken, just a different OS.
MasterDuke i just ran that locally and got 20
nwc10 but, Errol can handle the 5% cases that grissu3 can't? So it could act as the fallback?
I still like the idea of ryu if it's just one source file that does 100% 20:22
but that's not for "this week"
MasterDuke sure. but then why not ryu?
nwc10 snap!
moon-child it's harder to do printf with ryu 20:24
can probably be adapted to the task, though
nwc10 notable6: 20:25
notable6 nwc10, I cannot recognize this command. See wiki for some examples:
nwc10 oops
moon-child: seems to be the folloup for printf. I am trying to read the paper
the talk was good.
I am not an expert on any of this. I think I like integers still. 20:26
I fear I'm going to be reduced to saying that I only like booleans. All other types are too fiddly.
moon-child oh, cool, I missed that!
moon-child ♥booleans 20:27
nwc10 completely off topic, but referencing an earlier conversation. It has escaled - previously it was the *unofficial* documentaton that was pre-annotated with memes, to save the Internet effort. Now they even have them on the official signage: 21:04
my figners are very naughty
22:24 Geth left