Warning on sqrt

[xijiang]

WARNING: Method definition sqrt(Static.StaticInt{M}) where {M} in module Static at ~/.julia/packages/Static/ykIKz/src/float.jl:100 overwritten in module Octavian at ~/julia/packages/Octavian/dzD2K/src/staticfloats.jl:34.
** incremental compilation may be fatally broken for this module **

• Does this matter?
• How to avoid this?

I am

using LinearAlgebra, Dates, HTTP, DataFrames, Random, Distributions,
    Serialization, Statistics, StatsPlots, JLD2,  Octavian

Also, Fedora 33 with AMD 3900x.

[chriselrod]

Hi, thanks for the issue.

Does this matter?

It could, because they defined them differently.
In Octavian, it returned an Octavian.StaticFloat, while in Static.jl, it returned a Static.StaticFloat64.
Octavian shouldn't have commited type piracy (defining Base.sqrt on ArrayInterface.StaticInt in the first place).
ArrayInterface.StaticInt was eventually factored out of ArrayInterface and into its own package, Static, which then defined the square root method (without committing piracy, as it now defines the StaticInt type).

It's fixed by #73, which replaces Octavian.StaticFloat with Static.StaticFloat64.

Also, Fedora 33 with AMD 3900x.

Cool. Performance should hopefully be pretty good, but I'm curious how it'll perform for large matrices that require L3 cache blocking (e.g., 4000 x 4000).
When multiplying such large matrices C = A * B, it copies chunks of B into blocks that fit inside the L3 cache.

IIRC, the 3900x has 4 separate 16 MiB L3 caches. So I think the best way to handle it if we could do whatever we wanted would be to give each set of 3 cores their own up-to-16 MiB L3-cache block, splitting B and C into 4 pieces that each set of 3 cores works on independently.

But, I don't know how to actually do that, i.e., I can't currently tell which cores the Julia threads are running on, and without JULIA_EXCLUSIVE=1, the OS can move them around anyway.
Which means the above approach probably wouldn't work. I can't randomly assign sets of 3 cores to share the same L3-cache-block of B, because odds are those three threads won't actually share the same L3 cache. We could end up where the three cores actually sharing the same L3 cache were assigned 3 different L3-cache-blocks, i.e.up to 48 MiB, and thus we'd constantly be spilling cache memory and cripple performance.

So for now, I'm taking the fairly conservative approach of just using a single up-to-16 MiB block. 16 MiB is comparable to Intel's offerings, so it shouldn't be so small to really cripple the CPUs, and it saves us from accidentally falling off a performance cliff.

But maybe a better compromise is possible.