Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interoperability of indexing-based SIMD interface #45

Open
tkf opened this issue Feb 7, 2019 · 4 comments
Open

Interoperability of indexing-based SIMD interface #45

tkf opened this issue Feb 7, 2019 · 4 comments

Comments

@tkf
Copy link
Contributor

tkf commented Feb 7, 2019

In my small sparse array package https://github.com/tkf/SparseXX.jl, I want to use indexing-based SIMD interface with different "non-standard" arrays like the ones from MappedArrays.jl and FillArrays.jl. It may even make sense to support SIMD-indexing Broadcasted object so that it works with LazyArrays.jl. At first, I was rather hoping that I can do it by some duck typing so that array libraries do not need to know about SIMD.jl. However, as pointed out by @timholy and @mbauman in JuliaArrays/MappedArrays.jl#24, it looks we need some code importing both SIMD.jl and the array libraries and define getindex etc. that are aware of those libraries.

The question is who distribute/maintain the code. As I'm the only one using this feature now, I think it's probably better if I create a package that does it (here is the proof-of-concept: https://github.com/tkf/SIMDIndexing.jl). But then it becomes technically a type piracy since I don't "own" those types or functions. So, I thought it's better to get the "permission" of doing the type piracy in a friendly fashion.

Of course, if you want to add the code in SIMD.jl by including the array packages as "soft" dependencies using @require, I will happily create a PR.

cc: @dlfivefifty, as you seems to be maintaining FillArrays.jl

@dlfivefifty
Copy link

SIMD.jl is a very lightweight package, why not just have FillArrays.jl depend on SIMD.jl?

@timholy
Copy link
Contributor

timholy commented Feb 8, 2019

16 exports and almost 2k LOC isn't lightweight compared to some AbstractArray types. For example, PaddedViews is roughly 10% of the size of SIMD.

@dlfivefifty
Copy link

I meant lightweight in terms of it has no dependencies.

@tkf
Copy link
Contributor Author

tkf commented Feb 9, 2019

FillArrays.jl depend on SIMD.jl?

Yes, this is a possible solution. But that's O(N) work for me where N = the number of array package authors because I have to keep convincing them to have SIMD.jl as a dependency or to use Requires.jl. In practice N is probably 2 (= #{@timholy, @dlfivefifty}) but the possibility that N may grow makes me not wanting to go to this direction...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants