Nazgul Temat założony przez niniejszego użytkownika |
OpenGL glGenTextures(n, texture) - czas tworzenia tekstur w zaleznosci od parametru n » 2017-08-25 00:36:27 Dzien dobry, Mysle, ze oczywistym jest, ze kod GLuint textures[ 2 ];
glGenTextures( 2, textures );
Wykona sie szybciej niz GLuint textures[ 2 ];
glGenTextures( 1, & textures[ 0 ] );
glGenTextures( 1, & textures[ 1 ] );
Tylko zastanawia mnie o ile szybciej.. Czy to dziala jak dodawanie elementow std::list, czy bardziej jak std::vector? Moze przedstawię analogie
std::vector < int > v;
v.resize( 3 );
v[ 0 ] = 1;
v[ 1 ] = 2;
v[ 2 ] = 3;
std::vector < int > v;
v.push_back( 1 );
v.push_back( 2 );
v.push_back( 3 );
( zakladam ze system przydziela miejsce w czasie niezaleznym od ilosci potrzebnej pamieci i aktualnego stanu calej pamieci )
Bede bardzie wdzieczny za pomoc |
|
pekfos |
» 2017-08-25 00:42:40 Dlaczego to ma działać jak kontenery? Przecież w obu przypadkach cała potrzebna pamięć jest dana z góry. Skąd te pytanie? Myślisz że różnica jest na tyle duża, że opłaca się brać uchwyty na zapas? |
|
Nazgul Temat założony przez niniejszego użytkownika |
» 2017-08-25 00:57:25 W tym wszystkim nie wiem tylko jak zachowuje sie pamiec karty graficznej. Skoro oba przypadki sa rownowazne, to nie rozumiem dlaczego dali w ogole opcje generowania tablicy tekstur |
|
Kinexity |
» 2017-08-25 01:11:01 Po pierwsze sprawdź, czy po kompilacji nie wychodzi tak naprawdę to samo - przy tak krótkich i mało zróżnicowanych dwóch wersjach kodu efekt może być ten sam. |
|
pekfos |
» 2017-08-25 01:17:41 Zaszłość historyczna, pole do popisu dla implementacji sterowników, albo po prostu popularny use case. Jak potrzebujesz naraz kilku nowych tekstur, nie pisz pętli którą zrobiono za ciebie. A jeśli nie jest po drodze tworzyć tekstury hurtem, świat też się nie zawali, bo nawet jeśli jest różnica w wydajności, to przecież tworzenie tekstur to nie jest coś co robi się bez umiaru. |
|
Nazgul Temat założony przez niniejszego użytkownika |
» 2017-08-25 01:26:21 Minus dobrych kompilatorow - kompilator moze oba testowe kody skompilowac do takiej samej postaci:P sprobuje, chociaz obawiam sie, ze wyniki beda tak oscylowac, ze nic ciekawego z tego nie wywnioskuje |
|
Elaine |
» 2017-08-25 02:05:03 | Wolna wersja(czas dla duzych n moze byc paskudnie olbrzymi) |
Dodawanie N elementów do wektora przy pomocy push_back zajmuje O(n) czasu, więc różnica między wersją "szybką" a "wolną" jest co najwyżej stała. | Minus dobrych kompilatorow - kompilator moze oba testowe kody skompilowac do takiej samej postaci:P |
Nie znam żadnego kompilatora, który byłby w stanie tak zoptymalizować wywołania glGenTextures, bo z punktu widzenia kompilatora glGenTextures to zewnętrzna funkcja, o której nic nie wie. |
|
Nazgul Temat założony przez niniejszego użytkownika |
» 2017-08-25 15:05:21
Dodawanie N elementów do wektora przy pomocy push_back zajmuje O(n) czasu, więc różnica między wersją "szybką" a "wolną" jest co najwyżej stała.
|
http://www.cplusplus.com/reference/vector/vector
Internally, vectors use a dynamically allocated array to store their elements. This array may need to be reallocated in order to grow in size when new elements are inserted, which implies allocating a new array and moving all elements to it. This is a relatively expensive task in terms of processing time, and thus, vectors do not reallocate each time an element is added to the container.
Instead, vector containers may allocate some extra storage to accommodate for possible growth, and thus the container may have an actual capacity greater than the storage strictly needed to contain its elements (i.e., its size). Libraries can implement different strategies for growth to balance between memory usage and reallocations, but in any case, reallocations should only happen at logarithmically growing intervals of size so that the insertion of individual elements at the end of the vector can be provided with amortized constant time complexity (see push_back).
|
|
|
| « 1 » 2 |