PureBoard

Hi Leute,

hab bisher noch nie mit ASM (steht für Assembler, glaub ich) geproggt, hab aber gehört das es sehr viel schneller sein soll als "normaler" Code, oder?

Wollte jetzt fragen ob es sich lohnt einzelne Berechnungen (genauer die Entfernung zwischen zwei Point strukturierten Variablen) damit auszuführen?

Gruß
Scarabol

wie führst du sie denn bisher aus?

poste mal code...

Gruß
Scarabol

Also mehr als das hier geht wohl nicht:

Ok, danke hab ich geändert.

Wie sieht es den Grundsätzlich mit dieser Art von Berechnungen aus, ASM ja oder nein? Oder wofür wird es am häufigsten verwendet (schreibt bitte nicht "optimieren", genauer!)?

Gruß
Scarabol

Scarabol hat geschrieben:Ok, danke hab ich geändert.

Wie sieht es den Grundsätzlich mit dieser Art von Berechnungen aus, ASM ja oder nein? Oder wofür wird es am häufigsten verwendet (schreibt bitte nicht "optimieren", genauer!)?

Gruß
Scarabol

Achja, was man noch machen könnte: Pow() ist soweit ich weiß noch ein CALL, also kannst du das mal durch x = (ax-bx) : y = (ay - by) und dann x * x statt Pow(x, 2) und y * y statt Pow(y, 2) machen, aber dann hast du ein mehrzeiliges Macro oder du machst wieder eine Prozedur draus. Also Grundsätzlich wird der ganze PB Code sowieso in Assembler umgewandelt. Du musst ihn nur ein bisschen von Hand optimieren können (Kompillier mal einen testcode mit "pbcompiler.exe deinePBDatei.pb /COMMENTED" und schau dir PureBasic.asm im Compiler Verzeichnis an).

Also ich habe mal ein C-Programm mit Assembler optimiert, und da ging noch einiges. Gerade was Schleifen anging, Calls, und unnötige Wertzuweisungen. Heutzutage sind Compiler natürlich in der Lage, vieles davon selbst zu optimieren, und es kommt auch vor, daß er sogar besseren Code produziert, als wenn man selbst mit Assembler rumfrickelt (vor allem, wenn man noch nicht viel Ahnung davon hat).

In vielen Fällen ist es gar nicht nötig, mit Assembler zu optimieren. Meist liegen die Perfromance-fressenden Probleme nämlich ganz woanders, z.B. im verwendeten Algortihmus, in der Speicherverwaltung oder sonst etwas. Erst wenn man das alles 100%ig ausschließen kann, und das Programm immer noch zu langsam ist, sollte man drüber nachdenken, ob mit Assembler noch was zu machen ist.

Ich weiß jetzt nicht wie es bei Dir aussieht: Willst du einfach nur Assembler lernen, oder hast Du grad ein konkretes Performance-Problem mit Deinen 2 Punkten, wo Du einfach vermutest, daß Assembler die einzige Lösung ist? Falls letzteres zutrifft, wäre es evtl. sinnvoller, wenn Du erstmal Dein Problem und Deine Vorgehensweise schilderst, denn es ist denkbar, daß der wahre Flaschenhals ganz woanders sitzt (und das können echt simple Denkfehler sein).

DarkDragon hat geschrieben:Also mehr als das hier geht wohl nicht:

Code: Alles auswählen

Macro Distance(Pos1X, Pos1Y, Pos2X, Pos2Y)
  Sqr(Pow(Pos1X-Pos2X, 2)+Pow(Pos1Y-Pos2Y, 2))
EndMacro

falsch, da geht noch der aller wichtigste punkt:
1.) die verwendung von Pow() ist extrem langsam.
deswegen besser splitten, und DX*DX verwenden.

2.) wenn man distanzen vergleichen will, kann man sich bei beiden das wurzelziehen sparen.
dann verwendet man gleich D2 zum vergleichen, der rest des algorithmus entfällt.


Bevor man sowas nicht drauf hat, braucht man mit ASM nicht anzufangen.
es ist föllig egal, ob man die Pow() funktion von ASM aus oder von PB aus aufruft,
der Trick ist, sie überhaupt nicht aufzurufen.

es ist föllig egal

Sowas ist mir aber nicht egal

Kaeru Gaman hat geschrieben:

DarkDragon hat geschrieben:Also mehr als das hier geht wohl nicht:

Code: Alles auswählen

Macro Distance(Pos1X, Pos1Y, Pos2X, Pos2Y)
  Sqr(Pow(Pos1X-Pos2X, 2)+Pow(Pos1Y-Pos2Y, 2))
EndMacro

falsch, da geht noch der aller wichtigste punkt:

...

Ja lies mal zuerst alles zuende. Mein 2. Post sagt nämlich genau das. Man kann es machen wie man will.

...Pow() funktion von ASM aus oder von PB aus aufruft...

Nunja, wenn PB intelligent wäre würde es auch Pow als Compiler-Inside-Makro halten und es ersetzen, aber anscheinend tut es das ja nur bei anderen Funktionen.