AVX Intrinsics - SPeicherzugriffsfehler

Hab auf die Schnelle folgendes gefunden:
http://stackoverflow.com/questions/410982/is-there-a-difference-in-term-of-performance-between-unsigned-int-and-int-on

Sone schrieb:

Es gibt Operationen in dennen unsigned schneller ist, weil er optimieren kann (*4 = Bitshift).

http://ideone.com/ACqJgw[/quote]

Jetzt ersetze das Zweite durch ein Bitshift. Ich würde auch definitiv ein int verwenden als ein char, weil int mehr zur Hardware passt.

Zeus

aasdsad schrieb:

Hab auf die Schnelle folgendes gefunden:
http://stackoverflow.com/questions/410982/is-there-a-difference-in-term-of-performance-between-unsigned-int-and-int-on

Die erste Antwort ist ARM spezifisch.

SeppJ

aasdsad schrieb:

SeppJ schrieb:

... nix machen (wegen der Darstellung) ...

Ich weiß nicht ob ich das hier so unterschreiben würde. Die Darstellung ändert sich nicht von allein sobald ein overlow vorliegt. Ein Ring der wieder das erste Bit kippt ist ja etwas anderes als eine Addition. Im Prinzip weiß ich es nicht sooo genau. Alles reine Vermutung. Vielleicht weiß ja jemand was etwas genauer was die Laufzeitumgebung an diesem Punkt treibt.

Mit Darstellung meine ich so etwas wie Zweierkomplement. Egal, ob signed oder unsigned, Addition im Zweierkomplement kommt ganz ohne Fallunterscheidung aus. Die simplen Rechenregeln sind fest verdrahtet im Rechenwerk und können genau gleich für jede Zahlenkombination benutzt werden, egal ob Überlauf oder kein Überlauf. Und als Bonus läuft der signed Datentyp auch noch wie intuitiv erwartet über. Toll, oder?

Sone schrieb:

...

Was mich jetzt noch total wundert ist, dass er überhaupt Zeit braucht. Ich meine, dass dein Code nichts anderes macht als die Zeit auszugeben. Wenn die Optimierungen an sind sollten auch nur diese Zeilen übrig bleiben:

#include <iostream>
#include <ctime>

int main()
{
    clock_t first = clock();
    std::cout << "unsigned braucht " << clock() - first << '\n';

    first = clock();
    std::cout << "signed braucht " << clock() - first << '\n';
}

Eigenartig... ich würde erwarten, dass er im Release zwei mal 0 bringt. tmp wird nirgendwo benutzt,wozu soll der Compiler diese Variable nach der Optimierung behalten??

SeppJ

Änderungen an volatile-Variablen dürfen nicht einfach wegoptimiert werden.

SeppJ schrieb:

Änderungen an volatile-Variablen dürfen nicht einfach wegoptimiert werden.

Auch nicht vom Linker, er sieht ja, dass das vollständige Programm diese Variable an keiner Stelle nutzt.

aasdsad schrieb:

Auch nicht vom Linker, er sieht ja, dass das vollständige Programm diese Variable an keiner Stelle nutzt**?**

Sollte eine Frage sein..

Falls es jemanden interessiert: Ich kann das Verhalten hier mit gcc 4.7 auf keiner Optimierungsstufe nachvollziehen. Beide Varianten brauchen in allen Fällen genau gleich lang, was daran liegt, dass genau der gleiche Maschinencode erzeugt wird.

Ich weiß nicht, was die ideone-Leute da in ihren Compileroptionen haben.

@aasdsad: Der Compiler weiß nicht, dass es sich dabei nicht um ein magisches Outputregister für irgendwas handelt. Soweit der das beurteilen kann (darf), hängt da ne IR-LED hinter, die genau im richtigen Rhythmus betrieben werden soll.

Um wieder zu mir zu führen, ich hab tatsächlich nur die Parameter von

void *memalign(size_t boundary, size_t size);

durcheinandergebracht?

ich geh in die ecke und schäm mich. Danke an Seppj.

Zu der Anwendung:
Das hier ist gerade nur ein wenig Spielerei um mich auf die eigentliche Anwendung
vorzubereiten. Deshalb spielt die Performance hier in diesem Beispiel noch keine Rolle.

ABer vielen Dank für die rege Diskussion