Funktionsaufruf in C

Der "Aufruf" erzeugt einen gewissen Overhead, d.h. besser die Schleife 
in die Funktion packen. Je nach Optimierung kann dann der Aufruf inlined 
und/oder die Schleife selbst entrollt werden. Kommt auf den Code an

Egonwalter M. schrieb:
> was ist bezgl Speicherplatz und Rechengeschwindigkeit besser

Das mal eben zu schreiben und zu compilieren ist keine Lösung?

Jeder Funktionsaufruf kostet ein paar Prozessor-Zyklen. Auch die lokalen 
Variablen werden jedes Mal angelegt.
Also wäre die zweite Option etwas (geringfügig) günstiger.

Aber: Die Frage ist ob sich das in irgend einer Weise auf das System 
auswirkt. Sinnvollerweise legt man Schleifen dort an wo sie logisch 
gesehen hingehören um das Programm so auch lesbarer zu gestalten.
Alles Andere gehört in die Kategorie ›mehr oder weniger sinnloses 
Optimieren‹.

Bezüglich Speicher ist es egal. Bezüglich Laufzeit ist die Schleife in 
der Funktion schneller, die Zeit für den Funktionsaufruf fällt nur 
einmal an.
Ob das für Deinen Fall relevant ist, müsste man extra betrachten.

Egonwalter M. schrieb:
> Ich habe eine Frage zum Aufruf einer Funktion

auch wenn vielleicht schon alles gesagt ist: Funktionen macht man vor 
allem, um Teiloperationen zu separieren/gruppieren. Wenn Du die Funktion 
nur an einer Stelle brauchst, könntest Du sie sonst auch weglassen.

Darum gehört die Schleife dahin, wo die Schleifenbedingungen und äußeren 
Abhängigkeiten thematisch hingehören. Oder anders herum: wo die Summe 
der Parameter einfacher/weniger wird.

Wenn Du ein Beispiel bringst, wirst Du das verstehen.

Der Compiler optimiert den Code besser als man denkt. Insofern sollte 
man sich eher darauf konzentrieren, dass der Quelltext für den Menschen 
gut lesbar ist.

Abgesehen davon sind gerade beim AVR Funktionsaufrufe deutlich 
"billiger", als bei vielen anderen Mikrocontrollern.

Nur um kurz zu zeigen, dass wirklich das gleiche rauskommt.
Ausser das Beispiel ist jetzt übervereinfacht.

Ich verpacke mittlerweile sogar Zugriffe auf einzelne I/O Pins in 
Funktionen, bloß um ihnen sprechende Namen zu geben:

1

void set_power_led_on() {

2

    PORTB |= 1;

3

}

4

5

void set_power_led_off() {

6

   PORTB &= ~1;

7

}

8

9

bool start_button_pressed() {

10

   return (PINB & 2);

11

}

Selbst so etwas wird vom Compiler auf ein Minimum (nämlich einen 
einzigen Assembler Befehl) reduziert, wenn man es mit einem konstanten 
Parameter aufruft:

1

void set_power_led(bool on) {

2

    if (on) PORTB |= 1;

3

    else PORTB &= ~1;

4

}

Wir hatten hier mal einen Assembler Spezi, der meinte, er könne es 
besser als der C Compiler. Die Wette hatte er verloren.

Norbert schrieb:
> Jeder Funktionsaufruf kostet ein paar Prozessor-Zyklen. Auch die lokalen
> Variablen werden jedes Mal angelegt.

Du vergisst, dass der Optimizer den Code umstrukturiert. Dein Satz gilt 
so generell nur, wenn man den Compiler mit Option -O0 aufruft.

Stefan ⛄ F. schrieb:
> Wir hatten hier mal einen Assembler Spezi, der meinte, er könne es
> besser als der C Compiler. Die Wette hatte er verloren.

Naja, und wir hatten Projektansätze wie etwa einen Spektrum-Analyzer für 
den Audio-Bereich oder einen Westminster-Gong, die aber niemals 
benutzbare Realität wurden, bis sich kompetente Assemblerprogrammierer 
ihrer angenommen haben...

Bitte auch das bedenken...

Und weiters bitte ich zu bedenken: fast alles, was unfähige 
C-Programmierer im Bereich Signalanlyse im Laufe der Jahre auf dem AVR8 
gebacken bekommen haben, basiert wiederum auf den FFT-Routinen von Elm 
Chan, der die einerseits auch wieder in Assembler verfaßt hat, 
andererseits aber wohl eindeutig C bevorzugt, wenn möglich.

Sprich: es muß wohl doch was dran sein, dass man mit Asm deutlich 
effizienteren Code erzeugen kann als es ein C-Compiler könnte...

