PureBoard

Zu der Performance von Assembler-Anweisungen: Generell ist es so das eine Anweisung nicht zwingend nur 1 Tic lang dauert. Viele dauern mehrere Tics. Und es ist, zumindest für mich, nicht wirklich offensichtlich welche Anweisungen nun tatsächlich schneller sind. Zudem unterscheided sich das noch von CPU zu CPU Model.

Was mich erstaunt aber tatsächlich so ist: Es gibt viele Fälle wo man eine große Assembleranweisung in mehrere kleine aufsplittet und dadurch einen Performancegewinn erwirtschaftet. z.b. ist der Loop-Befehl langsamer als wenn man selbst dekrementiert/inkrementiert und mit einem conditional Jump die Schleife selbst baut.

> SAR, wo das oberste Bit nicht mit 0 aufgefüllt wird, sondern mit dem Vorzeichenbit des Operanden.
> War das Vorzeichenbit 1, wird auch wieder mit 1 aufgefüllt.
Möglicherweise bin ich ein bisschen mit schuld daran, dass wir aneinander vorbeireden.

Fakt ist, dass ich nicht wusste, dass es auch singed Shifts gibt, ich kannte bis dato nur unsinged Shifts, so wie ich es in der Schule gelernt habe.

Das war das, worüber ich mit Danilo drüber geredet habe.
Mit ZeHa wollte ich mich eigentlich über die verschiedenen Operatoren unterhalten und darüber, was schneller ist.

> ich dachte er möchte 1 für Zahlen <0 raushaben, sonst 0.
Jein. Die Webseite will -1 für x<-1 und 0 für x>=0. So wollte ich das eigentlich auch haben.
Dann hat aber Kaeru Gaman gesagt er steigt nicht durch. Beim Versuch ihm das zu erklären bin ich an eine Stelle angelangt, an der ich nicht weiterkam - ich wusste plötzlich selbst nicht mehr, wie 1|x>>31 funktioniert.
Warum? Weil ich SAR (singed Shifts) nicht kannte.


------------------------------------------------------


OK, also jetzt hzabe ich z. B. das Macro a>>31&1...

@ ZeHa:
Ist das denn performanter als die gleichwertige If-Abfrage? Wenn ich z. B. an den Operator <= denke...

@ Danilo:
Ich stelle einfach ein Minus voran, also -a>>31&1, schon habe ich wie gewünscht -1 für negative und 1 für positive Zahlen.

Vielen Dank übrigens für die Information mit signed Shifts. ist doch eigentlich Dreck, jetzt weiß ich endlich, warum ~1 = -2 ist...
Und wieder ein Rätsel der Menscheit gelöst! ^^

Das heißt, ich benötige ~x&1, um aus einer 1 eine 0 und einer 0 eine 1 zu machen, richtig?

Thorium hat geschrieben: z.b. ist der Loop-Befehl langsamer als wenn man selbst dekrementiert/inkrementiert und mit einem conditional Jump die Schleife selbst baut.

Ahso. Heißt das, das For langsamer ist als While n<10:n+1:Wend?

AND51 hat geschrieben:

Thorium hat geschrieben: z.b. ist der Loop-Befehl langsamer als wenn man selbst dekrementiert/inkrementiert und mit einem conditional Jump die Schleife selbst baut.

Ahso. Heißt das, das For langsamer ist als While n<10:n+1:Wend?

auch das war wieder auf ASM bezogen und nicht auf PB...

Es wird nur schneller sein, wenn man nur +1 rechnet, dann da gibt es ja einen extra befehl...
wobei aber bei For x = 0 to 100 denk ich in +step gemacht wird.
das kann dann eben langsamer sein

Kaeru Gaman hat geschrieben:auch das war wieder auf ASM bezogen und nicht auf PB...

Grundsätzlich:
PB = ASM

PureBasic bietet

Optimale Ausnutzung der verfügbaren Hardware durch Verwendung hochoptimierter (Asm) Befehle

, schließlich wird jeder PB-Befehl in ASM Code übersetzt.

In sofern war meine For-vs-While Frage durchaus berechtigt, ich hätte mein While-Konstrukt auch in ASM-Syntax hinschreiben können, aber ich kenne mich mit ASM noch nicht gut genug aus...


@ Andreas_S
Achso meinst du das... Musste grad zweimal überlegen.
Ja zum in- und dekrementieren gibt es INC und DEC. ich weiß niht, wie Step 1 bei For umgesetzt wird, aber ich denke mal, genauso. Es sei denn Step ist ungleich 1.

AND51 hat geschrieben:

Thorium hat geschrieben: z.b. ist der Loop-Befehl langsamer als wenn man selbst dekrementiert/inkrementiert und mit einem conditional Jump die Schleife selbst baut.

Ahso. Heißt das, das For langsamer ist als While n<10:n+1:Wend?

Ne PB compiliert das optimiert. Also der PB-Compiler nutzt einige ASM-Instuktionen wie Loop garnicht. Der baut die schleife selbst.

Ich wollte nur mal in die Runde werfen das es bei dem ganzen Performance-Kram stellen gibt wo man garnicht so leicht durchblickt warum nun das eine performanter ist als das andere. Auf ASM bezogen.

Thorium hat geschrieben:Ne PB compiliert das optimiert. Also der PB-Compiler nutzt einige ASM-Instuktionen wie Loop garnicht. Der baut die schleife selbst.

Ah, cool. Das heißt, ich brauche eigentlich gar nicht (so viel) in ASM rumpfuschen, das macht PB wirklich schon optimal?
Hat ASM dennoch Vorteile, bei denen sich die Nutzung in PB lohnt?

Naja, ich denk mir das der Code nicht ultimativ optimiert wird, desswegen
könnten Kenntnisse nützlich sein. Da du ja zum ASM-Code zugang hast...

Bei Sprachen wie C++ würde ich aufs Optimieren verzichten, da die Compiler mittlerweile so gut sind, daß sie das meist 10x besser hinkriegen als ein ASM-Programmierer. Es gibt aber sicherlich hin und wieder Fälle, wo eine "von Hand"-Lösung dennoch besser sein kann, aber bei den meisten Dingen, wo man meint, optimieren zu müssen, wird die Lösung des Compilers sicherlich gut genug oder besser sein.

Wie das bei PureBasic ausschaut, weiß ich allerdings auch nicht. Es ist sicherlich nicht so gut optimiert wie z.B. ein GCC (der ja nicht nur von einem alleine entwickelt wird), aber auch hier würde ich ASM echt nur dann einsetzen, wenn man wirklich weiß, was man tut, und warum man es tut.