array vs vector



  • also damit er noch ne regel hat:
    Verwende immer Vector wo möglich ( statt array)



  • asmcode schrieb:

    Shade Of Mine schrieb:

    Skym0sh0 schrieb:

    ein normales c array ist schneller

    wieso sollte das so sein?

    beim zugriff mit [] wars glaub ich eine Operation mehr im Assemblercode

    Begruendung?



  • Shade Of Mine schrieb:

    asmcode schrieb:

    Shade Of Mine schrieb:

    Skym0sh0 schrieb:

    ein normales c array ist schneller

    wieso sollte das so sein?

    beim zugriff mit [] wars glaub ich eine Operation mehr im Assemblercode

    Begruendung?

    Das ist das " inline " 😃 🤡



  • asmcode schrieb:

    Shade Of Mine schrieb:

    Skym0sh0 schrieb:

    ein normales c array ist schneller

    wieso sollte das so sein?

    beim zugriff mit [] wars glaub ich eine Operation mehr im Assemblercode

    Zugriffe mit Zeigersyntax sind übrigens, für den Compilierer, wesentlich schwerer zu optimieren...



  • David_pb schrieb:

    Zugriffe mit Zeigersyntax sind übrigens, für den Compilierer, wesentlich schwerer zu optimieren...

    Begruendung?



  • Shade Of Mine schrieb:

    David_pb schrieb:

    Zugriffe mit Zeigersyntax sind übrigens, für den Compilierer, wesentlich schwerer zu optimieren...

    Begruendung?

    Weil der Compiler, ohne aufwendige Analyse, nicht genau weiß wohin durch den Zeiger geschrieben wird. Das schließt dann z.B. aliasing oder unbeschreibbaren Speicher ein. Damit ist es dann ziemlich schwer für den Optimierer, zu entscheiden an welcher Stelle optimiert werden soll.
    Beim []-Operator gibts diese Annahmen nicht, da ist klar wohin geschrieben wird und aliasing kann ausgeschlossen werden.

    Ist aber natürlich nicht zu verallgemeinern. Es kann Fälle geben bei denen die Zeigersyntax besser ist.



  • David_pb schrieb:

    Beim []-Operator gibts diese Annahmen nicht, da ist klar wohin geschrieben wird und aliasing kann ausgeschlossen werden.

    😮



  • David_pb schrieb:

    Shade Of Mine schrieb:

    David_pb schrieb:

    Zugriffe mit Zeigersyntax sind übrigens, für den Compilierer, wesentlich schwerer zu optimieren...

    Begruendung?

    Weil der Compiler, ohne aufwendige Analyse, nicht genau weiß wohin durch den Zeiger geschrieben wird. Das schließt dann z.B. aliasing oder unbeschreibbaren Speicher ein. Damit ist es dann ziemlich schwer für den Optimierer, zu entscheiden an welcher Stelle optimiert werden soll.
    Beim []-Operator gibts diese Annahmen nicht, da ist klar wohin geschrieben wird und aliasing kann ausgeschlossen werden.

    Ist aber natürlich nicht zu verallgemeinern. Es kann Fälle geben bei denen die Zeigersyntax besser ist.

    Hmm, wird hinter dem operator[] nicht auch nur ein Zeiger dereferenziert? Also beim Vektor meine ich.



  • Beim vector kann das sein. Weiß nicht in wie weit der Standard vorschreibt wie genau auf die internen Daten zugegriffen wird.



  • David_pb schrieb:

    Weil der Compiler, ohne aufwendige Analyse, nicht genau weiß wohin durch den Zeiger geschrieben wird. Das schließt dann z.B. aliasing oder unbeschreibbaren Speicher ein. Damit ist es dann ziemlich schwer für den Optimierer, zu entscheiden an welcher Stelle optimiert werden soll.
    Beim []-Operator gibts diese Annahmen nicht, da ist klar wohin geschrieben wird und aliasing kann ausgeschlossen werden.

    Ist aber natürlich nicht zu verallgemeinern. Es kann Fälle geben bei denen die Zeigersyntax besser ist.

    Und wer hat dir den quark erzählt?

    a[b] == *(a+b) == *(b+a) == b[a]

    fuer alle diese Ausdrücke wird jeder intelligente Compiler exakt den selben Code generieren.



  • Shade Of Mine schrieb:

    Und wer hat dir den quark erzählt?

    Steht in diversen Papers von AMD.

    Shade Of Mine schrieb:

    a[b] == *(a+b) == *(b+a) == b[a]

    fuer alle diese Ausdrücke wird jeder intelligente Compiler exakt den selben Code generieren.

    Jaja, Theorie und Praxis liegen z.T. schon weit auseinander... 🙄



  • Ich glaube du verwechselst da was.



  • Tim schrieb:

    Ich glaube du verwechselst da was.

    Ja? Dann klär mich mal auf.



  • David_pb schrieb:

    Tim schrieb:

    Ich glaube du verwechselst da was.

    Ja? Dann klär mich mal auf.

    zeig uns was in den AMD Papieren steht und wir erklären dir was du falsch verstanden hast.

    Was ich gepostet habe ist Prozessor unabhaengig.

    ein compiler kann manchmal mit laufenden zeigern besser optimieren als mit index zugriffen oder umgekehrt, aber das liegt daran wie gut er den code versteht. und manchmal versteht er den code mit der einen syntax besser.

    aber wenn ich auf p[5] zugreifen will, dann mach ich in asm ein

    mov ecx, p
    add ecx, 5
    mov eax, [ecx]

    die cpu sieht nie ob ich *(p+5) oder p[5] geschrieben habe. selbes bei laufenden zeigern versus index...



  • @ David_pb:

    Na ich weiss nicht, vorhin hast du von Zeiger-Aliasing und gleichzeitig von der unterschiedlichen Syntax beim dereferenzieren geredet. Zwei Dinge die eigentlich wenig miteinander zu tun haben. Vielleicht erklärst du das nochmal genauer?



  • Shade Of Mine schrieb:

    ein compiler kann manchmal mit laufenden zeigern besser optimieren als mit index zugriffen oder umgekehrt, aber das liegt daran wie gut er den code versteht. und manchmal versteht er den code mit der einen syntax besser.

    Hab ich das nicht geschrieben?

    ohne aufwendige Analyse

    So, hab nochmal die Quelle rausgekramt:

    The use of pointers in C makes work difficult for the optimizers
    in C compilers. Without detailed and aggressive pointer
    analysis, the compiler has to assume that writes through a
    pointer can write to any place in memory. This includes storage
    allocated to other variables, creating the issue of aliasing, i.e.,
    the same block of memory is accessible in more than one way.
    To help the C compiler optimizer in its analysis, avoid the use of
    pointers where possible. One example where this is trivially
    possible is in the access of data organized as arrays. C allows the
    use of either the array operator [] or pointers to access the
    array. Using array-style code makes the task of the optimizer
    easier by reducing possible aliasing.
    For example, x[0] and x[2] cannot possibly refer to the same
    memory location, while *p and *q could. It is highly
    recommended to use the array style, as significant performance
    advantages can be achieved with most compilers.



  • David_pb schrieb:

    Shade Of Mine schrieb:

    ein compiler kann manchmal mit laufenden zeigern besser optimieren als mit index zugriffen oder umgekehrt, aber das liegt daran wie gut er den code versteht. und manchmal versteht er den code mit der einen syntax besser.

    Hab ich das nicht geschrieben?

    Du hast nichts von laufenden Zeigern gesagt. Aber jetzt ist es klar.



  • David_pb schrieb:

    Hab ich das nicht geschrieben?

    Nein.

    Mal abgesehen dass diese Info mit laufenden Zeigern versus index schon jahre veraltet ist, ist je nach Situation das eine oder andere schneller wenn der compiler dumm ist. die zitierte quelle ist übrigens auch fehlerhaft. denn *p und *q kann das selbe sein, aber x[1] und x[2] hat mit dem p/q beispiel nix zu tun. und x[1] und y[2] können sehr wohl das selbe sein.

    früher war es so, dass je nach situation das eine oder andere schneller war, je nachdem wie gut der compiler das konstrukt verstanden hat.

    es gibt gerade bei optimierungen viele halbwahrheiten - meistens aus der zeit als c++ compiler stroh dumm waren. schau dir den generierten asm code heute einfach mal an. die compiler sind soviel klueger geworden und erkennen code konstrukte ziemlich gut.

    wenn also eine der beiden varianten schneller ist, dann ist es ein fehler im optimierer des compilers.

    und wie gesagt, diese laufende zeiger versus index diskussion ist seit jahren begraben... es sei denn man programmiert im embedded bereich, aber dann muss man sich sowieso an die bugs der compiler anpassen...



  • Hm, danke für die Info!



  • um es zu belegen:

    ich habe den code aus dem AMD64 OPtimierungsguide genommen:
    http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF

    test.c und test2.c sind die beiden Dateien:
    mit "gcc -O2 -S -c test.c"

    der code der generiert wird ist leicht unterschiedlich. ein diff liefert daher viele unterschiede (alles mov*, add*, mul*) aber:

    TS-MacBook-Pro:perftest ts$ cat test2.s | grep mov | wc -l
          25
    TS-MacBook-Pro:perftest ts$ cat test2.s | grep add | wc -l
          15
    TS-MacBook-Pro:perftest ts$ cat test2.s | grep mul | wc -l
          16
    TS-MacBook-Pro:perftest ts$ cat test.s | grep mov | wc -l
          25
    TS-MacBook-Pro:perftest ts$ cat test.s | grep add | wc -l
          15
    TS-MacBook-Pro:perftest ts$ cat test.s | grep mul | wc -l
          16
    

    und natürlich:

    TS-MacBook-Pro:perftest ts$ cat test.s | wc -l
          77
    TS-MacBook-Pro:perftest ts$ cat test2.s | wc -l
          77
    

    also wenn es einen unterschied gibt an dem code, dann kann er nicht messbar sein...


Anmelden zum Antworten