Wieviele Taktzyklen benötigt ein Befehl in C

[nosico (Gast)]

Hallo Leute!

Ich suche verzweifelt eine Auflistung, wieviele Taktzyklen jeder C 
Befehl benötigt, finde aber leider keine und kann mir auch nicht 
wirklich vorstellen, dass es soetwas überhaupt nicht gibt :(

Vielen Dank im Voraus, nosico

[Karl H. (kbuchegg)]

nosico wrote:
> Hallo Leute!
>
> Ich suche verzweifelt eine Auflistung, wieviele Taktzyklen jeder C
> Befehl benötigt, finde aber leider keine und kann mir auch nicht
> wirklich vorstellen, dass es soetwas überhaupt nicht gibt :(

Du solltest dich an den Gedanken gewöhnen.
Wieviele Taktzyklen ein Befehl in C tatsächlich benötigt, hängt
davon ab, wie der Compiler den Befehl umsetzt (von Compiler
zu Compiler verschieden), sowie, und das ist viel wichtiger,
wie der Compiler eine etwaige Optimierung damit macht.
Im Extremfall kann ein Compiler ganze Befehlsketten komplett
aus deinem Programm herausoptimieren, sodass sie effektiv
0 Taktzyklen benötigen.

Wenn man tatsächlich zyklengenau programmieren muss, was sehr
selten vorkommt, dann führt an Assembler kein Weg vorbei.

[Frank (Gast)]

Lerne lieber, dir das vorzustellen. Wieviele Taktzyklen braucht wohl ein 
schnödes

a=b;

?
Oder gar ein

while(1);

?
Es gibt also keine eindeutigen Antwort, was ein Befehl in C braucht. 
Architekturunterschiede und Compiler erledigen den Rest.

[nosico (Gast)]

So eine Antwort habe ich ja befürchtet, aber die habe die Hoffnung halt 
nicht aufgegeben ;)

Gibt es nicht einmal eine Auflistung von der Umwandlung im AVR-GCC ohne 
Optimierung? Soetwas würde mir ja auch schon weiterhelfen...

[Karl H. (kbuchegg)]

nosico wrote:
> Gibt es nicht einmal eine Auflistung von der Umwandlung im AVR-GCC ohne
> Optimierung? Soetwas würde mir ja auch schon weiterhelfen...

Wobei würde dir das weiterhelfen?
In den meisten Fällen ist die Notwendigkeit der Kentniss der
Taktzyklen in Indiz dafür, dass
* ein falscher Algorithmus gewählt wurde
* Der Programmierer mit seinen bescheidenen Kenntnissen versucht
  besser zu sein als der Compiler und versucht händisch zu optimieren
  (was meist schief geht).
  Im gcc gibt es ein paar Bereiche in denen der Compiler tatsächlich
  nicht besonders gut optimiert (speziell wenn es um Berechnungen
  mit reinen 8-Bit Variablen geht, da kommen dem gcc manchmal die
  C alles_wird_in_int_gerechnet-Regel in die Quere) aber in den
  meisten Fällen muss man schon sehr gut in Assembler sein, um den
  Compiler zu schlagen.

Ansonsten gilt die Regel:
Schreibe dein Programm zuerst mal so, dass es funktioniert.
Klarheit geht dabei vor 'Cleverheit'.
Wenn es dann zu langsam ist, versuche rauszufinden, wo die
Rechenzeit verbraten wird und setzte dort den Optimierungshebel
an. Aber nicht dadurch optimieren, indem an low level Operationen
herumgefrickelt wird, das kann der Compiler nämlich besser. Sondern
sieh nach ob es systematische Optimierungen im verwendeten Algorithmus
gibt oder ob nicht ein anderer Algorithmus besser geeignet wäre.

Natürlich gibt es auch Ausnahmen:
Wenn man ein Videosignal erzeugen muss, dann muss das taktgenau sein.
Da kommt man aber mit C nicht weiter und muss auf Assembler ausweichen.

[nosico (Gast)]

Es geht mir ja genauso so wie Du geschrieben hast, zuerst wurde ein Code 
erzeugt, der einmal funktioniert und jetzt muss dieser Algorithmus 
optimiert werden, damit weitere Module angehängt werden können. In 
diesem konkreten Projekte geht es zufällig auch wirklich um eine 
Datenaufbereitung für ein Videosignal und genau für die die 
Algoritmus-Optimierung würde mir eine entsprechende Liste gewaltig 
weiterhelfen, da somit eine Abschätzung einfacher zum Durchführen ist, 
da natürlich ein dermaßen komplexer Algorithmus sehr schwer zum 
durchblicken ist

[Karl H. (kbuchegg)]

nosico wrote:
> Algoritmus-Optimierung würde mir eine entsprechende Liste gewaltig
> weiterhelfen,

es gibt keine, weil es nicht nur vom Befehl selbst abhängt
wie er umgesetzt wird sondern auch von der 'Programm-Umgebung',
in der er eingestzt wird.

> da somit eine Abschätzung einfacher zum Durchführen ist,
> da natürlich ein dermaßen komplexer Algorithmus sehr schwer zum
> durchblicken ist

Wie gesagt: die Low Level Dinge überlasse getrost dem Compiler,
der kann das besser und holt das Optimum heraus. Deine Aufgabe
ist es, auf High Level Dingen nach Optimierungsmöglichkeiten
zu suchen.

[nosico (Gast)]

ok, verstanden ;) thx nosico

