Hi! I'm a fan of PyCuTe. I just watched this lecture at GPU MODE presented last Friday: https://www.youtube.com/watch?v=_sKjPj3Zl6I, and I think I understand CuTe significantly better. Thank you, it was a great lecture.
I work on an ND Array database experiment called Xarray-SQL: https://github.com/xqlsystems/xarray-sql. In this data model, we represent any ND array as a 2D table, where the dimensions of the array are "primary key" columns, the voxel positions are other columns, and one voxel is one row. This colab notebook provides a better explainer of this programming model than I can describe here: https://colab.research.google.com/drive/1f32X7pCTXCERi7eZDyCVEKXcRSvP6dX6?usp=sharing.
One example I enjoyed in particular from the GPU MODE lecture was the EinFold demo in CuTe -- https://github.com/NVlabs/CuTe/blob/main/examples/einfold_test.py
This resonates with my "XQL" experiments because we've found that our data model for ND arrays lets us describe einsum notation in SQL: https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/einsteinsum.pdf, or see this extreme example: https://github.com/xqlsystems/xarray-sql/blob/claude/xarray-sql-mnist-demo/benchmarks/nn.py.
I had a conceptual question: Could we unite the sort of relational algebra found in SQL and CuTe's tensor algebra? It seems like CuTe's hierarchical stride definition acts as a sort of tree-based DSL for indexing numbers in array memory layouts. This seems to have a parallel to how database indexes work, which are often B-tree based indexes on primary key columns.
Given this, if we had a logical view of data as presented in the relational model, could we automatically infer the input hierarchical layout? The goal would be to make SQL-based matmuls as efficient as array-native ops. Specifically, it seems like we could parse metadata from the arrays, infer the CuTe layout, and use it to create an efficient "EinFold Hash Join" implementation. Maybe the query system could make a good enough guess for the memory layout, or it could be better tuned via a choice of (primary key) indexes. Forgive me if I'm conflating concepts here.
This approach may be going in the opposite direction of the goals for PyCuTe in the first place – the lecture favors metaprogramming instead of compiling, claiming that "compiler knobs and hits are not a programming model". I think I agree with this, but counter that knobs may be right for a data model.
Hi! I'm a fan of PyCuTe. I just watched this lecture at GPU MODE presented last Friday: https://www.youtube.com/watch?v=_sKjPj3Zl6I, and I think I understand CuTe significantly better. Thank you, it was a great lecture.
I work on an ND Array database experiment called Xarray-SQL: https://github.com/xqlsystems/xarray-sql. In this data model, we represent any ND array as a 2D table, where the dimensions of the array are "primary key" columns, the voxel positions are other columns, and one voxel is one row. This colab notebook provides a better explainer of this programming model than I can describe here: https://colab.research.google.com/drive/1f32X7pCTXCERi7eZDyCVEKXcRSvP6dX6?usp=sharing.
One example I enjoyed in particular from the GPU MODE lecture was the EinFold demo in CuTe -- https://github.com/NVlabs/CuTe/blob/main/examples/einfold_test.py
This resonates with my "XQL" experiments because we've found that our data model for ND arrays lets us describe einsum notation in SQL: https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/einsteinsum.pdf, or see this extreme example: https://github.com/xqlsystems/xarray-sql/blob/claude/xarray-sql-mnist-demo/benchmarks/nn.py.
I had a conceptual question: Could we unite the sort of relational algebra found in SQL and CuTe's tensor algebra? It seems like CuTe's hierarchical stride definition acts as a sort of tree-based DSL for indexing numbers in array memory layouts. This seems to have a parallel to how database indexes work, which are often B-tree based indexes on primary key columns.
Given this, if we had a logical view of data as presented in the relational model, could we automatically infer the input hierarchical layout? The goal would be to make SQL-based matmuls as efficient as array-native ops. Specifically, it seems like we could parse metadata from the arrays, infer the CuTe layout, and use it to create an efficient "EinFold Hash Join" implementation. Maybe the query system could make a good enough guess for the memory layout, or it could be better tuned via a choice of (primary key) indexes. Forgive me if I'm conflating concepts here.
This approach may be going in the opposite direction of the goals for PyCuTe in the first place – the lecture favors metaprogramming instead of compiling, claiming that "compiler knobs and hits are not a programming model". I think I agree with this, but counter that knobs may be right for a data model.