Search

open.mp forum

RegisterLogin

Discussion

General
Chat
Tech
Life
Art
Programming
open.mp
Development Updates
Questions and Suggestions
SA-MP
General Discussions
Videos and Screenshots
Support
Pawn Scripting
Tutorials
Releases
Plugins
Libraries
Filterscripts
Gamemodes
Maps
Advertisements
Other languages
Spanish/Espa?ol
Programaci?n
Discusi?n GTA SA Multijugador
Mods
Offtopic
Juegos
Portuguese/Portugu?s
Russian/???????
Italian/Italiano
Dutch/Nederlands
German/Deutsch
Romanian/Rom?na
Ex-Yu
Polish/Polski
Og?lne
Serwery
Skryptowanie
Filmiki i zdjecia
Lithuanian/Lietuvi?kas
French/Fran?ais
Hungarian/Magyar
Hindi/Urdu
Turkish
Other
Internal
Team
Hidden
Archived

Library

 Collections Links Members Roles

[Include] pawn-array-view: non-owning spans for multi-dimensional pawn arrays

pawn-array-view

ID
d6ouivfilegovhg7b6hg
author
yashas's avatar

Yashas

@yashas


View profile
Copy link
  Report member
started
Apr 17, 2019
replies
0
participating
No

scroll to top

powered by storyden

Login
Discussion
Plugins
[Include] pawn-array-view: non-owning spans for multi-dimensional pawn arrays
yashas's avatar

Yashas

@yashas


View profile
Copy link
  Report member
• 7y
Plugins

[Include] pawn-array-view: non-owning spans for multi-dimensional pawn arrays

plugin

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.

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[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


  • array_view.hpp

  • documentation

  • examples

  • project repository

  • develop branch (interesting stuff happens here)

0 likes0 replies

    Please sign up or log in to reply