[Uwe .. (uwegw)]

Schau dir die vom Compiler erzeugt .lss-Datei an. Darin kann man genau 
sehen, was der Compiler aus jeden Befehl gemacht hat.

[Rolf Magnus (Gast)]

> Oder gar ein
> while(1);

Dessen Verbrauch an Taktzyklen läßt sich recht genau ermitteln.

[Andreas K. (a-k)]

> Dessen Verbrauch an Taktzyklen läßt sich recht genau ermitteln.

Findest du? Wie gross ist denn die MTBF, in Takten?

[Michael G. (linuxgeek)]

> Wenn man tatsächlich zyklengenau programmieren muss, was sehr
> selten vorkommt, dann führt an Assembler kein Weg vorbei.

Und selbst das kannste bei moderneren CPUs mit Pipelining und CISC-Kern 
mal getrost vergessen. Ich hatte mal nen Listing fuer nen 8088 hehe...

[Rolf Magnus (Gast)]

>> Dessen Verbrauch an Taktzyklen läßt sich recht genau ermitteln.
>
> Findest du?

Einfach einen Zähler parallel zum Takteingang des Prozessors hängen und 
vor der Schleife diesen Zähler resetten. Nachdem die CPU abgeschaltet 
ist, den Zähler auslesen ;-)

> Wie gross ist denn die MTBF, in Takten?

Kommt auf die Taktfrequenz an :)

[Christian U. (z0m3ie)]

>Kommt auf die Taktfrequenz an :)

Versteh ich was falsch oder ist ein Takt jetzt nicht mehr 
Taktfrequenzunabhängig ?

[Andreas K. (a-k)]

> Versteh ich was falsch oder ist ein Takt jetzt nicht mehr
> Taktfrequenzunabhängig ?

Der Takt nicht, aber deren Anzahl bis zum Tod schon. Übertakter können 
davon ein Lied singen.

[Rolf Magnus (Gast)]

Außerdem wird die MTBF in der Regel in Stunden angegeben. Wenn man das 
in Takte umrechnen will, braucht man die Taktfrequenz.

[Malte _. (malte)]

Also beim gcc kannst du mit 'make Deindateiname.s' dir ein 
Assemblerlisting zur Datei Deintdateiname.c generieren. Aus der 
erzeugten Deindateiname.s  suchst du dir die passende Stelle, meist sind 
die Zeilennummern und Funktionsnamen des C-codes als Kommentar 
angegeben. Dann darfst du anfangen zu zählen ;-). Wie viele Takte ein 
einzelner Befehl dauert steht beim AVR Datenblatt, das ist aber nicht 
bei allen Architekturen immer eine feste Menge.
Natürlich kann die Sache wie oben schon beschrieben wieder ein paar 
Haken haben:
1. Der Compiler optimiert es weg und du findest keine Code.
2. Der erzeugte Code ist von der Compiler Version und den 
Optimierungsstufen abhängig.
3. Der Code verwendet Unterfunktionen aus der Bibliothek, bei dem du 
dann erstmal nicht weißt wie lange er braucht.
4. Je nach Ausgangssituation braucht der Code unterschiedlich viele 
Zyklen.