|
01:06
coleman left
01:07
coleman joined
02:55
guifa left
03:02
guifa joined
04:24
guifa left
|
|||
| patrickb | github.com/ugexe/zef/blob/main/lib...kumod#L343 this is one of the places with that code | 08:34 | |
|
08:57
[Tux] left
09:01
[Tux] joined
11:16
finanalyst joined
11:34
finanalyst left
11:47
finanalyst joined
|
|||
| nine | &str2identity is supposed to be imported from Zef::Identity. Seems like such symbols are not yet treated equally to lexically declared ones. | 12:25 | |
|
13:08
guifa joined
13:22
guifa left
13:48
finanalyst left
|
|||
| Geth | rakudo/fixup-logic-gap: 0cff0f43ee | ab5tract++ | src/Perl6/Metamodel/ParametricRoleHOW.nqp fix |
14:21 | |
| rakudo/main: 3babcc695b | ab5tract++ | src/Perl6/Metamodel/ParametricRoleHOW.nqp Fix an inverted logic scenerio for $type_env Because `$type_env` was always defined, we never noticed that the logic was in the wrong order: if isnull($type_env) then fetch from $type_env cache ... (7 more lines) |
14:26 | ||
| ab5tract | ironically enough I'm running into similar problems. in my branch, the above logic inversion surfaced a much more helpful '@!a` is not availabe in frame exception | 14:27 | |
| *my branch for the generics and trait_mod:<is> stuff | 14:28 | ||
| lizmat: interested in benchmarking the effects of this type_env cache fix? | 14:31 | ||
| lizmat | on it | 14:32 | |
| ab5tract | š | 14:34 | |
| lizmat | maybe 1% in the benchmark I use... so well within noise | 14:40 | |
| $ mvm-profile 'sub foo($a) { $a * $a }; foo($_) for ^1000000' | 14:41 | ||
| ( from raku.land/zef:lizmat/MoarVM::Profile ) | |||
| timo | i'm not sure if that benchmark in particular exercises the code from the commit at all? | 14:42 | |
| lizmat | ok, what should I use then ? | 14:43 | |
| timo | core setting compilation might be a candidate, or spec test if you have the time | ||
| tbh i didn't look at the commit maybe ab5tract has a better suggestion | |||
| ab5tract | Yeah anything that exercises the type env, which I guess is primarily parametric roles and the punning thereof | 14:44 | |
| But it is conceivable that we might see something at the core setting compilation level | 14:45 | ||
| Specters āfelt fasterā but thatās clearly subjective | 14:46 | ||
| *spectest | |||
| lizmat | spectest was within noise for me (70 -> 69) | 14:47 | |
| timo | i would assume that spec tests are quite variable already | ||
| lizmat | yeah, definitely within noise | ||
| role A { has $.a = 42 }; A.new for ^100000 | 14:48 | ||
| within noise | |||
| timo | i think it requires things like a type parameter being used for something | 14:49 | |
| at the point where A.new has happened for the first time we should already have a pun of the role ready to go for every further creation | 14:50 | ||
| ugexe | role { has $.a = 42 }.new for ^10000 | 14:53 | |
| lizmat | that last one is (with one 0 more) from 108.5ms -> 105.5 ms | 14:58 | |
| so I'd say for that case, we haz a win | |||
| ab5tract | I'm going to try something more expansive. | 15:18 | |
| well that's unexpected... | 15:20 | ||
| my commit makes things slower | |||
| gist.github.com/ab5tract/42d1db5d3...f7cc09d1dc | 15:21 | ||
| nevermind me | 15:22 | ||
| timo | why are we calling instantiate generic with $type_env as a parameter in the case where type_env is null? | 15:24 | |
| ab5tract | because there are null checks at that level | 15:25 | |
| but generally, it's never null | 15:26 | ||
| timo | ok, so it could have been literally nqp::null at that position, too instead of the variable | 15:27 | |
| ab5tract | timo: I debated whether to make it explicitly null in the call to instantiate_generic, but couldn't decide so just left it as is | ||
|
15:49
rakkable left
15:50
rakkable joined
|
|||