XE2: ASM und Pascal gemischt?

[daywalker9]

Oder besser: Typen dafür definieren und diesen nutzen.

[jaenicke]

Zitat von Schorschi5566:

P.S.: Der Vorteil den der Autor des Wrappers darin gesehen hat, dürfte sein, dass man keinen "doppelten" Funktionsaufruf macht, sondern die DLL-Funktion den Rücksprung direkt machen kann.

// EDIT:
Ok, ich sehe es, aber wo liegt da der große Vorteil? Die paar Mikrosekunden Zeitersparnis?

[Schorschi5566]

Zitat:

Ok, ich sehe es, aber wo liegt da der große Vorteil? Die paar Mikrosekunden Zeitersparnis?

Wird sich zeigen. Werde dann mal die Win32 und die Win64-Version vergleichen. Wirkt sich wahrscheinlich eh erst ab ein paar Millionen Aufrufen auf der Stopuhr aus.

[Insider2004]

Seit XE2 gilt mehr denn je: weg mit dem Assembler-Zeugs! Pascal ist mittlerweile genauso schnell. Und es entfällt das ständige Neuschreiben beim Portieren. Die beste Performance erreicht man durch gescheite Algorithmen, nicht durch Assembler.

[USchuster]

Assembler hat für gewisse Bereiche und Probleme durchaus seine Berechtigung. Der heutige 0815 Programmier sollte darauf verzichten und lieber den Compiler optimierten Code erzeugen lassen, wobei sich das Verzichten ohnehin oft durch die fehlenden Kenntnisse erübrigt. Assemblerunterstützung war ursprünglich nicht für Win64 im XE2 geplant und die Lösung zur Nutzung von Assembler wäre dann das Einbinden von Objektdateien von z.B. NASM gewesen. Das es Assemblerunterstützung doch gibt, liegt daran das die entsprechende Nachfrage besteht.

[Stevie]

Zitat von USchuster:

Assemblerunterstützung war ursprünglich nicht für Win64 im XE2 geplant und die Lösung zur Nutzung von Assembler wäre dann das Einbinden von Objektdateien von z.B. NASM gewesen. Das es Assemblerunterstützung doch gibt, liegt daran das die entsprechende Nachfrage besteht.

Wenn ich mir so manche RTL Units anschaue, frag ich mich, wie sie es sonst selber relativ unkompliziert hinbekommen hätten.

[jaenicke]

Zitat von Insider2004:

Pascal ist mittlerweile genauso schnell.

Naja, das stimmt zumindest so allgemein nicht. Wenn man sich den generierten Assemblercode angeht, sieht man, dass es da durchaus Optimierungspotential gibt.

Es gibt aber nicht viele Fälle, bei denen der relativ kleine Performancegewinn wirklich ins Gewicht fällt. In diesen Fällen kann es sich aber dann durchaus lohnen Assembler einzusetzen, auch wenn das heißt, dass man den Code für verschiedene Plattformen mehrfach schreiben muss. Das ist dann aber auch nicht so schlimm, weil es eben nicht so viele Fälle sind.

[Schorschi5566]

Zitat:

Die beste Performance erreicht man durch gescheite Algorithmen, nicht durch Assembler.

Sehr oft lassen sich "gescheite" Algorithmen aber mit Assembler richtig gut optimieren.

Aber wie Sebastian Jaenicke schon schreibt. Es muss sich schon lohnen, wenn man in die ASM-Kiste greift...

Hatte gehofft, der Compiler würde den überflüssigen Aufruf zu 'nem Jump optimieren, tut er aber nicht.

[himitsu]

- Lade alles statisch.
- Lade doch alle Adressen gleich zu Beginn und springe danach direkt hin, ohne den Wrapper.
oder
- Lade überall erstmal Laderoutinen rein und tausche diese, beim ersten Aufruf, aus.

Delphi-Quellcode:

interface

var
  SQLite3_Open: function(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl;

implementation

function _SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl;
begin
  LoadProcAddress(SQLite3_Open, 'sqlite3_open');
  Result := SQLite3_Open(filename, db);
end;

initialization

SQLite3_Open := _SQLite3_Open;

Ich weiß jetzt nicht, wie das mit Konstanten in Mac oder 64 Bit aussieht, aber früher hätte ich eventuell eine typisierte Konstante mißhandelt, anstatt der globalen Variable (da diese grungsätzlich erstmal schreibgeschützt ist, was sich aber verbiegen läßt)

[samso]

Dieser ASM-Trick wird häufig verwendet (z.B. Jedi-Projekt). Es gibt drei Vorteile:
1) Es braucht nicht jedesmal eine individuelle global variable deklariert zu werden. Wenn man nur eine Funktion wrappen muss spielt das keine Rolle, aber bei 150 Funktionen macht einen dieses ständige Copy&Paste schon ganz schön müde.
2) Die Parameter, die sich ja sowieso schon auf dem Stack befinden, werden nicht nochmal auf den Stack kopiert
3) Ein sicherlich zu vernachlässigender Zeitvorteil beim Sprung/Rücksprung in die eigentliche Routine

Wenn der Compiler eine Aufrufkonvention unterstützen würde, bei der die Parameter nicht nochmals kopiert werden müssten, könnte man sich den Umweg über Assembler sparen. Ich würde mir so etwas wünschen (entsprechend des Aufrufs "inherited;"):

Delphi-Quellcode:

var
   _SQLite3_Open: FARPROC;

function SQLite3_Open(filename: PAnsiChar; var db: TSQLiteDB): integer; cdecl;
begin
   if _SQLite3_Open = nil then
     LoadProcAddress(_SQLite3_Open, 'sqlite3_open');
   _SQLite3_Open;
end;