Das kannst du nicht wegdiskutieren.

Mal ganz davon abgesehen: man braucht doch bloß in den Code der Compiler 
selber zu schauen: Assembler ohne Ende. Das wird nur vor den volldummen 
C-only-Schranzen versteckt, aber es ist DA.

c-hater schrieb:

> Mal ganz davon abgesehen: man braucht doch bloß in den Code der Compiler
> selber zu schauen

Gemeint ist natürlich nicht der Code der Compiler selber, sondern der 
der Runtime für das Target. Das noch zu Klarstellung.

c-hater schrieb:
> egal was

Tschüss, ich bin raus

Stefan ⛄ F. schrieb:
> Norbert schrieb:
>> Jeder Funktionsaufruf kostet ein paar Prozessor-Zyklen. Auch die lokalen
>> Variablen werden jedes Mal angelegt.
>
> Du vergisst, dass der Optimizer den Code umstrukturiert. Dein Satz gilt
> so generell nur, wenn man den Compiler mit Option -O0 aufruft.

Das macht er? Macht er das auch wenn die Funktion an verschiedenen 
Stellen (Sourcecode-Dateien) aufgerufen wird und selbst ebenso in einer 
separaten Datei (oder vielleicht in einer Library) liegt?

Aber ich weiß worauf du hinaus willst… ;-)

Stefan ⛄ F. schrieb:
> c-hater schrieb:
>> egal was
>
> Tschüss, ich bin raus

Du bist vor allem auch eins: Ein Zitatfälscher. "Egal was" schrieb ich 
an keiner Stelle.

Mal rein "gefühlt": Wenn Du in der main() den Aufruf auf eine Funktion 
mit einer Endlos-Loop findest, und dieses Programm erweitern sollst...

...ok, ich mach das nicht mehr professionell, aber ich würde mich 
verarscht fühlen.

c-hater schrieb:
> Stefan ⛄ F. schrieb:
>
>> Wir hatten hier mal einen Assembler Spezi, der meinte, er könne es
>> besser als der C Compiler. Die Wette hatte er verloren.
>
> Naja, und wir hatten Projektansätze wie etwa einen Spektrum-Analyzer für
> den Audio-Bereich oder einen Westminster-Gong, die aber niemals
> benutzbare Realität wurden, bis sich kompetente Assemblerprogrammierer
> ihrer angenommen haben...
> Bitte auch das bedenken...
> Und weiters bitte ich zu bedenken: fast alles, was unfähige
> C-Programmierer im Bereich Signalanlyse im Laufe der Jahre auf dem AVR8
> gebacken bekommen haben, basiert wiederum auf den FFT-Routinen von Elm
> Chan, der die einerseits auch wieder in Assembler verfaßt hat,
> andererseits aber wohl eindeutig C bevorzugt, wenn möglich.
> Sprich: es muß wohl doch was dran sein, dass man mit Asm deutlich
> effizienteren Code erzeugen kann als es ein C-Compiler könnte...
> Das kannst du nicht wegdiskutieren.
> Mal ganz davon abgesehen: man braucht doch bloß in den Code der Compiler
> selber zu schauen: Assembler ohne Ende. Das wird nur vor den volldummen
> C-only-Schranzen versteckt, aber es ist DA.

Ein reflektierter und abwägender Beitrag von c-hater. Lesen war spannend 
-- ich hab die ganze Zeit auf den Holzhammer gewartet und er kam nicht! 
Und bei den volldummen Schranzen ganz zum Schluss war es dann irgendwie 
schon zu spät ...

LG, Sebastian

Jörg W. schrieb:
> Norbert schrieb:
>> Macht er das auch
>
> mit -flto ggf. schon

OK. Also, ich schreibe eine Funktion welche einen Sack voller lokaler 
Variablen anlegt, verarbeitet und einen Return Wert generiert.
Die packe ich in eine Library.

Und der Compiler zupfelt mir das später auseinander, arrangiert alles 
neu und packt es wo auch immer hin?
Ähm, ich vermute eher nicht.

Aber du schriebst ja auch:  Link-Time Optimierung und ggf

Dirk B. schrieb:
> Norbert schrieb:
>> Jeder Funktionsaufruf kostet ein paar Prozessor-Zyklen. Auch die lokalen
>> Variablen werden jedes Mal angelegt.
>
> Das anlegen der Variablen kostet aber keine Zeit.

Auf'm Stack muss der (frame)Pointer angepasst werden. OK, nur wenige 
Zyklen. Lokale Variablen müssen jedes mal initialisiert werden. Auch nur 
wenige Zyklen. Selbst ein lokaler alloca() ist überschaubar.

