stl und ausführgeschwindigkeit

hey

die stl ist vom universellen design her ja schön und gut, wenn man aber ausführgeschwindigkeit will, ist es dann wirklich schlau, iteratoren usw zu verwenden statt seine vektoren manuell zu indizieren z.b.?

SG1

Na dann erklär mal, wo der Performance-Unterschied zwischen einem Zeiger und einem Vektor-Iterator ist.

STL = Kein Runtime-Overhead. Prüf es selbst, wird alles wegoptimiert (ausser natürlich im Debug-Modus, da ist die STL signifikant langsamer, weil jeder Zugriff geprüft wird).

naja ich hab immer ein schlechtes gewissen wenn ich instanzen von iteratoren anlege, diese dann mit std::advance verschiebe und diese dann dereferenziere statt dass ich einfach den operator[] nutze (bei arrays und vectoren).

Nathan

std::vector<T>::iterator ist in manchen Implementierungen im Releasebuild einfach nur ein T*; kein Overhead.

jo okay, ihr habt mich überzeugt, danke. (:

Columbo

significant speed schrieb:

naja ich hab immer ein schlechtes gewissen wenn ich instanzen von iteratoren anlege, diese dann mit std::advance verschiebe und diese dann dereferenziere statt dass ich einfach den operator[] nutze (bei arrays und vectoren).

std::advance ist für Random-Access-Iteratoren entsprechend spezialisiert (und damit meine ich keine Template-Spezialisierung, intern wird da Tag-Dispatching durchgeführt).

__gnu_cxx::__normal_iterator kapselt - bei entsprechendem Template-Argument - nur die Operationen auf einen Zeiger, das wird definitiv alles geinlined.

Und der Index-Operator funktioniert genauso: *(E1 + E2) .

Sollte gleich schnell sein, aber dafür verbürge ich mich nicht.

volkard

significant speed schrieb:

naja ich hab immer ein schlechtes gewissen wenn ich instanzen von iteratoren anlege, diese dann mit std::advance verschiebe und diese dann dereferenziere statt dass ich einfach den operator[] nutze (bei arrays und vectoren).

Da kannste machen, wie Du willst. Ist gleich schnell.

Manchmal braucht man mit op[] aber eine Variable weniger! Zum Beispiel kein end, weil die Größe eh compilezeitkonstant ist, end aber nicht. Dann ist op[] potentiell schneller, weil eine weiter außen liegende Variable in ein Register hüpfen kann. Das AMD-Optimierungs-Handbuch legt da viel Wert drauf. Denke aber, die Compiler kennen den Trick auch schon lange, also schreib, was für Dich besser lesbar ist.

Columbo

Manchmal braucht man mit op[] aber eine Variable weniger! Zum Beispiel kein end, weil die Größe eh compilezeitkonstant ist, end aber nicht.

Wir reden von std::vector , nicht von einem (echten) Array.

Edit: Nein, auch von Arrays war die Rede. Gut, ist berechtigt. Andererseits sind die Zeiger auf Anfang und Ende eines echten Arrays doch auch konstant, also zumindest konstant genug um Optimierungsspielraum zu lassen?

volkard

Arcoth schrieb:

Manchmal braucht man mit op[] aber eine Variable weniger! Zum Beispiel kein end, weil die Größe eh compilezeitkonstant ist, end aber nicht.

Wir reden von std::vector , nicht von einem (echten) Array.

Edit: Nein, auch von Arrays war die Rede. Gut, ist berechtigt. Andererseits sind die Zeiger auf Anfang und Ende eines echten Arrays doch auch konstant, also zumindest konstant genug um Optimierungsspielraum zu lassen?

Lies Dein Maschinensprachbuch schnell fertig und schreib nochmal.