COO matrices support
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- julia
- Área
- data, machine-learning
Línea de trabajo
Comienza auditando las capas y operaciones del grafo que deben funcionar con almacenamiento MatrixCOO subyacente y, a continuación, compara CPU SparseMatricesCOO.jl con CUDA CUSPARSE.CuSparseMatrixCOO y sus requisitos de ordenación. Se considera terminado cuando las capas y operaciones compatibles funcionan con almacenamiento COO y el proyecto ha decidido si los datos COO deben ordenarse.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Currently, the default storage type for our graphs is the COO format, which for us is a tuple of 3 vectors, (source, target, edge_weight).
This format is convenient for gather/scatter operations. On the other hand, as we move to using more and more sparse-dense multiplication for efficiency, it would be nice to construct without allocations a COO Sparse Matrix type out of the tuple to perform algebraic allocations. AFAIK, this is also what PyG does.
On CPU, this should be doable using https://github.com/JuliaSmoothOptimizers/SparseMatricesCOO.jl
On CUDA, we have CUSPARSE.CuSparseMatrixCOO. Unfortunately, this format requires edge ordering, which we currently don't guarantee.
- additional note: PyG/pytorch coo matrix type doesn't enforce edge ordering. Do they bypass CUSPARSE and provide their own multiplication kernels?
What to do:
- make sure that most layers and operations work we construct a graph with underlying MatrixCOO storage
- decide if we want to require our COO storage to be sorted
- Lenguaje dominante
- Julia
- Estrellas
- 309
- Forks
- 74
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de JuliaGraphs/GraphNeuralNetworks.jl
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
-
Mooncake on CUDA issue trackerAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
JuliaGraphs/GraphNeuralNetworks.jl#702 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
-
Test against Enzyme / Reactant?Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
JuliaGraphs/GraphNeuralNetworks.jl#655 · 7 comentarios ·
Todos los issues de JuliaGraphs/GraphNeuralNetworks.jl
Issues similares
-
Broken links in the docsAbierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
oxfordcontrol/COSMO.jl#211 ·
-
documentation
Dificultad 2/5 Medio día Aptitud para principiantes 65/100
Los mantenedores suelen responder en 6 días
-
Out-of-place JLArray/GPU problem with VectorContinuousCallback scalar-indexes (callback cache built with CPU zeros)Posiblemente ocupada @ChrisRackauckas-Claude la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
SciML/OrdinaryDiffEq.jl#4813 ·
Los mantenedores suelen responder en 1 día
-
ARKODE: callbacks that modify `u` throw MethodError on reinitPosiblemente ocupada @devmotion la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 79/100
SciML/Sundials.jl#575 ·