Comments (7)
FWIW, the SYCL spec landed on using size_t
for all index types, and int
for dimensions: https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:item.class
The fact that the gpu blas APIs typically use int indexes makes things fun here. Bottom line, we don't want silent failures if overflow happens, even in release builds.
from gtensor.
I guess I'll agree that while there was some intention behind the different size for multi-d index vs 1-d index, it's really not possible to not do this in a way that doesn't cause potential subtle overflow bugs.
So probably what we should do is to use <class>::size_type
consistently everywhere, get rid of int
, with the former being defaulted to gt::size_type
which in itself should probably default to std::size_t
(but one could argue about uint
).
Maybe actually ssize_t
would be better, since there are times where negative indices may make some sense. I think this need some more thinking/investigation...
from gtensor.
yes this is subtle. As a start, I am using size_t for index calculations inside kernels and for SYCL and whenever doing interations over container.size() or calc_size(shape). This involves no change to the external interface.
from gtensor.
There are potentially 3 types at play here:
- size_type - for addressing in to memory
- index_type, backend - what the underlying GPU lib uses, e.g. for dim3 in CUDA (uint32_t)
- index_type, gt high level - currently int, as part of shape_type, not convinced this should be different from (2)
I'm inclined to make gt::index_type a standard that should be used e.g. for GT_LAMBDA (gt::index_type i)
, and then we have knobs to change this and aren't stuck with a bunch of code with hard coded ints. I am also inclined to change the default to uint32_t on HIP/CUDA and to size_t for SYCL, to match the backend.
from gtensor.
Having both size_type and index_type is a bit confusing here. One is 1d, the other is N-d, but of course 1d is just a special case of N-d, so it's wierd.
from gtensor.
Having both size_type and index_type is a bit confusing here. One is 1d, the other is N-d, but of course 1d is just a special case of N-d, so it's wierd.
Right, I think I just wrote something along those same lines in another thread.
from gtensor.
I think an interesting experiment here, would be to change all indexes to size_type and change default size_type to uint32_t, and see if (a) tests, benchmarks etc pass, (b) gene passes tests, and (c) performance of benchmarks and/or GENE improves significantly. If the answer is yet, then I think it's worth doing. Other than some reverse iteration direction loops in bandsolver which can be rewritten, I don't see negative indexes being used anywhere. It would also be interesting to see if using uint32_t consistently works around the ROCm compiler bug with -O2.
from gtensor.
Related Issues (20)
- improve C API for streams
- cgtblas: sycl backend does not handle nullptr case HOT 3
- sycl: use complex extension
- fortran: add cmake option for complex/real sizes
- fortran: rocm does not find ISO_Fortran_binding.h header HOT 2
- clib namespace is confusing HOT 1
- device debug print helper HOT 1
- more CI checks: ASan, UBSan, clang-tidy HOT 2
- missing return statement warning
- cmake: use official ROCm and oneAPI integration
- ci: update clang-format version HOT 8
- spack package, e4s integration, release
- alternate fft backends
- micro benchmarking assign expressions on all platforms
- improve caching allocator
- const stream objects HOT 2
- half precision support
- half precision axpy HOT 15
- CUDA host/device warnings (shape ctor not device) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gtensor.