Ist die ternäre Operation in iPhone besser als "if/else"?

Question

Ich habe diesen Block in meinem Programm:

if (x > 0) {
    a = 1;
    b = 4;
} else {
    a = 2;
    b = 3;
}

Dies kann mit einer ternären Operation wie folgt geschrieben werden:

a = (x > 0) ? 1 : 2;
b = (x > 0) ? 4 : 3;

Die Ergebnisse sind äquivalent, aber es handelt sich um einen wirklich kritischen Teil meiner Anwendung, der tausende Male pro Sekunde ausgeführt wird. Ich möchte einige Mikrosekunden einsparen, da diese Methode ein wenig wachsen wird.

Meine Frage: Auf ARM-Ebene, welche ist schneller? Ich glaube, dass der erste eine Branch-Anweisung erzeugt. Aber wie sieht es mit der ternären Operation aus? Wird diese auf dem iPhone auch zu einem Branch? Oder hat der ARM des iPhone ein böses Opcode, um die Arbeit zu erledigen?

Übrigens, ich habe auch eine böse Technik wie diese gesehen:

a = (x > 0) * 1 + (x <= 0) * 2;

Ist das wirklich schneller?

Answer 1

BEARBEITEN:

Gerade habe ich dein Beispiel kompiliert, mit GCC/LLVM, verschiedenen Optimierungen und habe mir das ARM6- und ARM7-Assembly angesehen, hier sind meine Schlussfolgerungen:

• ARM-ASM unterscheidet sich je nach GCC / LLVM und Zielarchitektur
• Aber, wenn der höchste Optimierungsgrad verwendet wird, wird genau der gleiche Assemblercode für if und ternary erzeugt, und das unabhängig von Compiler/Architektur ist. (ja, habe mehrere Paare verglichen ;)

Hier ist das prägnanteste Ergebnis mit LLVM / ARM7, unter Verwendung der IT-Instruktion, die du erwähnt hast, für if und ternary:

MOVS    R1, #2
CMP     R0, #0
IT GT
MOVGT   R1, #1
MOV.W   R2, #3
IT GT
MOVGT   R2, #4

ENDEBEARBEITEN

Habe gerade ein wenig zum Thema gesucht und auch wenn einige Leute denken, dass der ternäre Operator weniger optimiert ist, besagen die meisten Ergebnisse und relevanteren Informationen, dass er den gleichen Assemblercode erzeugt.

Beachte, dass sich dies ändern kann durch:

1. Compiler wie GCC, LLVM...
2. Optimierungsgrad

Ich bin im Moment etwas faul, um Code zu disassemblieren, aber vielleicht überarbeite ich diese Antwort später.

Also ich denke, djna hat recht, abgesehen von den 2* (x>0), was wirklich überraschend wäre, wenn es nicht optimiert wäre, ist das gleich.

Nachdem, ob ternär oder nicht, es ist eine Geschmacksfrage. Ich bevorzuge ternär, wenn es im Code Sinn macht und lesbar ist.

Zum zweiten Beispiel ist es ein Trick, der die Tatsache ausnutzt, dass true == 1 / false == 0... Lustig, aber ich würde nicht gerne diesen Code pflegen.

Answer 2

Nein.

Es gibt keine Gewinner beim Code-Golf.

Lesbarkeit gewinnt.

Also ist in diesem Fall dein erstes Beispiel, das traditionelle bedingte Blöcke verwendet, ungefähr 7099092034902 Mal einfacher zu lesen. Jeder, der auch nur ansatzweise mit Programmierung vertraut ist, wird verstehen können, was los ist.

Im letzten Beispiel... Gott, was ist das!

Answer 3

Ein intelligenter Compiler könnte denselben Output für beide Codes erzeugen.

Ein nicht intelligenter Compiler würde dazu führen, dass (X>0) im ternären Operator-Fall zweimal ausgewertet wird und daher langsamer ist!

Answer 4

Nachdem ich jahrelang Software optimiert habe, würde ich wetten, dass der kleine Block, den Sie oben posten, nicht wirklich Ihr Problem ist. Ich denke, wir müssen die gesamte Methode zusammen mit einigen Profilergebnissen sehen (wenn es um Optimierung geht, ist Messen ALLES), um damit besser umzugehen.

Um Ihre eigene Frage zu beantworten - nehmen Sie jede Option und profilieren Sie diese für sagen wir 10 Millionen Aufrufe (tausend werden Ihnen nicht viel über das obige Fragment sagen). Das wird Ihnen zeigen, welche am schnellsten ist, es macht keinen Sinn, es im Voraus zu erraten.

Answer 5

Meine Frage: Auf ARM-Ebene, welcher ist schneller?

Warum schreiben Sie nicht ein einfaches Testprogramm, das die Ausführungsgeschwindigkeit für zum Beispiel 100.000 Aufrufe jedes Blocks misst?