Allgemeine Frage zur Geschwindigkeit in Asm
-
Hi,
hab eine Frage, die einige Befehle betrifft, z.B. MUL oder auch IMUL usw.: Werden diese Befehle auch intern durch Schleifen von ADDs simuliert? Falls das der Fall ist, wäre es dann nicht schneller (dafür aber umständlicher ^^), jeden MUL Befehl durch eine Schleife zu ersetzen?
Gruß
Johannes
-
im allgemeinen dürte eine 'simulation' stets erheblich langsamer sein als die benutzung von mul/imul. nat. gibt es einige ausnahmen, wenn ein faktor bekannt ist. nat. ist z.b. add eax, eax schneller als die multiplikation mit 2; auf dem p4 (ausser prescott) sogar erhblich schneller als shl eax, 1
generell lässt sich die multiplikation mit 2er potenzen und 3,5,9 (x86) auf anderem wege schneller realisieren.
mul/imul sind zwar erheblich langsamer als normale adds, allerdings bei weitem nicht soweit, dass ein ersatz durch add vorteile bringt, schon allein aufgrund der permanenten abhängigkeiten, die eine parallele ausführung ausschliessen.
-
Assembler kannst du nie allgemein schnell machen, da es von der CPU abhängt, wie was implementiert wurde. Also schnapp dir die Dokumente, die dein CPU Hersteller zur CPU rausgibt und lies nach was da steht und teste ein wenig rum. rdtsc ist dein Freund.
-
kingruedi schrieb:
rdtsc ist dein Freund.
nur im real modus
- oder genauer: nicht in multi-tasking systemen.
-
Wieso das? In der Regel misst man ja nur ein paar Instruktionen, und die Chance, dass gerade dazwischen ein Task Switch liegt, ist verschwindend gering. Außerdem fällt es soundso sofort auf, weil du ja mehrere Messungen machen wirst.
-
wenn du nur kuze zeiten nimmst, also z.b. einen durchgang irgendeiner berechnung, dann ist die absolut gemessene zeit relativ klein - in diesem falle wird die messung u.a. dadurch relativ stark verfälscht, als rdtsc ja nicht auf die beendigung vorhergehender befehle wartet - im gegenteil - es könnte sogar wegen out of order execution ohne weiteres ausgeführt werden, bevor die berechnung beendet ist. umgekehrt könnte genauso die startzeit zu früh oder zu spät genommen werden. ich zweifle, ob sich dieses problem durch wiederholte messung gänzlich eliminieren lässt, einfach deshalb, weil die zeitmessung selbst einen signifikanten anteil an der gesamtzeit beansprucht. aus diesem grunde halte ich es für sinnvoller, nur grosse zeiten zu messen - stellen, die man auf geschwindigkeit optimiert sind ja ohnehin in aller regel irgendwelche schleifen, so dass man hier häufig keinen extra code einfügen muss. das os hält ja fest, wieviel zeit tatsächlich in einem process aufgewandt wurde, so dass man sich dann auch auf diese zeiten, wie sie vom system geliefert werden, verlassen kann. ein taskswitch selbst mag vergleichsweise selten sein und nicht ins gewicht fallen. das muss aber nicht unbedingt für die zeit gelten, die in anderen threads vergeht.
das soll dich selbstverständlich nicht davon abhalten, rdtsc zu verwenden. man sollte sich nur der damit verbundenen probleme bewusst sein. system calls sind ja auch nicht ohne probleme, zumal die zeitauflössung relativ gering ist, was man ja aber durch grössere messzeiten recht leicht kompensieren kann. erlaubt ist sowieso alles, was läuft und auswertbar ist
-
Ich würde es so trimmen, dass ich ein paar tausend Cycles messe. Ist immer noch kurz genug, um bequem zwischen die Timer Interrupts zu passen.
Ist rdtsc nicht eh serialisierend, wie cpuid?
-
Ringding schrieb:
Ist rdtsc nicht eh serialisierend, wie cpuid?
dem intel manual zufolge nicht.