@@ -13,10 +13,10 @@ compiled, thus avoiding the invalidation.
13
13
The reason for this package essentially comes down to over-aggressive world-splitting optimizations. There's
14
14
multiple sources on this optimization:
15
15
16
- * https://discourse.julialang.org/t/avoiding-vectors-of-abstract-types/61883/20
17
- * https://discourse.julialang.org/t/how-is-it-that-new-julia-programmers-tend-to-abuse-type-annotations/108465/19
18
- * https://discourse.julialang.org/t/does-julia-create-a-1-5-language-problem/107984/110
19
- * https://discourse.julialang.org/t/static-jl-vs-staticnumbers-jl/87228/21
16
+ - https://discourse.julialang.org/t/avoiding-vectors-of-abstract-types/61883/20
17
+ - https://discourse.julialang.org/t/how-is-it-that-new-julia-programmers-tend-to-abuse-type-annotations/108465/19
18
+ - https://discourse.julialang.org/t/does-julia-create-a-1-5-language-problem/107984/110
19
+ - https://discourse.julialang.org/t/static-jl-vs-staticnumbers-jl/87228/21
20
20
21
21
Basically what happens is that Julia's base image specializes on all of the dispatches it sees in the
22
22
world that it builds. So for example, in Julia's Base image, you see that ` <(x,y) ` always returns a Bool.
@@ -28,7 +28,7 @@ However, enter a library like Symbolics.jl which adds a method `<(x::Num, y)::Nu
28
28
represented symbolically rather than eagerly evaluated into a Bool. This breaks the world-splitting
29
29
assumptions and thus every single code that assumed ` < ` would output a Bool has to be recompiled.
30
30
However, you can see that it's not only Symbolics.jl that does this, but Static.jl, TaylorModels.jl,
31
- tracers defined in JuMP, ..., there's a huge list of libraries that can trigger this invalidation.
31
+ tracers defined in JuMP, ..., there's a huge list of libraries that can trigger this invalidation.
32
32
33
33
** The issue isn't that these packages are abnormal, it's that Julia's Base image is really abnormal!**
34
34
** It's a world with effectively no standard Julia code and no standard Julia package**
@@ -72,9 +72,9 @@ But whatever the matter is, it's very clear that `@recompile_invalidations` is s
72
72
too high of a level in those scenarios. What we really want is to simply trigger the invalidations
73
73
we know we will have in Pkg, the REPL, etc., force the construction of a new image, and keep that
74
74
around for the future. And since we know "most" (according to JuliaHub statistics, around 1300 out of
75
- 6000 for Static.jl alone) packages will hit these same invalidators, we might as well put it as the
76
- very bottom of the dependency chain so that this only happens once, and if this package never changes
77
- (or almost never changes), this precompilation only happens the first time you install Julia packages.
75
+ 6000 for Static.jl alone) packages will hit these same invalidators, we might as well put it as the
76
+ very bottom of the dependency chain so that this only happens once, and if this package never changes
77
+ (or almost never changes), this precompilation only happens the first time you install Julia packages.
78
78
All subsequent updates can then reuse the world that comes after this invalidation fix.
79
79
80
80
That of course leads directly to CommonWorldInvalidations.jl.
@@ -86,5 +86,5 @@ That is another possible solution. That solution requires convincing everyone th
86
86
in cases where these packages aren't used. Of course I throw out 10% as a number I haven't actually measured.
87
87
The point is, you'd have to go measure a ton of things and convince a ton of people on each method
88
88
despecialization, which may take a lot of time and effort. We would like to see this change happen in Base,
89
- but until that happens, CommonWorldInvalidations.jl effectively renders this a non-issue and we can
89
+ but until that happens, CommonWorldInvalidations.jl effectively renders this a non-issue and we can
90
90
move on with our lives with this simple little hack in place.
0 commit comments