| IRC logs at
Set by AlexDaniel on 12 June 2018.
01:03 pamplemousse joined 01:19 pamplemousse left 07:00 sena_kun joined
MasterDuke timotimo: it's from implementing the neither bigint is big branch 07:27
and simplifying `infix:<%>` 07:32
maybe a better test `my $a = 0; for ^10_000_000 { $a += $_ % 3; $a += $_ % -5; $a += $_ % 258 }; say now - INIT now; say $a` gives the same results, but goes from ~5.8s to 3.8s (this is all on my gmp branch, but changing non-(gmp/tommath) code 07:41
currently src/math/bigintops.c is just shy of 600 lines shorter on my branch 07:47
09:42 Altai-man joined 09:44 sena_kun left 10:06 Altreus_ joined 10:08 codesections left, codesections joined, Altreus left
lizmat MasterDuke++ 10:28
11:56 Kaiepi left 11:58 Kaiepi joined 12:08 Kaiepi left 12:11 leont joined, Kaiepi joined 12:16 Kaiepi left
nine I think, there's only one more big stumbling block on the way to in-process-precompilation. It's the type parameterization cache. This cache is vital for correct functioning as multiple parameterizations with the same type and same arguments must result in the same type object. But same object also means that it may come from an earlier compilation. 12:29
timotimo: do you have any idea for me how to get around this?
12:30 Kaiepi joined
timotimo do we have the solution for when something should be shared vs when it shouldn't? 12:32
does scdisclaim do anything useful here?
nine You mean like after we precompiled, sc_disclaim, so e.g. those parameterized types will get added to a future compilation's sc? 12:34
timotimo possibly
i'm operating on not much or at least not good sleep, so kind of cloudy perception and thinking in my head
at least scdisclaim would prevent a CU from depending on an "external" SC "just because" it pulled an earlier cached parameterized type out of the cache 12:35
but when we now load another SC later, the check would still be identity? or only identity of the parameters probably 12:36
nine There's a resolve_param_interns which de-duplicates those types if I understand this correctly 12:40
Intriguingly with the parameterizations, the failure mode is not a superfluous dependency on some different SC but a failure to serialize: STable %s does not exist in serialization context 12:41
timotimo oh, huh. 12:52
maybe whenever we pull something out of the parameterization cache we need to grab its ST and add it to the current compilee's SC
nine I've tried that but didn't get terribly far. Could be a good approach anyway, but I probably luck understanding to make sense of how it goes wrong 12:53
.oO( such a small difference between lack and luck )
nine Hah! Small difference in words, huge difference in results
Oh...scdisclaim does make a difference. It fixes the golfed example, even though it causes "Object of type Block is QAST::Block code object, but not in SC" elsewhere 13:09
13:09 Kaiepi left, Kaiepi joined
timotimo code object, huh? 13:10
nine Also it breaks the parameterized type cache somehow. Type comparisons now fail when done in the process that precompiled the library but succeed in subsequent runs (where we use the already precompiled module) 13:27
lizmat wouldn't the module being precompiled not have a completely different parameterized cache ? 13:32
a clone of the one that existed when the process started ?
aka, make the parameterized type cache a parameter of the precompilation ? 13:33
nine That cache hangs of the STable, i.e. the type description in the VM. 13:34
timotimo ah, right
that's the paramet. attribute in the struct
nine st->paramet.ric.lookup 13:35
13:42 sena_kun joined 13:44 Altai-man left
timotimo just throwing a random thing, does there have to be something special to handle that the parameterizers are usually closures with their own objects they close over? 14:09
nine I don't see much special handling. 14:17
In the spec tests the parameterizer is usually loaded from the setting as those tests parameterize Hash 14:19
timotimo i don't really mean whether we have any special handling, more that it may be needed 14:21
nine Well it's certainly something to keep in mind and something that could keep an additional test 14:26
15:01 domidumont joined 15:20 domidumont1 joined 15:22 domidumont left
nine Fun fact: the scdisclaim op has been added in 2015 but never actually used anywhere 15:26
So it's quite possible that it's even buggy 15:27
16:24 hankache joined
timotimo froggs used it for serializing simple datastructures without causing annoying sc deps 16:25
16:51 hankache left 16:56 pamplemousse joined 17:08 domidumont1 left 17:10 pamplemousse left 17:41 Altai-man joined 17:44 sena_kun left 17:50 domidumont joined 18:03 domidumont left 20:38 Altai-man left 21:07 brrt joined 22:14 brrt left 23:08 leont left