open.mp forum
[Plugin] [Include] pawn-array-view: non-owning spans for multi-dimensional pawn arrays - Printable Version

+ open.mp forum (https://forum.open.mp)
-- Forum: SA-MP (https://forum.open.mp/forumdisplay.php?fid=3)
--- Forum: Releases (https://forum.open.mp/forumdisplay.php?fid=13)
---- Forum: Plugins (https://forum.open.mp/forumdisplay.php?fid=32)
---- Thread: [Plugin] [Include] pawn-array-view: non-owning spans for multi-dimensional pawn arrays (/showthread.php?tid=316)

[Include] pawn-array-view: non-owning spans for multi-dimensional pawn arrays - Yashas - 2019-04-17

pawn-array-view

pawn-array-view is an efficient C library that abstracts the complex memory layout of multi-dimensional pawn arrays and provides an intuitive C/ array-like interface for dealing with them. The name suggests that the library only allows read-only access to the arrays but that's not true; you can access and modify the arrays. Any decent C compiler will be able to optimize off all access and modifications to the arrays into simple pointer arithmetic.

Defects (Help Wanted)
LICM optimizations aren't pushing loop invariant subexpressions out of the loop because of aliased pointers. I haven't figured out how to correctly place restrict qualifiers which aren't ignored.

Code:
int main() {
    pawn::array_view<int, 3> array((cell*)0x10000);
    for(int i = 0; i < 100; i) {
        for(int j = 0; j < 100; j) {
            for(int k = 0; k < 128; k) {
                array[i][j][k] = 10;
            }
        }
    }
    return 0;
}

The compiler does not move the array[i][j] calculations outside the loop. There is a valid reason to not move them since modifying an element could modify something which would require recalculating the indexes. This is useful only when indirection tables are being modified. The common case is data being modified but not the indirection table. In this situation, moving the calculations out of the loop improves performance.

There are more consequences. The compiler can also vectorize the loop if it manages to pull the subexpression out of the loop. The failure to move the subexpression outside the loop prevents a ton of optimizations.

Note that the optimizations happen when the array is only being read. The problem is for modifications only.

Plans
If the size of the arrays are known at compile-time, a better interface can be provided. I have plans on providing full-fledged container like support for arrays where the dimensions are available at compile time.

There is a project going on in the develop branch which has working but inefficient code for dealing with known dimensions at run-time.

I plan on renaming array_view to span. This include was initially providing a view but then the ability to mutate was added but the name wasn't changed. It's a very misleading name now.

Links