|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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 | |
| lizmat | .oO( such a small difference between lack and luck ) |
12:54 | |
| 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
|
|||