4 ms·

Maintenance, probably. Puting data in a structure that mirrors the real thing normally helps when trying to understand it

Pannoniae 3y ago
No, I mean for the JVM.... the interface could remain the same but the pointer indirections could be avoided. I don't see the downsides, that's why I'm asking.
- tralarpa 3y ago
  I guess it was just to simplify the original specification of the JVM (if two dimensional arrays are just arrays of arrays, you don't need special instructions for them). I can also imagine that the original JVM designers did not expect JIT compilers to one day become so good that the performance difference becomes relevant.
  - samus 3y ago
    But there is actually a special bytecode instruction to create multidimensional arrays: MULTIANEWARRAY. My suspicion is that it allows a sufficiently sophisticated JVM to allocate all the memory required at once such that all of it is contiguous. Also, the performance impact has nothing to do with the JIT. It follows from how indexes in contiguous vs. ragged arrays are computed. The JIT can't do much in this case apart from providing speedup by a constant factor. (Actually, it could do more if Java had true multidimensional arrays)
    - tralarpa 3y ago
      > MULTIANEWARRAY Oh, I didn't know that. Weird. IIRC there are no corresponding special instructions for accesses to multidimensional arrays. > Also, the performance impact has nothing to do with the JIT What I meant: The authors didn't expect that the JIT compiler would become so good in compiling the bytecode, that the performance difference between contiguous vs. ragged arrays actually becomes relevant.
- alkonaut 3y ago
  It just means you don't have to special case any particular scenario such as array-of-array, it's no different than array-of-whatever. Also jagged arrays form a complication. But even for the simple case of large non-jagged arrays: In the situation where you needed this perf gain as a developer you would still need to be able to specify the order e.g. row-major or column-major, since the VM won't know your access pattern. So if you make your own matrix class you would be better off storing a flat array yourself and doing the access arithmetic yourself like index = y*cols + x. It would be a pretty cumbersome API in Java if they had this in the declaration api and you declared double[100][100] how would you declare whether that 10k flat array is row major or column major? If the VM gets it wrong for your access pattern then a lot of the perf gain from fewer pointer indirections will be eaten by cache misses from looking in the wrong order.
  - samus 3y ago
    This information could be made part of the type of the array. Bases on the type, Java could then compute the proper index.
    - alkonaut 3y ago
      Yes, but you'd have a whole set of additional data (number of dimensions e.g. 2 and then the order of access for those dimensions). And that would affect the size of every array instance, which is something you really don't want. Or the compiler would need to keep track of it on the type level so that a row-major array can't be passed where a column major is expected etc. In any case it would really make the APIs overly complicated.
      - samus 3y ago
        It would be 4 byte more per array for metadata, plus the sizes. It would actually require less memory than ragged arrays, which have to record the size in each subarray. API complexity could be handled by a polymorphism mechanism to make it possible to write code that is generic regarding row/column access order.
- dzaima 3y ago
  If you keep the interface the exact same, you run into some pretty big complications, as with the current interface you can change one row out with another object with a single statement, or similarly get a row object as such (which you do implicitly in "arr[a][b]"!). So you'd have to still store an object per row in addition to the data to keep their identity the same each time they're gotten, and have some way to transform out of this representation if the last reference to the 2D array is via a single row of it, GCing away the rest of the rows.
- deleted 3y ago
  [deleted]

Pannoniae 3y ago

No, I mean for the JVM.... the interface could remain the same but the pointer indirections could be avoided. I don't see the downsides, that's why I'm asking.

tralarpa 3y ago
I guess it was just to simplify the original specification of the JVM (if two dimensional arrays are just arrays of arrays, you don't need special instructions for them). I can also imagine that the original JVM designers did not expect JIT compilers to one day become so good that the performance difference becomes relevant.
- samus 3y ago
  But there is actually a special bytecode instruction to create multidimensional arrays: MULTIANEWARRAY. My suspicion is that it allows a sufficiently sophisticated JVM to allocate all the memory required at once such that all of it is contiguous. Also, the performance impact has nothing to do with the JIT. It follows from how indexes in contiguous vs. ragged arrays are computed. The JIT can't do much in this case apart from providing speedup by a constant factor. (Actually, it could do more if Java had true multidimensional arrays)
  - tralarpa 3y ago
    > MULTIANEWARRAY Oh, I didn't know that. Weird. IIRC there are no corresponding special instructions for accesses to multidimensional arrays. > Also, the performance impact has nothing to do with the JIT What I meant: The authors didn't expect that the JIT compiler would become so good in compiling the bytecode, that the performance difference between contiguous vs. ragged arrays actually becomes relevant.
alkonaut 3y ago
It just means you don't have to special case any particular scenario such as array-of-array, it's no different than array-of-whatever. Also jagged arrays form a complication. But even for the simple case of large non-jagged arrays: In the situation where you needed this perf gain as a developer you would still need to be able to specify the order e.g. row-major or column-major, since the VM won't know your access pattern. So if you make your own matrix class you would be better off storing a flat array yourself and doing the access arithmetic yourself like index = y*cols + x. It would be a pretty cumbersome API in Java if they had this in the declaration api and you declared double[100][100] how would you declare whether that 10k flat array is row major or column major? If the VM gets it wrong for your access pattern then a lot of the perf gain from fewer pointer indirections will be eaten by cache misses from looking in the wrong order.
- samus 3y ago
  This information could be made part of the type of the array. Bases on the type, Java could then compute the proper index.
  - alkonaut 3y ago
    Yes, but you'd have a whole set of additional data (number of dimensions e.g. 2 and then the order of access for those dimensions). And that would affect the size of every array instance, which is something you really don't want. Or the compiler would need to keep track of it on the type level so that a row-major array can't be passed where a column major is expected etc. In any case it would really make the APIs overly complicated.
    - samus 3y ago
      It would be 4 byte more per array for metadata, plus the sizes. It would actually require less memory than ragged arrays, which have to record the size in each subarray. API complexity could be handled by a polymorphism mechanism to make it possible to write code that is generic regarding row/column access order.
dzaima 3y ago
If you keep the interface the exact same, you run into some pretty big complications, as with the current interface you can change one row out with another object with a single statement, or similarly get a row object as such (which you do implicitly in "arr[a][b]"!). So you'd have to still store an object per row in addition to the data to keep their identity the same each time they're gotten, and have some way to transform out of this representation if the last reference to the 2D array is via a single row of it, GCing away the rest of the rows.
deleted 3y ago
[deleted]