ArrayInterfaceCore

[ParadaCarleton]

As mentioned here, ArrayInterface has become a huge dependency to take on. It might make sense to separate out some ArrayInterfaceCore that can be loaded faster and contains only basic functionality.

[chriselrod]

We could take one or both of the following approaches:

1. Don't even include functionality. Just stubs of the methods other libraries would need/want to overload. ArrayInterface would import these, so it won't be a breaking change (i.e., extending ArrayInterface.parent_type would be extending ArrayInterfaceCore.parent_type).
2. Add basic functionality so that someone wanting to use ArrayInterface can actually use ArrayInterfaceCore without taking on as much weight.

Taking both would mean creating two libraries: one of the stubs, and then one of the basic functionality.

[grahamas]

@chriselrod your approaches sounds like (for shorthand):

1. AbstractArrayInterface
2. and ArrayInterfaceCore

I think there's a more functional divide. It seems to me like there are two kinds of users:

1. Someone purely trying to develop their own Array type (usually the ideal use-case for AbstractX packages). However, even for this person the AbstractArrayInterface wouldn't be sufficient in many cases. The existing package provides a lot of useful low-level stuff (device etc) that a more advanced developer might want to use without the cost of importing the various high-level dependencies of this package. This is the person who probably wants something like ArrayInterfaceCore, for some definition of "basic functionality," and so is the subject of this issue.
2. Someone trying to use one (or more) of the Array types defined in this package. This person wants more than would be included in my understanding of "basic functionality" (maybe e.g. the FieldArray) but still a lot less than the full package (e.g. does not want CUDA, CuArray etc.). This person suggest splitting up ArrayInterface into sub-packages, all depending on ArrayInterfaceCore, each contributing one set of Array implementations. This person isn't really relevant to this issue, but sometimes this person is me, so I think it'd be cool. But it should be clear/decided that "basic functionality" won't include this person. Edit: this isn't a concern because of @requires

Basically, that's all to say I don't think AbstractArrayInterface would be all that useful, and I think "basic functionality" can mean a lot of different things to different people. From my perspective, I'd like it to mean that when I subtype AbstractArray, the vast majority of necessary and optional methods have working default implementations. Someone should probably write down what you really want "basic functionality" to mean, though.

Finally, I'm curious how this ties into the long-mentioned merge into base julia.

[chriselrod]

For me, basic functionality are the things required for LoopVectorization to work on a custom array type.
That set of things are what the JuliaSIMD ecosystem uses.

[ChrisRackauckas]

What's the measure here? Load time?

[ParadaCarleton]

What's the measure here? Load time?

I think it should be; anything like an ArrayInterfaceCore should take on the order of a tenth of a second to load, I think. Is there a breakdown of load time by file? What precisely makes ArrayInterface take so long to load?

[ChrisRackauckas]

Looks like it hits that mark?

julia> @time using ArrayInterface
  0.098646 seconds (172.08 k allocations: 9.701 MiB, 40.21% compilation time)

Though it's close 😅 . Likely influenced by the @requires usage which should get upstreamed as much as possible.

[ParadaCarleton]

Looks like it hits that mark?

julia> @time using ArrayInterface
  0.098646 seconds (172.08 k allocations: 9.701 MiB, 40.21% compilation time)

Though it's close sweat_smile . Likely influenced by the @requires usage which should get upstreamed as much as possible.

Are you sure you're in a clean environment, and also that this environment isn't located on a supercomputer?

julia> @time using ArrayInterface
    1.524555 seconds (1.29 M allocations: 71.782 MiB, 1.27% gc time, 94.02% compilation time)

[ChrisRackauckas]

Julia v1.7?

[ParadaCarleton]

Julia v1.7?

... How?!

 0.156010 seconds (147.17 k allocations: 8.357 MiB, 58.06% compilation time)

[Tokazama]

The problem with splitting things up is that the point is that everyone uses the same interface. I know that there's a lot of code related to the indexing pipeline and ArrayIndex, but not everyone is using it and that seems to cause some friction. I'm completely open to improving that code but if people just don't want to use it we should just get rid of it and hope to have related problems solved in Julio 2.0.

[ParadaCarleton]

The problem with splitting things up is that the point is that everyone uses the same interface. I know that there's a lot of code related to the indexing pipeline and ArrayIndex, but not everyone is using it and that seems to cause some friction. I'm completely open to improving that code but if people just don't want to use it we should just get rid of it and hope to have related problems solved in Julio 2.0.

It might be worth splitting that code into a different package, both to reduce compile times (which are a bit on the iffy side, although definitely not a huge deal after 1.7) and to improve the code's visibility -- if the indexing features mostly aren't being used, that might be because people aren't aware of them.

[Tokazama]

if the indexing features mostly aren't being used, that might be because people aren't aware of them.

I think the appropriate solution for this is documentation (which the lack of is admittedly my fault).
My personal opinion is that there is a need for all of this code in one package (perhaps a cleaner and more concise version than what currently exists), because the core array interface includes indexing and there are necessary improvements on what is currently in Base.
We could certainly take out certain components that are not array specific (like we did with Static.jl), but anything else would needlessly divide a code base that should be completely unified.

Nonetheless, I've drafted a PR that gets rid of the indexing code so people can begin to look at how this affects things.
I'm ultimately open to whatever people think is best moving forward because no matter how good this package may seem to any one person, its utility is entirely dependent on community buy in.

[ParadaCarleton]

if the indexing features mostly aren't being used, that might be because people aren't aware of them.

I think the appropriate solution for this is documentation (which the lack of is admittedly my fault). My personal opinion is that there is a need for all of this code in one package (perhaps a cleaner and more concise version than what currently exists), because the core array interface includes indexing and there are necessary improvements on what is currently in Base. We could certainly take out certain components that are not array specific (like we did with Static.jl), but anything else would needlessly divide a code base that should be completely unified.

Nonetheless, I've drafted a PR that gets rid of the indexing code so people can begin to look at how this affects things. I'm ultimately open to whatever people think is best moving forward because no matter how good this package may seem to any one person, its utility is entirely dependent on community buy in.

I’d definitely agree that’s not sufficient reason to separate this code out — it’s more of an incidental benefit you might get. The main hope would be splitting the package would reduce the size of the dependency without causing many problems.