Was aber wenn ich mit malloc() einen großen Arbeitbereich brauche?
Einmal malloc(), 1.000.000 mal Schleife und arbeiten, einmal free()
oder
1.000.000 mal eine Funktion aufrufen mit jeweils:
malloc(), arbeiten, free()

Es kommt immer auf den jeweiligen Fall an.

Jörg W. schrieb:
> Wie du eben schreibst: zum Separieren/Gruppieren kann das trotzdem
> sinnvoll sein.

So war das "sonst" gemeint: wenn es nicht um dieses Vorteils wäre.

Mein oben genanntes Beispiel:

> void set_power_led(bool on) {
>     if (on) PORTB |= 1;
>     else PORTB &= ~1;
> }

wird ebenfalls auf einen einzigen Assembler Befehl reduziert, selbst 
wenn es in einer anderen *.c Datei steht, als wo es benutzt wird.

Aber nur, wenn -flto benutzt wird und die Optimierungsstufe mindestens 
auf -O2 oder -Os gestellt ist. Mit -O1 bleibt es ein Funktionsaufruf.

Teo D. schrieb:
> Nur ha ich nicht ganz (eher gar nicht:) verstanden, warum das in
> einem do-while Block gepackt wird?-{

Die defines sind unter gewissen Umständen problematisch. Was du da 
siehst, ist ein Workaround, der diese Probleme vermeiden soll.

Schau mal
https://stackoverflow.com/questions/14041453/why-are-preprocessor-macros-evil-and-what-are-the-alternatives

Den Absatz "Macro expansions can have strange side effects.". In der 
Diskussion werden noch einige weitere potentielle Probleme mit dem 
Markos genannt.

Ich fand Makros früher mal super toll für HW Zugriffe, bin aber auch 
wieder davon weg gekommen, nach ich mit damit selbst ein paar mal ins 
Knie geschossen hatte und auch oft mit unverständlichen Fehlermeldungen 
vom Compiler konfrontiert wurde.

Die vielen Beispiele mit aus heutiger Sicht unnötigen Makros stammen aus 
Zeiten, als der Optimizer im Compiler noch nicht so gut war.

(prx) A. K. schrieb:
> Explizites Inlining steht im Standard erst mit C99 zur Verfügung.

Also seit 23 Jahren!

Teo D. schrieb:
> arum das in einem do-while Block gepackt wird?

Das ist ein elegantes Mittel, um das ;- oder }-Problem zu lösen.

Das define sieht aus wie ein Funktionsaufruf. Dahinter sollte im Code 
ein ; stehen.

enthält das #define ein ; oder } am Ende, dann bekommst Du durch Dein ; 
eine Warnung. Und Dinge wie

1

   ...

2

   if(y) 

3

       if(x<8) SetLEDs(x); 

4

       else    SetLEDs(0);

gehen schief ohne dass es auffällt (OK, würde man sagen, selber Schuld 
;-)

Enthält es keines, z.B.:

1

#define SetLEDs(mask) Portx=mask

dann kann der Compiler nicht warnen, wenn Du was abgefahrenes machst, 
z.B.:

1

   SetLEDs(0x18)+4;

2

   SetLEDs(mask)=0;

3

   SetLEDs(0x18)&1;

4

   SetLEDs(=0x18);

5

   void *p; p=&SetLEDs(0); /* komisch, ich muss für den Funktionspointer ein Argument angeben. Vermutlich ein Compiler-Bug, aber es compiliert so!!! */

c-hater schrieb:
> Und weiters bitte ich zu bedenken: fast alles, was unfähige
> C-Programmierer im Bereich Signalanlyse im Laufe der Jahre auf dem AVR8
> gebacken bekommen haben, basiert wiederum auf den FFT-Routinen von Elm
> Chan, der die einerseits auch wieder in Assembler verfaßt hat,
> andererseits aber wohl eindeutig C bevorzugt, wenn möglich.
> Sprich: es muß wohl doch was dran sein, dass man mit Asm deutlich
> effizienteren Code erzeugen kann als es ein C-Compiler könnte..


Das sind ganz spezielle Funktionen bei denen bestimmte Algorithmen 
möglichst effizient implementiert wurden. Was jedoch bei 99% der 
Anwendungen mittlerweile völliger Blödsinn ist, da blockiert dann vorher 
der Speicherdurchsatz usw.

Ein moderner C Compiler würde vermutlich ähnliche Aufrufe produzieren da 
diesem die meisten Algorithmen und die dazugehörigen Implementierungen 
je nach Architektur bekannt sein sollten.

Du versucht damit gerade Spezialfälle auf allgemeine Anwendungen zu 
übertragen. Und das kannst du bei heutiger Software vergessen.