Zu viele Parameter für einen Funktionsaufruf in C?

[Andi_Rostock]

Hallo zusammen,

ich bastle mir gerade ein Löser für Differentialgleichungen in C.
Die meisten vorhandenen Löser sind ja in Fortran geschrieben, die auch zum Teil nach C portiert wurden. Nun ist mir aufgefallen, dass bei diesen in C übersetzten Lösern die Funktionsaufrufe furchtbar lang sind. Hier ein Beispiel:

static int dopcor (unsigned n, FcnEqDiff fcn, double x, double* y, double xend,
		   double hmax, double h, double* rtoler, double* atoler,
		   int itoler, FILE* fileout, SolTrait solout, int iout,
		   long nmax, double uround, int meth, long nstiff, double safe,
		   double beta, double fac1, double fac2, unsigned* icont, double* duser,
		   int* iuser)

Nun stellt sich für mich die Frage, ob dies nicht eher hinderlich ist und man(n) besser durch Zusammenfassen der Parameter in Strukturen oder Vektoren den Aufruf beschleunigen könnte.
Von der Lesbarkeit her, wäre es sicher sinnvoll.
Was meint Ihr?

Viele Grüße
Andreas

[jeebee]

Afaik wird der Aufruf nicht schneller, wenn du die Parameter in structs oder was auch immer zusammenfasst. Es müssen ja trotzdem alle Parameter bereitgestellt und wieder gelesen werden. (x86-asm: jeder Parameter einer Funktion wird vor Funktionsaufruf auf den Stack gelegt => n Instruktionen für n Parameter; Wenn du structs hast, müssen diese gefüllt werden und dann noch für den Funktionsaufruf auf den Stack gelegt werden, da gewinnst du sehrwahrscheinlich nichts -- verlierst aber auch unwesentlich). Von der Lesbarkeit her stimm ich mit dir überein, z.B. die Toleranzen könntest du gut in einem struct oder einem Array (ich würde zu nem struct tendieren) zusammenfassen.

[BLUESCREEN3D]

Nun stellt sich für mich die Frage, ob dies nicht eher hinderlich ist und man(n) besser durch Zusammenfassen der Parameter in Strukturen oder Vektoren den Aufruf beschleunigen könnte.

Ich würde da nur optimieren, wenn die Funktion einen Bottleneck darstellt und ansonsten auf Lesbarkeit setzen und wie von jeebee vorgeschlagen logische Gruppen bilden, die du auch im restlichen Quellcode nutzen kannst.

[jeebee]

Was ich noch vergessen hatte zu erwähnen:

die Optimierung die du (eventuell) bei der Parameter-Übergabe erreichst (auf einem halbwegs aktuellen System), wird in den meisten Fällen wo's um numerische Probleme geht sowieso irrelevant sein. Die Zeit besser dazu verwenden einen schnellen Algo zum Lösen auszuwählen / zu implementieren / zu optimieren / zu erfinden (für Fortgeschrittene ).

[Andi_Rostock]

Besten Dank für die Tipps.
Ich werde mich für die Lesbarkeit entscheiden und ein paar Strukturen einführen.
So kann der Fkt-Aufruf doch einfacher gestaltet werden.
Ich hasse Fkt-Aufrufe die über mehrere Zeilen gehen :-)

Nen neuen schnellen Algo zu entwickeln traue ich mir nicht zu. Bin halt kein Mathematiker. Ich portiere jedoch gerade einen Fortran-Code nach C.
Ich weiß, dass ich das nicht machen bräuchte... Ich will aber
Mit f2c ist's mir zu viel gefrickel. Ausserdem lerne ich gleich wie der Algo funzt.

Viele Grüße
Andi

[jeebee]

Das mit dem neu-entwickeln war auch eher als Scherz zu verstehen, es existieren ja schon genug effiziente Algorithmen zum DG-Lösen

[Hun]

Warum portierst du? Normalerweise ist es leichter den Code beizubehalten und in der C-App gegen den Fortran-Code zu linken. Zumal die Optimizer fuer Fortran nach wie vor besser sind..

[Andi_Rostock]

Klar könnte man einfach gegen Fortran linken. Unter Linux zumindest.
Der Aufwand wäre (glaube ich) unter Windows etwas größer. Naja, so wichtig ist es aber nicht.
Ich finde von der Ästhetik her C-Code irgendwie schöner. Ich weiss, dass das kein besonderer, objektiver Grund.

Es geht für mich auch darum, den Löser zu verstehen. Ist übrigens der RADAU5 Löser von Hairer und Wanner. Gibt auch ein tolles Buch von den Beiden, wo der Lösungsalgo schön erklärt wird.