Geteilt Rechnung vereinfachen in C

Simon X. schrieb:
> Gibt es
> eine vereinfachte form wie schieben oder so
Optimierung einschalten, den Rest erledigt der Optimizer

Den darf ich nicht einschalten, da es im Programm eine Stelle hat die 
genau so durchgeführt werden muss wie sie steht. Aber was gäbe es für 
eine schönere Schreibweise?

Simon X. schrieb:
> Jedoch wie ich weiss werden so viele
> rechenschritte benötigt um dies in meinem C code abzuarbeiten.

Die entscheidende Frage ist aber nicht, ob es viele sind, sondern ob es 
zuviel sind.
Für Ausgaben an den langsamen Menschen langweilt sich eine CPU dabei 
nur.

Simon X. schrieb:
> Den darf ich nicht einschalten, da es im Programm eine Stelle hat die
> genau so durchgeführt werden muss wie sie steht

Dann korrigiere diese Stelle entsprechend, das ist in 99% der Fälle 
möglich.

Welche Architektur ist es? Ist der Divisor fix oder zur Laufzeit 
variabel?

Auf was für einem Prozessor programmierst du? Manche ALUs können 
bestimmte Rechenoperationen optimiert ausführen (bei manchen DSPs z.B. 
sogar in einem Prozessortakt). Wenn du das gecheckt hast, schau mal nach 
Bitshiften...ein Einstieg gibts hier 
https://stackoverflow.com/questions/2776211/how-can-i-multiply-and-divide-using-only-bit-shifting-and-adding

Simon X. schrieb:
> Den darf ich nicht einschalten, da es im Programm eine Stelle hat die
> genau so durchgeführt werden muss wie sie steht.

"broken by design"

Nutze einen ATmega2560 bei 16MHz. mit dem ICE Atmel compiler. Der 
divisor ist so im Datenblatt vorgegeben. So versuche ich das Programm 
nur zu optimieren. Mit dem compiler möchte ich eigentlich nicht 
arbeiten. Ist für mich nur eine halbe Lösung zu dem Problem und nicht 
das Problem aus der Welt geschaffen.

Harry L. schrieb:
> Simon X. schrieb:
>> Den darf ich nicht einschalten, da es im Programm eine Stelle hat die
>> genau so durchgeführt werden muss wie sie steht.
>
> "broken by design"

Die Arbeit dem Compiler zu überlassen heisst für mich das man Faul ist 
und nicht. Aber verstehen ist was anderes. Es gibt tatsächlich stellen 
oder Rechenschritte die genau so erledigt werden müssen und nicht 
umgangen werden können.

Simon X. schrieb:
> mit dem ICE Atmel compiler.

Das ist ein Debugger.

Simon X. schrieb:
> Der
> divisor ist so im Datenblatt vorgegeben.

Wenn Divisor (aus dem Datenblatt) und Dividend (100000000) fix sind, 
wird die Berechnung sowieso immer zu einer fixen Zahl vorberechnet.

Simon X. schrieb:
> Mit dem compiler möchte ich eigentlich nicht
> arbeiten.
Ohne Compiler kannst du auf dem AVR wohl kaum C nutzen. Was meinst du 
wirklich?

Simon X. schrieb:
> Ist für mich nur eine halbe Lösung zu dem Problem und nicht
> das Problem aus der Welt geschaffen.
Meinst du den Optimierer? Den darf man ruhig ordentlich ausnutzen, dafür 
ist der da. Ohne Optimierung zur kompilieren ist angezogene Handbremse.

Simon X. schrieb:
> Die Arbeit dem Compiler zu überlassen heisst für mich das man Faul ist
> und nicht.
Das heißt dass man kompakten, lesbaren und wartbaren Code schreibt und 
die Details dem Computer überlässt. Das ist ökonomisch. Wenn man 
unbedingt alles selber machen will, macht man es in Assembler. Übrigens 
beschleunigt der Optimizer selbst die besten C-Programme noch; ohne 
Optimierung baut der Compiler immer unnötige Dinge ein.

Simon X. schrieb:
> Es gibt tatsächlich stellen
> oder Rechenschritte die genau so erledigt werden müssen und nicht
> umgangen werden können.
Wenn sie korrekt formuliert sind, wird da auch nichts umgangen und das 
genau so gemacht wie gewünscht. Präzisiere das mal, was "genau so" 
erledigt werden soll und was der Optimierer da kaputt machen könnte.

“The real problem is that programmers have spent far too much time 
worrying about efficiency in the wrong places and at the wrong times; 
premature optimization is the root of all evil (or at least most of it) 
in programming.” Donald Knuth

Simon X. schrieb:
> Den darf ich nicht einschalten, da es im Programm eine Stelle hat die
> genau so durchgeführt werden muss wie sie steht.

Kannst du uns bitte ein Beispiel geben, wo bei dir der Optimizer nicht 
aktiv werden darf?

Ansonsten kann man sehr bequem für Teile des Programms die Optimierung 
verbieten oder umschalten.

