|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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 www.cs.rpi.edu/~milanova/docs/dls2020.pdf -- 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/eval-client.pl line 10. | ||
| 9.9999999999999992e+22 | |||
| 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 colabti.org/irclogger/irclogger_lo...-04-15#l26 | 09:17 | |
| Geth | MoarVM: MasterDuke17++ created pull request #1470: Simplify pow_I and change to never return Nums |
09:30 | |
| jnthn | 6guts.wordpress.com/2021/04/15/rak...ispatcher/ | 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 github.com/ivmai/libatomic_ops/pull/32) | 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 | ||
| jnthn | .oO( I should make less of these English mistakes... ) |
13:05 | |
| 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. |
14:41 | |
| 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. youtu.be/D-AXZZDTQhM | 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. |
18:00 | |
| 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 | ||
| 9.9999999999999992e+22 | |||
| 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 github.com/rakudo/rakudo/issues/36...-817586922 ? | ||
| [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? | ||
| yeah | |||
| 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: github.com/Raku/whateverable/wiki/Notable | ||
| nwc10 | oops | ||
| moon-child: dl.acm.org/doi/10.1145/3360595 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: twitter.com/bocachicagal/status/13...43463?s=21 | 21:04 | |
| escalted | |||
| my figners are very naughty | |||
|
22:24
Geth left
|
|||