Getting type stability with EinCode #97

sethaxen · 2020-05-04T08:15:15Z

I have a function that computes the product of a square matrix along one dimension of an n-dimensional array. Thus, the returned array is of the same size as the passed array. Because the dimension over which to multiply is only known at runtime, I use EinCode. However, the result is not type-stable. Is there a good way to give OMEinsum more information so the compiler can figure out the return type? Or maybe more generally, what's the best way to contract over a single index shared by two arrays, where the index is only known at runtime?

julia> using OMEinsum

julia> function f(M::AbstractMatrix, V::AbstractArray; dim=1)
           n = ndims(V)
           dimsV = Tuple(Base.OneTo(n))
           dimsY = Base.setindex(dimsV, 0, dim)
           dimsM = (0, dim)
           code = EinCode((dimsV, dimsM), dimsY)
           return einsum(code, (V, M))
       end

julia> M, V = randn(4, 4), randn(10, 4, 2);

julia> f(M, V; dim=2)
10×4×2 Array{Float64,3}:
[:, :, 1] =
  1.19814   -2.83308   -0.82374    6.23831
 -3.856      1.35973    0.168978   1.15039
  3.60948   -2.782     -0.735527   1.44291
 -4.52866    0.361779   0.807384   3.24125
  2.74821    1.30956    1.20418   -5.25221
  4.45576   -0.632032  -1.40112   -5.93926
 -2.1384     0.81895    0.187812  -1.01684
  4.51044   -1.39046   -0.798984  -3.6388
 -0.987397  -0.393374  -1.85841   -0.326891
 -3.02511    2.97092    2.33957   -3.35689

[:, :, 2] =
  1.9988    -2.7311     -2.85731     3.38059
 -5.63312    2.61159     3.5489      7.22906
  1.58536    0.74342    -0.0612845  -5.44578
  0.957018  -0.0174554   0.838485    0.054773
  1.81001   -1.62433    -0.753998    0.165946
  2.69391   -0.0213057  -1.24054    -6.89847
  3.61053   -2.85339    -1.76307    -1.98227
  4.4069    -0.590834    0.724681    0.698118
 -5.60072    1.33233     1.42462     4.45287
 -2.31928   -0.103913    1.75607     7.84296

julia> using Test

julia> @inferred f(M, V; dim=2)
ERROR: return type Array{Float64,3} does not match inferred return type Any
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] top-level scope at REPL[57]:1

The text was updated successfully, but these errors were encountered:

mcabbott · 2020-06-08T18:16:43Z

If you comment out the last line of f, then its return type is EinCode{_A,_B} where _B where _A -- so I don't know how much hope there is of the final type being stable.

I think the work here is ultimately done by TensorOperations, which keeps dimensions and strides as values not types. So this is stable:

julia> function f4(M, V; dim)
           IA = (-1,0)
           IB = ntuple(d -> d==dim ? 0 : d, ndims(V))
           # IC = (-1, filter(!=(dim), ntuple(+, ndims(V)))...)
           IC = ntuple(d -> d==dim ? -1 : d, ndims(V))
           TensorOperations.tensorcontract(M, IA, V, IB, IC)
       end
f4 (generic function with 1 method)

julia> f4(M, V; dim=2) ≈ f(M, V, dim=2)
true

julia> @code_warntype  f4(M, V; dim=2)
...
Body::Array{Float64,3}

FuZhiyu · 2024-07-05T17:34:29Z

I'm surprised to find out that even when the dimensions are known, it still returns unstable results:

a, b = randn(2, 2), randn(2, 2)
function einproduct(a, b)
    # c = ein"ij,jk -> ik"(a,b)
    @ein c[i,k] := a[i,j] * b[j,k]
    return c
end
Main.@code_warntype einproduct(a, b)

It returns Any. Why would this be?

GiggleLiu · 2024-07-05T23:37:56Z

Thank for the issue. Type stability is completely out of consideration in OMEinsum.
OMEinsum often handles tensors of rank >20, there are exploding many possible types as the output, so reducing the compilation time has a higher priority.

High order tensors appears in many applications:

