vector vs pole

[VODA]

Zdravím,
zeptám se asi úplně jako lama, ale jak je to s rychlostí procházení prvků vektoru o proti klasickému poli...
Jde mi o to, že mám třídu pro animovaný model. Mám dvě varianty. Jedna má data modelu uložena v dynamicky alokovaných polích, druhá má data kompletně uložená ve vektorech.
No a když renderuji model, tak v prvním případě mám 2x více FPS než u vectorové varianty...
Přitom způsob renderu je u obou případů úplně stejný...

Tak já nevím...

Předem děkuji za vysvětlení. Jsem rád za každou přiležitost, kdy se mohu něco přiučit...
_________________
Opravdovost se pojí s trýzní...

[VODA]

Trochu jsem ještě pokusoval a zjistil jsem, že přístup k prvkům vectoru je v DEBUG módu mnohem pomalejší než u pole, ale v RELEASE módu nad polem vítězí...
Takové srovnání (model je kreslen zatím glBegin/glEnd, má 2500 trianglů):

Debug: vector 147 FPS, pole 248 FPS
Release: vector 380 FPS, pole 332 FPS

Jako věděl jsem, že v Releasu pojede program rychleji, ale netušil jsem, že by to mohlo mít takový vliv...

Pokud je tu nějaký odborník, budu rád když mi to vysvětlíte...
_________________
Opravdovost se pojí s trýzní...

[Pavel]

Nejsem odbornik.

V debugu je pristup k prvku vectoru (operator[]) implementovan jinak nez v releasu. V debugu obsahuje nejspise alespon testy na to, zda ses trefil do alokovanych hranic - stejne jako metoda at.

I ve vectoru se interne alokuje pole, proto myslim, ze bude jen zanedbatelne pomalejsi, ale tezko bude rychlejsi.

[rezna]

jak rika pavel - vector interne testuje spoustu veci, aby se debugu zarucilo ze nesahas mimo apod.

[]semo[]

A ještě jedna věc: když spustíš release z Visual Studia (s debugerem), tak to je taky pomalejší. Release, Ctrl+F5, to je ta správná rychlost! :-).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[Mantharis]

Kdyz uz to tu resime tak me se hodne osvedcilo klasicky pole vuze svych programu uplne vypustit a vsechno cpat do vektoru.
Myslim ze az na tu debug rychlost a malilinko vetsi pametovou rezii neni jediny rozumny duvod klasicky dynamicky pole jeste pouzivat.
_________________
If the God gave us the source code we could bug the world.

[Al]

No tak měřit rychlost v debugu, to je velká bláznovina. V nastavení projektu ve visualku se dá nastavit i něco "napůl cesty", aby se třeba dal program krokovat a zároveň to nebylo hrozivě pomalé při běhu. Ale na měření rychlosti bych teda používal bez výjimky jen maximálně optimalizovaný release.

[pcmaster]

Jediny hlavny rozdiel bude ten, ze (std::)vector je natahovaci. Tj, pri prekroceni uz alokovaneho poctu poloziek sa cely moze interne realokovat, co samozrejme znamena invalidaciu vsetkych iteratorov.
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[perry]

Nějak nechápu, jak může být Vector rychlejší než klasické pole. Měl jsem za to, že vector je datová struktura obalující pole a umožňující, aby se pole natahovalo... Ale tím pádem by pořád mělo být rychlejší alokované pole na správnou velikost + jeho naplnění. U průchodu by to pak mělo být cca. stejné.
_________________
Perry.cz

[Quiark]

No s tím natahováním to imho není tak horké - když překročíš kapacitu, musí se naalokovat nové a stávající prvky do něj překopírovat (jeden po druhém, pomocí operator =)!. Funkce realloc() se tam nepoužívá.
_________________
Mám strach

[pcmaster]

Ja som netvrdil, ze sa tam pouziva realloc() Akurat efekt je velmi podobny, pretoze AFAIK interne pole vo vector je vzdy spojite v jednom kuse, takze ak za akutalne zaalokovanym polom je uz ina zaalkovana pamat, musi sa cele znovu zaalokovat (realokovat) na uplne inom mieste v jedinom bloku a obsah sa tam prekopiruje. Ci?
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Quiark]

Jo, ale to kopírování bude pomalé. realloc dokáže použít volný blok v heapu a tak zvětšit množství naalokované paměti bez kopírování.

Ale jelikož vector alokuje trochu paměti navíc, tak i při neustálém přidávání je cena za přidání amortizovaně konstantní, což je v pohodě, takže asi řešíme nesmysly
_________________
Mám strach

[VODA]

Také nevím proč to řešíte. Mě zajímal rozdíl rychlosti přístupu do vectoru přes operator [] o proti klasickému poli.

Předpokládám, že v releasu jsem u vectoru dosáhl lepších výsledků o proti poli díky lepší linearizaci dat...i když nevím přesně, jestli jsem jí docílil vlastní zásluhou...
_________________
Opravdovost se pojí s trýzní...

[Tringi]

Jsou dvě alternativy.
První je, že důvod pro výkonový rozdíl se skrývá ve tvém kódu.
Druhou pak to, že kompilátor svou magií ví, že se jedná o vektor a jak se s ním pracuje (nebo spíš přesněji ví co nelze), a na základě toho umí kód zoptimalizovat lépe než pro obyčejné pole. Ale to je můj tip, používám MinGW, a nikoliv MSVC.
_________________
WWW | GitHub | TW

[VODA]

No, já jsem to asi zapomněl zmínit, ale já používám taktéž minGW pod Eclipsem...
_________________
Opravdovost se pojí s trýzní...