#pragma GCC push_options
#pragma GCC optimize ("O0")

hier dein kritischer Code

#pragma GCC pop_options

Georg G. schrieb:
> #pragma GCC push_options
> #pragma GCC optimize ("O0")
>
> hier dein kritischer Code
>
> #pragma GCC pop_options

wenn man das braucht, hat man mit sehr großer Wahrscheinlichkeit ein 
fehlerhaftes Programm.

Dummschwaetzer schrieb:
> oder der Compiler hat bugs

Die finden in der Regel nur Programmieranfänger. Ausnahmen hiervon sind 
extrem selten.

Woran mag das liegen?

Simon X. schrieb:
> Mit dem compiler möchte ich eigentlich nicht
> arbeiten. Ist für mich nur eine halbe Lösung zu dem Problem und nicht
> das Problem aus der Welt geschaffen.

Was, bitte, soll das nu heißen?? Du hast also einen C-Code, den du an 
einer Stelle optimieren möchtest - was das auch immer bedeuten soll und 
dann?
Gruß Rainer

c-hater schrieb:
> Völlig unbrauchbar ist C allerdings prinzipiell für alles, wo es nicht
> genügt, schnell genug zu sein, sondern eine (ggf. innerhalb bestimmter
> Grenzen) exakte Laufzeit erforderlich ist.
Es ist allerdings recht unwahrscheinlich dass der TE genau solch einen 
Fall vorliegen hat.

Es wurde immer noch nicht die Frage beantwortet, ob das Programm 
überhaupt zu langsam ist. Solange das nicht feststeht, ist eine 
Optimierung überflüssig wie ein Kropf.

Simon X. schrieb:
> Ich muss in meinem Programm 100000000/eine zahl rechnen. Dies
> funktioniert auch bestens. Jedoch wie ich weiss werden so viele
> rechenschritte benötigt um dies in meinem C code abzuarbeiten. Gibt es
> eine vereinfachte form wie schieben oder so. So währe dies ein wenig
> freundlicher vom code her.

Es gibt für die Version "Variable"/" Konstante" die Umformung in 
"Variable"*"andere Konstante">>"noch eine andere Konstante".
Das ganze nennt sich Barrett-Verfahren und wird vom GCC in der Tat 
vollautomatisch eingesetzt, sobald Optimierungen aktiv sind und es der 
Wertebereich erlaubt.

Für deine Problematik, d.h. "Konstante"/"Variable" existiert meines 
Wissens nach kein derartiges verfahren.

Peter D. schrieb:
> Solange das nicht feststeht, ist eine Optimierung überflüssig wie ein
> Kropf.

Unabhängig davon ist es aber auch recht sinnlos, den Compiler so 
einzustellen, dass er besonders ineffizienten Code produziert, um sich 
dann den Kopf darüber zu zerbrechen, wie man das von Hand wieder gerade 
biegen könnte.

Und dass …

Simon X. schrieb:
> es im Programm eine Stelle hat die genau so durchgeführt werden muss wie
> sie steht

… glaube ich nicht. So eine Aussage kommt eigentlich immer durch das 
fehlende Wissen, wie man es richtig macht.

Simon X. schrieb:
> da es im Programm eine Stelle hat die
> genau so durchgeführt werden muss wie sie steht.
Also der Optimizer/Compiler wird meines Wissens nicht etwas 
konstruieren, was andere Ergebnisse liefert als von dir per Code 
angestrebt. Mich dünkelt, dass du über sehr wenig Kenntnisse darüber 
verfügst und du dir selber im Wege stehst.

Ingo L. schrieb:
> Also der Optimizer/Compiler wird meines Wissens nicht etwas
> konstruieren, was andere Ergebnisse liefert als von dir per Code
> angestrebt.

Dazu muss der Code aber korrekt sein. Es gibt in C und C++ leider viele 
Möglichkeiten, (unbemerkt) fehlerhaften Code zu produzieren, welcher 
dann ggf. kaputt optimiert wird. Insbesondere bei Zugriffen auf 
Hardware-Register, bei denen Reihenfolge und Timing wichtig sind, bewegt 
man sich in einer Grauzone. Da aber IIRC die AVR hier relativ gutmütig 
sind sollten sich Lösungen finden lassen.
Es wäre praktisch, die fragliche Codestelle mal sehen zu können...

Simon X. schrieb:
> Es gibt tatsächlich stellen oder Rechenschritte die genau so erledigt
> werden müssen und nicht umgangen werden können.
Dann muss man die "Stellen" einfach so programmieren, dass sie immer 
das machen, was sie tun sollen. Mit Optimierung halt schneller...

Wenn ich Code habe, der ohne Optimierung läuft und mit Optimierung nicht 
mehr, dann weiß ich, dass der Code noch einen Fehler enthält.

Ich glaube ich habe es verstanden. Der Fragesteller möchten bespasst 
werden. Irgendwas soll passieren, damit irgendwas anders wird. Kein 
Problem, dann machen wir das.

