upvote
Isn't an array of arrays by definition the sequential implementation?

Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be.

They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within the original array.

Even in c++ could you not just define some int [1000][1000]foo? I've never really used C++ but my C knowledge assumption is that is 1000000 continuous elements.

reply
The C++ way to do it currently would be:

    std::array<std::array<T, N>, M> data;
Which is contiguous

    int data[M][N]; 
also works fine and is contiguous in C++

Edit:

For the stack at least. On the heap, you'd need to use a single std::vector<int> and do the indices manually, or use mdspan

reply
I does not work fine in C++ when N and M are not compile-time constants, which is basically always the case in any interesting numerical algorithm. Also not in Rust.

It works fine in C though, or FORTRAN, or Ada, or ALGOL 60, ...

reply
Which is why std::mdspan exists, and std::linalg.

NVidia has pivoted to design CUDA hardware with focus on C++ back in , and seems to be doing quite well for them.

CppCon 2017: "Designing (New) C++ Hardware”

https://www.youtube.com/watch?v=86seb-iZCnI

They were also the ones sponsoring the ISO work on mdspan, while HPC research labs are pushing for linalg on top.

I would rather be using Ada today, but that isn't how the world moves.

reply
> Even in c++ could you not just define some int [1000][1000]foo?

If it fits on the stack, yes.

Typical code using MD-arrays is scientific code, and the data they manipulate generally do not fit there.

reply
Would the compiler not allocate the memory contiguously on the heap in that case then? Seems like a reasonable thing to do.
reply
I see. That makes sense.
reply