XOR Implementierung langsam? (Intel Architektur x86)
-
Hi,
unser Dozent meinte das ein XOR (sei es Assembler oder c/c++) langsam sei. Es soll wohl schlecht (oder einfach nur langsam) implementiert worden sein.
Stimmt das denn überhaupt? Hat sich das bis Heute nicht geändert? Mein Problem ist nämlich, das ich Daten in eine Datei schreiben möchte (in C++). Diese sollen vorher mit XOR "verschlüsselt" werden. Ok, ein simples XOR ist nicht wirklich sicher, ich brauche aber nur ein n00b Schutz und es soll so schnell wie möglich gehen.
Falls es wirklich langsam ist (und mein Dozent recht hat
), kann man die CPU dann austricksen in dem man das XOR einfach in OR's und AND's umwandelt?A XOR B = (A OR B) AND (~A OR ~B)Das sind dann aber trozdem 5 Operationen...
-
kann ich nicht bestätigen. sehe auch keinen grund dafür: ein xor ist doch nicht schwerer als ein and oder or zu implementieren.
-
Also ich habe zumindest keine Ahnung, was euer Dozent gemeint haben koennte.
Xor braucht heute wie der ganze restliche Fizzel-Kram auch nur einen Takt.
Auf dem 8086 duerfte es genau so schnell wie or und and gewesen sein.
-
Camper schrieb:
kann ich nicht bestätigen. sehe auch keinen grund dafür: ein xor ist doch nicht schwerer als ein and oder or zu implementieren.
Nobuo T schrieb:
Also ich habe zumindest keine Ahnung, was euer Dozent gemeint haben koennte.
Xor braucht heute wie der ganze restliche Fizzel-Kram auch nur einen Takt.
Auf dem 8086 duerfte es genau so schnell wie or und and gewesen sein.Ich kann das nämlich auch nicht so richtig glauben.
-
Nach meinem Wissen werden elementare Operationen wie AND OR XOR durch Hardware berechnet.
Der Laufzeitunterschied dürfte daher recht gering sein.
-
Nobuo T schrieb:
Xor braucht heute wie der ganze restliche Fizzel-Kram auch nur einen Takt. Auf dem 8086 duerfte es genau so schnell wie or und and gewesen sein.
Ich hab das Buch "Assembler Referenz". Wenn man da in der Referenz nachschaut kommen _genau_ die gleichen Laufzeiten für or/xor raus, wobei erst ab dem 486 und nur für Benutzung von zwei registern eine Laufzeit von einem Taktzyklus. Bei Verwendung des Speichers ergibt sich eine Laufzeit von 2-3 (Abhängig von der Art des opcodes).
-
Kann es sein, dass er darauf anspielt, dass man die alte Regel, dass man Register durch selbst-xor statt mov nullsetzen soll, heute vielleicht nicht mehr unbedingt befolgen soll?
-
Bashar schrieb:
Kann es sein, dass er darauf anspielt, dass man die alte Regel, dass man Register durch selbst-xor statt mov nullsetzen soll, heute vielleicht nicht mehr unbedingt befolgen soll?
das soll man? ich glaube micht erinnern zu können, dass die prozessoren extra dafür optimiert wurden (d.h. die falsche abhängkeit vom vorhergehenden wert wird eleminiert).
-
Keine Ahnung, ich meine das mal irgendwo gelesen zu haben. Kann auch Unsinn sein.
-
imho ist das keine Frage der Implementation, sondern eine schaltungstechnische Frage. XOR wie OR Gatter sind mit 3 Transistoren realisierbar, ein AND mit 2 und ein NOT mit einem.
-
Die Schaltung *ist* die Implementation
-
Diese berechnungen werden teilweise über ein ROM gemacht.
Was nützt der kleine Laufzeitvorteil wenn mann dan auf den Tackt warten muss.
-
Hi
das ist das problem der Taktgetriebenen Prozessoren. Die anderen funktionieren nur im experimentierstadium.
gruss