De actio juméntis insipiéntibus schlage ich eine Zerlegung in einen 
Kettenbruch vor. Das ist ein bisschen altmodisch (schon Euler hat ...) 
aber kann man mal machen. Die Mathematik ist ein bisschen aufwendiger, 
aber es gibt ein klassisches Lehrbuch online: 
https://archive.org/download/dielehrevondenk00perrgoog/dielehrevondenk00perrgoog.pdf

Ob mit oder ohne Compileroptimierung, die Division dauert immer gleich 
lang. Es wird immer die gleiche Lib aufgerufen.

Man kann zur Optimierung aber auch float statt long nehmen. Float 
berechnet nur 24 Bit und ist daher schneller.

Hannes J. schrieb:
> schlage ich eine Zerlegung in einen Kettenbruch

Ich werfe mal Subtraktion und Addition in einer Schleife ins Forum. 
Division ist wiederholte Subtraktion, also kann man das auch so 
hinschreiben.

Hannes J. schrieb:
> Ich glaube ich habe es verstanden. Der Fragesteller möchten bespasst
> werden.

Das glaube ich mittlerweile auch! Und wenn man nicht weiss, wie groß die 
zweite Zahl sein wird, dann bleibt doch nur eine Float-Division. Auch 
wenn ich - wie gesagt- keine große Ahnung in "C" habe, so scheint es mir 
doch völlig unsinnig, in einer Hochsprache eine Rechenoperation "zu 
Fuss" selbst zu schreiben...
Und noch einmal meine Frage: der TO hat ein C-Programm, möchte aber 
keinen Compiler benutzen! Also was denn dann!!!
Gruß Rainer

Fritz B. schrieb:
> S. R. schrieb:
>> Division ist wiederholte Subtraktion, also kann man das auch so
>> hinschreiben.
>
> Angenommen, die fragliche Zahl wäre die 341256. Jetzt schreib mal die
> Aufgabe 100000000/341256(*) als Subtraktionen hin. Ich wüßte nicht, wie
> ich das anstellen soll. Aber wenn du das so einfach findest, schreib mal
> bitte auf, wie du das machen würdest.
Hast du im Fach Informatik in der Uni gepennt?
Das was jz23 da aufgeschrieben hat, ist eines der ersten Dinge die man 
lernt wwenn es darum geht ein wenig davon zu verstehen was unter der 
haube von Programmiersprachen geschieht :)

Alex G. schrieb:
> Das was jz23 da aufgeschrieben hat, ist eines der ersten Dinge die man
> lernt wwenn es darum geht ein wenig davon zu verstehen was unter der
> haube von Programmiersprachen geschieht :)

Und das weiß sogar ich, der nie Informatik studiert hat. :-)

Kaj schrieb:
> Wenn man den Compiler mit Mist fuettert kann man nicht erwarten das
> Rosen dabei raus kommen.

Oder kurz: Shit in - shit out.

oder "Input-Korn, PutPut-Huhn, Output-Ei"...

Leute, das ist nicht mehr wirklich witzig.
Ihr tut so als ob der TE aus Dummheit dieses Problem hätte und als ob 
ihr alle immer perfekten code schreiben würdet (und das vorallem schon 
seit eurer ersten Bekanntschaft mit einer Tastatur) >_>
Wart ihr nie in der Situation einmal sehr froh gewesen zu sein dass der 
code überhaupt lief. Egal wie?
Optimierungen auszuschalten ist da noch bei weitem das angenehmste.

Wenn ihr den TE nicht vollends verschreckt habt, beschreibt er aber 
vieleicht die betreffende code Stelle und man kann wieder was sinnvolles 
in diesen Thread schreiben.

Peter D. schrieb:
> Es wurde immer noch nicht die Frage beantwortet, ob das Programm
> überhaupt zu langsam ist.

Und die 2. Frage ist, falls es zu langsam ist, ob dann überhaupt die 
Division der schuldige ist.

Ich hab da schon Sachen erlebt. Z.B. daß jemand für eine 
Multiplexanzeige jedesmal neu die Zahl komplett in Ziffern zerlegt, um 
dann davon ein Digit auszugeben.
Wer Rechnungen unnötig oft ausführt, darf sich nicht wundern, wenn dann 
wichtige Sachen zu langsam werden.

Alex G. schrieb:
> Optimierungen auszuschalten ist da noch bei weitem das angenehmste.

Aber böse geschummelt. Es ist schon sinnvoll direkt zu lernen wie es 
richtig geht. Sonst gibt's bald ein böses Erwachen... Dazu kann man ja 
auch fragen wo genau das Problem liegt, wenn man es eingegrenzt hat.

Alex G. schrieb:
> Wenn ihr den TE nicht vollends verschreckt habt, beschreibt er aber
> vieleicht die betreffende code Stelle und man kann wieder was sinnvolles
> in diesen Thread schreiben.
Macht er ja leider nicht :-/