quantum circuit simulation (https://github.com/nzy1997/TensorQEC.jl)
probabilistic inference (https://github.com/TensorBFS/TensorInference.jl)
combinatorial optimization (https://github.com/QuEraComputing/GenericTensorNetworks.jl)

qiyang-ustc · 2024-12-16T17:21:17Z

Will this instability decrease the speed of the function when be processed?
I found in some OMEinsum will be slow for....-> 100000 times!.

function _FL2(T, L)
    L_reshaped = reshape(L, (size(T,1), size(T,1), :))
    result = ein"(abx,aim),bin->mnx"(L_reshaped, conj(T), T) :: Array{eltype(T),3}
    return reshape(result, size(L))
end

julia> size(L),size(T)
((256, 256), (256, 2, 256))

Performance:

julia> @benchmark ein"(abx,aim),bin->mnx"(L_reshaped, conj(T), T)
BenchmarkTools.Trial: 1446 samples with 1 evaluation.
 Range (min … max):  1.403 ms … 204.071 ms  ┊ GC (min … max):  0.00% …  6.36%
 Time  (median):     2.242 ms               ┊ GC (median):     0.00%
 Time  (mean ± σ):   3.443 ms ±   6.709 ms  ┊ GC (mean ± σ):  27.07% ± 25.08%

  ▆█▆▆▆▄▄▁▁
  █████████▇▆█▇██▇██▇▇█▇▇▇▇██▆▇▆▆▆▅▇▆▁▆▄▅▅▅▁▅▅▄▁▄▄▁▁▁▄▁▄▅▄▁▁▄ █
  1.4 ms       Histogram: log(frequency) by time      17.1 ms <

 Memory estimate: 3.51 MiB, allocs estimate: 317.

julia> @benchmark _FL2(T, L)
BenchmarkTools.Trial: 1 sample with 1 evaluation.
 Single result which took 16.662 s (0.00% GC) to evaluate,
 with a memory estimate of 513.52 KiB, over 30 allocations.

Meanwhile, if I use TensorOperations:

function _FL2(T, L)
    L_reshaped = reshape(L, (size(T,1), size(T,1), :))
    @tensor result[m,n,x] := L_reshaped[a,b,x] * T[a,i,m] * T[b,i,n]
    return reshape(result, size(L))
end

the performance get correct:

@benchmark _FL2(T, L)
BenchmarkTools.Trial: 1796 samples with 1 evaluation.
 Range (min … max):  1.086 ms … 205.694 ms  ┊ GC (min … max):  0.00% … 31.31%
 Time  (median):     1.769 ms               ┊ GC (median):     0.00%
 Time  (mean ± σ):   2.772 ms ±   5.724 ms  ┊ GC (mean ± σ):  28.95% ± 23.49%

  ▇█▇▇▅▂▂▁                                                    ▁
  █████████▆▆▅▇▅▇▆▆▇▆▇▇▇▇▇▇▆▇▇▆▆▆▅▅▆█▅▆▅▇▅▆▄▅▅▁▁▅▄▄▅▄▁▁▄▄▁▄▅▄ █
  1.09 ms      Histogram: log(frequency) by time      16.2 ms <

 Memory estimate: 2.50 MiB, allocs estimate: 11.

GiggleLiu · 2024-12-16T22:49:51Z

I do not think the type instability matters here. Maybe check your Julia version? @qiyang-ustc

julia> @benchmark _FL2(T, L)
BenchmarkTools.Trial: 842 samples with 1 evaluation.
 Range (min … max):  4.439 ms … 71.841 ms  ┊ GC (min … max): 0.00% … 2.75%
 Time  (median):     5.041 ms              ┊ GC (median):    4.05%
 Time  (mean ± σ):   5.925 ms ±  4.291 ms  ┊ GC (mean ± σ):  7.74% ± 6.34%

  ▄█▇▅▂▂▂
  ██████████▆█▁▇▆▆▄▅▄▅▅▅▄▅▅▄▄▅▄▁▅▁▁▅▄▁▁▄▁▁▄▁▁▁▁▁▄▁▁▁▄▁▁▄▄▁▁▄ ▇
  4.44 ms      Histogram: log(frequency) by time     20.8 ms <

 Memory estimate: 9.01 MiB, allocs estimate: 323.

qiyang-ustc · 2024-12-16T23:14:58Z

Interesting, my current version (macOS).

(@v1.11) pkg> st
Status `~/.julia/environments/v1.11/Project.toml`
  [6e4b80f9] BenchmarkTools v1.5.0
  [42fd0dbc] IterativeSolvers v0.9.4
  [ebe7aa44] OMEinsum v0.8.4
  [5fb14364] OhMyREPL v0.5.28
  [295af30f] Revise v3.6.4
  [6aa20fa7] TensorOperations v5.1.3

Let me try to figure out what happened here

qiyang-ustc · 2024-12-16T23:50:37Z

I think it is more interesting, and Indeed I make some mistakes, I thought for such simple problem the order specification is not so important.

julia> function _FL2(T, L)
           L_reshaped = reshape(L, (size(T,1), size(T,1), :))
           result = ein"abx,(aim,bin)->mnx"(L_reshaped, conj(T), T) :: Array{eltype(T),3}
           return reshape(result, size(L))
       end^C

julia> @benchmark _FL2(T, C * C)
BenchmarkTools.Trial: 1547 samples with 1 evaluation.
 Range (min … max):  1.546 ms … 131.868 ms  ┊ GC (min … max):  0.00% …  0.00%
 Time  (median):     2.051 ms               ┊ GC (median):     0.00%
 Time  (mean ± σ):   3.225 ms ±   4.121 ms  ┊ GC (mean ± σ):  23.83% ± 24.31%

  ▂▆█▃▃▃▂▂▂▂▁▁▂▂▂▂▂▁▂
  ██████████████████████▇▆█▆▆▅▅▇▄▆▄▄▆▆▅▆▄▅▄▅▅▅▅▄▄▄▄▁▁▁▁▄▄▄▄▁▄ █
  1.55 ms      Histogram: log(frequency) by time      12.3 ms <

 Memory estimate: 4.01 MiB, allocs estimate: 323.

julia> function _FL2(T, L)
           L_reshaped = reshape(L, (size(T,1), size(T,1), :))
           result = ein"(abx,aim),bin->mnx"(L_reshaped, conj(T), T) :: Array{eltype(T),3}
           return reshape(result, size(L))
       end
_FL2 (generic function with 1 method)

julia> @benchmark _FL2(T, C * C)
BenchmarkTools.Trial: 1636 samples with 1 evaluation.
 Range (min … max):  1.562 ms … 19.747 ms  ┊ GC (min … max):  0.00% … 19.90%
 Time  (median):     2.054 ms              ┊ GC (median):     0.00%
 Time  (mean ± σ):   3.048 ms ±  1.968 ms  ┊ GC (mean ± σ):  27.26% ± 25.50%

   ▅█▅▂▂▂▂▂▂▂▁   ▁▁▁▁▁ ▁▁
  ████████████▇███████████▇█▇▇▇▇▆▇▇▆▄▆▄▇▆▅▄▅▄▄▄▄▄▄▄▁▄▅▄▅▅▄▁▄ █
  1.56 ms      Histogram: log(frequency) by time     10.8 ms <

 Memory estimate: 4.01 MiB, allocs estimate: 323.

julia> function _FL2(T, L)
           L_reshaped = reshape(L, (size(T,1), size(T,1), :))
           result = ein"abx,aim,bin->mnx"(L_reshaped, conj(T), T) :: Array{eltype(T),3}
           return reshape(result, size(L))
       end
_FL2 (generic function with 1 method)

julia> @benchmark _FL2(T, C * C)
BenchmarkTools.Trial: 1 sample with 1 evaluation.
 Single result which took 16.971 s (0.00% GC) to evaluate,
 with a memory estimate of 1.00 MiB, over 32 allocations.

Thus it seems it related to the order specification of ein_string.

I also notice when check the generated code with @code_native,

the faster one call something like:
OMEinsum/FCR12/src/einsequence.jl:257 within NestedEinsum`

But the slower one call
OMEinsum/FCR12/src/interfaces.jl:54 within StaticEinCode`

Is this helpful to diagnosis the problem?

qiyang-ustc · 2024-12-17T00:02:44Z

In order to present this more precisely. Please check the following MWE:
Notice, in the last comment, (abx,aim),bin->mnx take nearly the same time of abx,(aim,bin)->mnx, it is also weird in my mind.

julia> using BenchmarkTools, OMEinsum

julia> @benchmark ein"abx,aim,bin->mnx"(rand(64,64,1), rand(64,2,64), rand(64,2,64))
BenchmarkTools.Trial: 92 samples with 1 evaluation.
 Range (min … max):  48.270 ms … 395.540 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     49.050 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   54.857 ms ±  36.580 ms  ┊ GC (mean ± σ):  0.00% ± 0.00%

  █▅▁
  ███▇▅▅▅▁▁▁▁▅▁▅▁▅▅▁▁▅▁▁▁▁▁▁▅▁▁▁▅▁▁▁▁▁▁▁▁▁▁▅▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▅ ▁
  48.3 ms       Histogram: log(frequency) by time      95.1 ms <

 Memory estimate: 193.62 KiB, allocs estimate: 36.

julia> @benchmark ein"abx,(aim,bin)->mnx"(rand(64,64,1), rand(64,2,64), rand(64,2,64))
BenchmarkTools.Trial: 12 samples with 1 evaluation.
 Range (min … max):  331.549 ms … 577.723 ms  ┊ GC (min … max):  2.51% … 33.04%
 Time  (median):     446.449 ms               ┊ GC (median):    10.68%
 Time  (mean ± σ):   447.993 ms ±  87.542 ms  ┊ GC (mean ± σ):  20.32% ± 15.10%

  ██    █     █  █       █         █     █       █   █ █      █
  ██▁▁▁▁█▁▁▁▁▁█▁▁█▁▁▁▁▁▁▁█▁▁▁▁▁▁▁▁▁█▁▁▁▁▁█▁▁▁▁▁▁▁█▁▁▁█▁█▁▁▁▁▁▁█ ▁
  332 ms           Histogram: frequency by time          578 ms <

 Memory estimate: 384.39 MiB, allocs estimate: 489.

julia> @benchmark ein"(abx,aim),bin->mnx"(rand(64,64,1), rand(64,2,64), rand(64,2,64))
BenchmarkTools.Trial: 10000 samples with 1 evaluation.
 Range (min … max):   99.975 μs …  10.920 ms  ┊ GC (min … max):  0.00% … 98.15%
 Time  (median):     122.029 μs               ┊ GC (median):     0.00%
 Time  (mean ± σ):   169.924 μs ± 348.072 μs  ┊ GC (mean ± σ):  21.70% ± 12.25%

  █▆▄▃▃▂▁                                                       ▁
  ███████▇▆▅▄▄▁▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃▄▅▆▆▄▄▅▅▅▅▅▄▄▅▄▅▃▅▄▅ █
  100 μs        Histogram: log(frequency) by time       1.63 ms <

 Memory estimate: 397.56 KiB, allocs estimate: 325.

ArrogantGao · 2024-12-17T01:08:35Z

I think the results here make sense:

julia> using BenchmarkTools, OMEinsum

julia> ein_1 = ein"abx,aim,bin->mnx"
abx, aim, bin -> mnx

julia> ein_2 = ein"abx,(aim,bin)->mnx"
abx, mnab -> mnx
├─ abx
└─ aim, bin -> mnab
   ├─ aim
   └─ bin


julia> ein_3 = ein"(abx,aim),bin->mnx"
xmbi, bin -> mnx
├─ abx, aim -> xmbi
│  ├─ abx
│  └─ aim
└─ bin


julia> A, B, C = (rand(64,64,1), rand(64,2,64), rand(64,2,64));

julia> @benchmark $(ein_1)($A, $B, $C)
BenchmarkTools.Trial: 174 samples with 1 evaluation.
 Range (min … max):  28.648 ms …  30.992 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median):     28.708 ms               ┊ GC (median):    0.00%
 Time  (mean ± σ):   28.735 ms ± 189.006 μs  ┊ GC (mean ± σ):  0.00% ± 0.00%

    ▄▆▅▅▃█▂▃  ▁
  ▄██████████▇█▆▇▅▁▄▄▅▃▃▁▃▁▁▁▃▁▁▃▁▁▁▁▁▁▁▁▁▁▁▁▃▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▃ ▃
  28.6 ms         Histogram: frequency by time         29.1 ms <

 Memory estimate: 33.39 KiB, allocs estimate: 27.

julia> @benchmark $(ein_2)($A, $B, $C)
BenchmarkTools.Trial: 34 samples with 1 evaluation.
 Range (min … max):  112.747 ms … 202.833 ms  ┊ GC (min … max):  1.40% … 44.79%
 Time  (median):     122.213 ms               ┊ GC (median):     8.70%
 Time  (mean ± σ):   148.203 ms ±  40.752 ms  ┊ GC (mean ± σ):  24.70% ± 19.76%

  ▆█                                                         ▃▁
  ██▄▄▁▁▁▁▄▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▄▆▁▁▁▁▄██ ▁
  113 ms           Histogram: frequency by time          203 ms <

 Memory estimate: 384.24 MiB, allocs estimate: 480.

julia> @benchmark $(ein_3)($A, $B, $C)
BenchmarkTools.Trial: 10000 samples with 1 evaluation.
 Range (min … max):   96.167 μs …   6.366 ms  ┊ GC (min … max): 0.00% … 97.64%
 Time  (median):     105.083 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):   114.678 μs ± 108.491 μs  ┊ GC (mean ± σ):  5.63% ±  7.94%

  ██▇▅▂▁                                                        ▂
  █████████▇█▇▇▇▅▄▅▄▁▃▃▄▄▄▄▄▁▄▄▁▃▃▁▃▃▁▁▃▁▁▃▁▁▁▁▁▁▁▁▁▃▁▁▁▁▁▁▁▃▁▄ █
  96.2 μs       Histogram: log(frequency) by time        493 μs <

 Memory estimate: 237.33 KiB, allocs estimate: 316.

julia> size_dict = Dict(['a' => 64, 'b' => 64, 'x' => 1, 'i' => 2, 'm' => 64, 'n' =>64]);

julia> contraction_complexity(ein_1, size_dict)
Time complexity: 2^25.0
Space complexity: 2^12.0
Read-write complexity: 2^14.584962500721156

julia> contraction_complexity(ein_2, size_dict)
Time complexity: 2^25.584962500721158
Space complexity: 2^24.0
Read-write complexity: 2^25.00105627463478

julia> contraction_complexity(ein_3, size_dict)
Time complexity: 2^20.0
Space complexity: 2^13.0
Read-write complexity: 2^15.321928094887362

It is clear that the second contraction order has larger space and time complexity.

ArrogantGao · 2024-12-17T01:11:51Z

I think it is more interesting, and Indeed I make some mistakes, I thought for such simple problem the order specification is not so important.

julia> function _FL2(T, L)
           L_reshaped = reshape(L, (size(T,1), size(T,1), :))
           result = ein"abx,(aim,bin)->mnx"(L_reshaped, conj(T), T) :: Array{eltype(T),3}
           return reshape(result, size(L))
       end^C

julia> @benchmark _FL2(T, C * C)
BenchmarkTools.Trial: 1547 samples with 1 evaluation.
 Range (min … max):  1.546 ms … 131.868 ms  ┊ GC (min … max):  0.00% …  0.00%
 Time  (median):     2.051 ms               ┊ GC (median):     0.00%
 Time  (mean ± σ):   3.225 ms ±   4.121 ms  ┊ GC (mean ± σ):  23.83% ± 24.31%

  ▂▆█▃▃▃▂▂▂▂▁▁▂▂▂▂▂▁▂
  ██████████████████████▇▆█▆▆▅▅▇▄▆▄▄▆▆▅▆▄▅▄▅▅▅▅▄▄▄▄▁▁▁▁▄▄▄▄▁▄ █
  1.55 ms      Histogram: log(frequency) by time      12.3 ms <

 Memory estimate: 4.01 MiB, allocs estimate: 323.

julia> function _FL2(T, L)
           L_reshaped = reshape(L, (size(T,1), size(T,1), :))
           result = ein"(abx,aim),bin->mnx"(L_reshaped, conj(T), T) :: Array{eltype(T),3}
           return reshape(result, size(L))
       end
_FL2 (generic function with 1 method)

julia> @benchmark _FL2(T, C * C)
BenchmarkTools.Trial: 1636 samples with 1 evaluation.
 Range (min … max):  1.562 ms … 19.747 ms  ┊ GC (min … max):  0.00% … 19.90%
 Time  (median):     2.054 ms              ┊ GC (median):     0.00%
 Time  (mean ± σ):   3.048 ms ±  1.968 ms  ┊ GC (mean ± σ):  27.26% ± 25.50%

   ▅█▅▂▂▂▂▂▂▂▁   ▁▁▁▁▁ ▁▁
  ████████████▇███████████▇█▇▇▇▇▆▇▇▆▄▆▄▇▆▅▄▅▄▄▄▄▄▄▄▁▄▅▄▅▅▄▁▄ █
  1.56 ms      Histogram: log(frequency) by time     10.8 ms <

 Memory estimate: 4.01 MiB, allocs estimate: 323.

julia> function _FL2(T, L)
           L_reshaped = reshape(L, (size(T,1), size(T,1), :))
           result = ein"abx,aim,bin->mnx"(L_reshaped, conj(T), T) :: Array{eltype(T),3}
           return reshape(result, size(L))
       end
_FL2 (generic function with 1 method)

julia> @benchmark _FL2(T, C * C)
BenchmarkTools.Trial: 1 sample with 1 evaluation.
 Single result which took 16.971 s (0.00% GC) to evaluate,
 with a memory estimate of 1.00 MiB, over 32 allocations.

Thus it seems it related to the order specification of ein_string.

I also notice when check the generated code with @code_native,

the faster one call something like: OMEinsum/FCR12/src/einsequence.jl:257 within NestedEinsum`

But the slower one call OMEinsum/FCR12/src/interfaces.jl:54 within StaticEinCode`

Is this helpful to diagnosis the problem?

Here the reason is not the type instability, the difference in speed is because of the contraction order. ein"abx,aim,bin->mnx" this eincode is not optimized at all, which means it will be loop all indices directly, of course it is very slow. With ein"(abx,aim),bin->mnx", a contraction order is determined, thus it gives a NestedEinsum, which is a contraction tree, so it is faster.

If you want to get the contraction order automatically, please try optein.

julia> @benchmark $(optein"abx,aim,bin->mnx")($(A), $(B), $(C))
BenchmarkTools.Trial: 10000 samples with 1 evaluation.
 Range (min … max):  115.000 μs …   6.201 ms  ┊ GC (min … max): 0.00% … 97.14%
 Time  (median):     127.875 μs               ┊ GC (median):    0.00%
 Time  (mean ± σ):   141.044 μs ± 135.872 μs  ┊ GC (mean ± σ):  7.40% ±  9.37%

  ▆█▇▅▃▂▁▁                                                      ▂
  ███████████▇▇▆▅▅▄▄▄▃▃▃▁▁▃▃▃▄▃▁▃▄▁▁▁▁▃▃▁▁▁▁▁▁▁▁▁▁▃▁▁▁▁▁▁▁▁▃▄▆█ █
  115 μs        Histogram: log(frequency) by time        558 μs <

 Memory estimate: 334.91 KiB, allocs estimate: 352.

julia> optein"abx,aim,bin->mnx"
bxim, bin -> mnx
├─ abx, aim -> bxim
│  ├─ abx
│  └─ aim
└─ bin

qiyang-ustc · 2024-12-17T08:51:55Z

Thanks! It is very clear!

GiggleLiu added the enhancement New feature or request label Sep 23, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Getting type stability with EinCode #97

Getting type stability with EinCode #97

sethaxen commented May 4, 2020

mcabbott commented Jun 8, 2020 •

edited

Loading

FuZhiyu commented Jul 5, 2024

GiggleLiu commented Jul 5, 2024

qiyang-ustc commented Dec 16, 2024 •

edited

Loading

GiggleLiu commented Dec 16, 2024 •

edited

Loading

qiyang-ustc commented Dec 16, 2024 •

edited

Loading

qiyang-ustc commented Dec 16, 2024

qiyang-ustc commented Dec 17, 2024

ArrogantGao commented Dec 17, 2024

ArrogantGao commented Dec 17, 2024 •

edited

Loading

qiyang-ustc commented Dec 17, 2024

Getting type stability with EinCode #97

Getting type stability with EinCode #97

Comments

sethaxen commented May 4, 2020

mcabbott commented Jun 8, 2020 • edited Loading

FuZhiyu commented Jul 5, 2024

GiggleLiu commented Jul 5, 2024

qiyang-ustc commented Dec 16, 2024 • edited Loading

GiggleLiu commented Dec 16, 2024 • edited Loading

qiyang-ustc commented Dec 16, 2024 • edited Loading

qiyang-ustc commented Dec 16, 2024

qiyang-ustc commented Dec 17, 2024

ArrogantGao commented Dec 17, 2024

ArrogantGao commented Dec 17, 2024 • edited Loading

qiyang-ustc commented Dec 17, 2024

mcabbott commented Jun 8, 2020 •

edited

Loading

qiyang-ustc commented Dec 16, 2024 •

edited

Loading

GiggleLiu commented Dec 16, 2024 •

edited

Loading

qiyang-ustc commented Dec 16, 2024 •

edited

Loading

ArrogantGao commented Dec 17, 2024 •

edited

Loading