-
Notifications
You must be signed in to change notification settings - Fork 35
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
Comments
SIMD.jl is a very lightweight package, why not just have FillArrays.jl depend on SIMD.jl? |
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. |
I meant lightweight in terms of it has no dependencies. |
Yes, this is a possible solution. But that's |
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 definegetindex
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
The text was updated successfully, but these errors were encountered: