Prozessorspeziefische Assemblerbefehle
-
@rapso
Hast du nicht im letzten Post gesagt, man soole mehrere Versionen kompilieren? Oder meinst du mehrere Dll's und ich lade dann zur Laufzeit die entsprechende DLL?
-
Ishildur schrieb:
@rapso
Hast du nicht im letzten Post gesagt, man soole mehrere Versionen kompilieren? Oder meinst du mehrere Dll's und ich lade dann zur Laufzeit die entsprechende DLL?naja, wenn die initialisierung fehlschlaegt und es zurueck geht, ist wohl das ganze binary wohl unbrauchbar ;).
Dll ist eine moeglichkeit, eine simple alternative ist ein loader. ob ein program erfolgreich war oder nicht kannst du ueber exit(..) zurueckliefern und deine loader exe muss nicht viel tun ausser alle programme in der liste durchgehen bis eines zurueckliefert dass es erfolgreich war.also falls du dir quick&dirty ein dll system sparen willst.
(falls es noch nicht eindeutig rueberkam, ein binary pro konfiguration, mit nem define als build parameter die verschiedenen einstellungen permutieren).
-
Ishildur schrieb:
Das Problem das ich sehe ist nun halt, dass das Programm, wenn keiner dieser Befehlssätze verfügbar ist, je ein cmp und je zusätzlich im Code drinnen haben werde...
Servus,
hierzu möchte ich etwas anmerken. Nur weil es einen Befehl im z.B. SEE-Satz gibt,muss dies noch lange nicht heißen, dass dieser die Laufzeit verkürzt. Die meisten Befehls-Erweiterungen tragen nur in einer gewissen Situation und/oder Kombination zu einer wirklichen Verbesserung bei.
Das solltest du nicht vergessen.Zudem sollte man nicht von Anfang an alles tot optimieren. Erst nach ein paar Test's sollte man überlegen, denn Code zu optimieren. Hierzu gehört auch der Algorithmus. In den meisten Fällen wird nur am Algo optimiert und man gewinnt hier, "in der Regel", die meiste Zeit.
Ansonsten würde ich dir empfehlen, den Assembler-Code auszulagern und evtl. den Präprozessor zu benutzen.
-
Wo ist denn hier genau das Problem?
Bist du ein 64kb-proggi Extrem-Demoszener, der keinen Platz mehr hat für eine einfache Cpuid Überprüfung?;)
-
nachtfeuer schrieb:
Wo ist denn hier genau das Problem?
Bist du ein 64kb-proggi Extrem-Demoszener, der keinen Platz mehr hat für eine einfache Cpuid Überprüfung?;)planst du etwa den ganzen code mit if-else zu durchziehen?
-
Was spricht dagegen den Code der SSE/MMX/... verwendet in eigene Funktionen zu packen, und diese dann über Funktionszeiger aufzurufen?
Dadurch käme man mit einer .exe aus, und hätte trotzdem keine "if" in den Funktionen.
-
hustbaer schrieb:
Was spricht dagegen den Code der SSE/MMX/... verwendet in eigene Funktionen zu packen, und diese dann über Funktionszeiger aufzurufen?
Dadurch käme man mit einer .exe aus, und hätte trotzdem keine "if" in den Funktionen.Nichts. Die Frage ist "Warum?". Und für welchen Zweg?
-
Siassei schrieb:
hustbaer schrieb:
Was spricht dagegen den Code der SSE/MMX/... verwendet in eigene Funktionen zu packen, und diese dann über Funktionszeiger aufzurufen?
Dadurch käme man mit einer .exe aus, und hätte trotzdem keine "if" in den Funktionen.Nichts. Die Frage ist "Warum?". Und für welchen Zweg?
Weil ich es persönlich unpraktisch finde unnötigerweise zwei oder mehr Executables zu erstellen. Und es in diesem Thread so dargestellt wurde, dass das die einzig sinnvolle Möglichkeit wäre. Ausser ganz darauf zu verzichten irgendwelche Optimierungen anzubringen. Ob "ganz verzichten" eine sinnvolle Option ist weiss ich nicht, ich kenne ja nichtmal die genaue Aufgabenstellung.
Der OP hat eine konkrete Frage gestellt. Ich denke man kann zur Abwechslung auch mal einfach darauf antworten, ohne gleich zu unterstellen, dass er seine Hausaufgaben nicht gemacht hat, und die Optimierung ja vermutlich sowieso sinnlos ist.
@Ishildur:
Nimm Funktionszeiger, oder verlass dich auf die Branch-Prediction der CPU.
Wenn das "if" nicht in einer engen Schleife vorkommt, wird es vermutlich auch egal sein ob nun "if" oder Funktionszeiger oder eigene .exe.
Zumal die ganzen MMX/SSE/... Intrinsics vom Compiler vermutlich sowieso nicht ganz wegoptimiert werden können (würde mich zumindest wundern).
-
hustbaer schrieb:
Was spricht dagegen den Code der SSE/MMX/... verwendet in eigene Funktionen zu packen, und diese dann über Funktionszeiger aufzurufen?
Dadurch käme man mit einer .exe aus, und hätte trotzdem keine "if" in den Funktionen.das wuerde nur bei grossen funktionen sinn machen, in vielen faellen z.b. eine vector lib, waere ein aufruf ueber einen function pointer vermutlich weit aus langsammer als die nicht vektorisierten c funktionen.
-
@rapso:
Hmja, an sowas hab ich gernicht gedacht.
In so einem Fall sind Funktionszeiger natürlich total kontraproduktiv, da kein inlining etc.p.S.: ich hab bei MMX/SSE/... gleich mal an Bildbearbeitung/Signalverarbeitung gedacht, wo man ja oft wenige "grosse" Funktionen hat die man auf die Daten loslässt. Da könnte man mit Funktionszeigern oder eben einfach "ifs" IMO ganz gut arbeiten.
