Wie schreibe im in C einen längeren Ausdruck zum Quadrat?
(X - X_mitte)^2 funktioniert natürlich nicht, das ^ Zeichen ist
für bitweises Xor reserviert. Gibt es da nur pow((x - x_mitte),2); ?
Blähboy schrieb:> Wie schreibe im in C einen längeren Ausdruck zum Quadrat?> (X - X_mitte)^2 funktioniert natürlich nicht, das ^ Zeichen ist> für bitweises Xor reserviert. Gibt es da nur pow((x - x_mitte),2); ?
Ja, es gibt IMO keinen Operator dafür.
Blähboy schrieb:> Wie schreibe im in C einen längeren Ausdruck zum Quadrat?
Indem du diesen Term einmal berechnest, in eine Variable stopfst und
dann diese mit sich selbst multiplizierst.
In was für einem Kindergarten sind wir denn hier???
W.S.
Fritz Kuckuck schrieb im Beitrag #6173046:
> W.S. schrieb:>> In was für einem Kindergarten sind wir denn hier???>>>> W.S.>> Gereizte Leute viel ich find!> Doch wo sind die, die reizend sind?
Und ich finde das war noch diplomatisch ausgedrückt.
Armin W. schrieb:> #define TERM (X - X_mitte)>> TERM*TERM
och nö bitte nicht, man muss nicht jeden Kack mit dem Präprozessor
hinmurksen. Es gibt genug andere Möglichkeiten.
sid schrieb:> wassn aus *math.h* geworden?> pow(x,2) 'd die nichtmehr in C?
Frage nicht gelesen/verstanden? Der TE hat doch gefragt ob es da noch
was anderes gibt außer pow() ;)
Dirk B. schrieb:> Sven B. schrieb:>> pow(x, 2) ist viel langsamer als x*x>> Ja.> Das weiß auch der Compiler und optimiert das, wenn er darf.
Hast du mal ein Beispiel für einen Compiler, der pow(x, 2) in x*x
optimiert für x double? Ich kenne keinen der das tut.
Sven B. schrieb:> Dirk B. schrieb:>> Sven B. schrieb:>>> pow(x, 2) ist viel langsamer als x*x>>>> Ja.>> Das weiß auch der Compiler und optimiert das, wenn er darf.>> Hast du mal ein Beispiel für einen Compiler, der pow(x, 2) in x*x> optimiert für x double? Ich kenne keinen der das tut.
Tim T. schrieb:> das ist ja schon wieder irgendwie traurig...
Was ist daran traurig? Beachte das "volatile" im C-Source. Das wurde
wohl gemacht, damit der Compiler nicht direkt selbst das Ergebnis
ausrechnet.
Allein schon beim Weglassen des volatile bei x
1
#include<math.h>
2
3
intmain(void)
4
{
5
doublex=42.0;
6
7
volatiledoubley1=x*x;
8
volatiledoubley2=pow(x,2);
9
}
wird nicht mehr multiplipliziert, sondern direkt das Ergebnis in y1 und
y2 gespeichert:
1
movsd xmm0, QWORD PTR .LC0[rip]
2
xor eax, eax
3
movsd QWORD PTR [rsp-16], xmm0
4
movsd QWORD PTR [rsp-8], xmm0
5
ret
6
.LC0:
7
.long 0
8
.long 1083936768
Über das Weglassen des "volatile" bei y1 und y2 brauchen wir erst gar
nicht zu reden. da verschwindet natürlich alles.
Frank M. schrieb:> Tim T. schrieb:>> das ist ja schon wieder irgendwie traurig...>> Was ist daran traurig? Beachte das "volatile" im C-Source. Das wurde> wohl gemacht, damit der Compiler nicht direkt selbst das Ergebnis> ausrechnet.
Das traurige ist das der gcc nicht erkennt das er einfach ein
1
movsd xmm0, QWORD PTR [rsp-24]
2
mulsd xmm0, xmm0
oder auch ein
1
movsd xmm0, QWORD PTR [rsp-24]
2
mulsd xmm0, QWORD PTR [rsp-24]
machen könnte und stattdessen zwei Register lädt...
Udo K. schrieb:> Macht der doch? Jedenfalls wenn man das idiotische volatile> weglaesst...
Der Grund fürs volatile wurde ja schon oben angeführt, die Frage ist,
warum macht er es bei volatile nicht?
Tim T. schrieb:> Der Grund fürs volatile wurde ja schon oben angeführt,> die Frage ist, warum macht er es bei volatile nicht?
Weil er es nicht darf. Wenn eine Variable "volatile" ist, dann ist sie
bei jedem Zugriff neu zu lesen, sie könnte sich ja geändert haben.
S. R. schrieb:> Tim T. schrieb:>> Der Grund fürs volatile wurde ja schon oben angeführt,>> die Frage ist, warum macht er es bei volatile nicht?>> Weil er es nicht darf. Wenn eine Variable "volatile" ist, dann ist sie> bei jedem Zugriff neu zu lesen, sie könnte sich ja geändert haben.
Seufz:
1
movsd xmm0, QWORD PTR [rsp-24]
2
movsd xmm1, QWORD PTR [rsp-24]
3
mulsd xmm0, xmm1
soll also besser sein als:
1
movsd xmm0, QWORD PTR [rsp-24]
2
mulsd xmm0, QWORD PTR [rsp-24]
Nope. Sobald du eine 2 Register Operation wie z.B. mul durchführst, geht
das gar nicht anders als sich darauf zu verlassen das der Wert
zwischenzeitlich nicht verändert wurde.
Abgesehen davon bekommt Clang das hin...
Ich gehe weiter und behaupte das ist schlicht undefiniertes Verhalten:
1
volatile double x = 42.0;
2
volatile double y1 = x * x;
1) Da x als volatile ausgewiesen ist, müssen beide Multiplikatoren
individuell ausgewertet werden (C11 5.1.2.3 6)
2) Die genannten Auswertungen sind unsequenced (C11 6.5 3)
3) Zugriff auf eine volatile Variable ist ein side effect (C11
5.1.2.3 2)
4) unsequenced side effects, die die gleiche Variable betreffen, sind
undefiniertes Verhalten (C11 6.5 2)
Fazit: Finger weg von volatile
Tim T. schrieb:> Hmm,> movsd xmm0, QWORD PTR [rsp-24]> movsd xmm1, QWORD PTR [rsp-24]> mulsd xmm0, xmm1>> das ist ja schon wieder irgendwie traurig...
Was genau mach dich traurig daran? Ich hätte das "volatile" auch
weglassen können, aber dann hätte der Compiler gleich 1764 daraus
gemacht...
Tim T. schrieb:> Frank M. schrieb:>> Tim T. schrieb:>>> das ist ja schon wieder irgendwie traurig...>>>> Was ist daran traurig? Beachte das "volatile" im C-Source. Das wurde>> wohl gemacht, damit der Compiler nicht direkt selbst das Ergebnis>> ausrechnet.>> Das traurige ist das der gcc nicht erkennt das er einfach ein> movsd xmm0, QWORD PTR [rsp-24]> mulsd xmm0, xmm0>> oder auch ein> movsd xmm0, QWORD PTR [rsp-24]> mulsd xmm0, QWORD PTR [rsp-24]>> machen könnte und stattdessen zwei Register lädt...
Natürlich erkennt er es. Du verstehst nur nicht, was "volatile" macht.
Udo K. schrieb:> Macht der doch? Jedenfalls wenn man das idiotische volatile> weglaesst...
Was genau ist deiner Meinung nach idiotisch daran? Ohne "volatile" hätte
der Compiler das Ergebnis gleich selbst ausgerechnet, eher ungeeignet,
wenn man das Verhalten von pow() demonstriere will.
Hätte ich das "volatile" bei y1 und y2 auch weggelassen, hätte der
Compiler gemerkt dass das Ergebnis eh nicht verwendet wird, und die
ganze Rechnung rausgeworfen.
Tim T. schrieb:> die Frage ist,> warum macht er es bei volatile nicht?
Lies ein C-Buch.
Jemand schrieb:> Fazit: Finger weg von volatile
Aber ohne volatile funktioniert das Beispiel halt nicht.
1
#include<math.h>
2
3
intmain(void)
4
{
5
doublex=42.0;
6
7
volatiledoubley1=x*x;
8
volatiledoubley2=pow(x,2);
9
}
wird optimiert zu
1
main:
2
movsd xmm0, QWORD PTR .LC0[rip]
3
xor eax, eax
4
movsd QWORD PTR [rsp-16], xmm0
5
movsd QWORD PTR [rsp-8], xmm0
6
ret
7
.LC0:
8
.long 0
9
.long 1083936768
1
#include<math.h>
2
3
intmain(void)
4
{
5
doublex=42.0;
6
7
doubley1=x*x;
8
doubley2=pow(x,2);
9
}
wird gar zu
1
main:
2
xor eax, eax
3
ret
Toll, wenn es darum geht in einem echten Programm unnötige
Rechenoperationen einzusparen, aber eher schlecht, wenn man
demonstrieren will, zu was pow(x, 2) im ungünstigen Fall kompiliert.
vn nn schrieb:> Toll, wenn es darum geht in einem echten Programm unnötige> Rechenoperationen einzusparen, aber eher schlecht, wenn man> demonstrieren will, zu was pow(x, 2) im ungünstigen Fall kompiliert.
wenn Du nachvollziehen willst, zu was pow(x, 2) compiliert wird,
schreib' eine Funktion und compiliere die mit -c und schau' dir an, was
der Compiler daraus macht.
1
intisquare(inti)
2
{
3
returnpow(i,2);
4
}
Da wird nix wegoptimiert. Die Übung überlasse ich dir.
Allerdings wurde ein "Haken" noch nicht diskutiert, der insbesondere in
einer µC-Umgebung relevant sein kann:
gcc (zumindest, clang weiß ich nicht) macht die 'pow()'-Optimierung nur,
wenn man nicht mit -ffreestanding übersetzt (was ja in einer
µC-Umgebung durchaus eher mal der Fall ist).
vn nn schrieb:> Was genau mach dich traurig daran? Ich hätte das "volatile" auch> weglassen können, aber dann hätte der Compiler gleich 1764 daraus> gemacht...
Herr, schmeiß Hirn vom Himmel. Das ist absolut klar, darum muss ja das
volatile da hin damit der Compiler nicht direkt das vorausberechnete
Ergebnis einträgt.
> Natürlich erkennt er es. Du verstehst nur nicht, was "volatile" macht.
Ich bin mir absolut sicher das ich das deutlich besser verstehe als du,
nur es macht einfach keinen Sinn diese Optimierung nicht zu machen, da
sich ausserhalb der Sequenz für die Variable nichts dadurch ändert.
> Tim T. schrieb:>> die Frage ist,>> warum macht er es bei volatile nicht?>> Lies ein C-Buch.
Ob du es glaubst oder nicht, ich hab eins gelesen, genauer gesagt waren
es einige, dazu noch Compilerbau, Rechnerarchitektur usw. Außerdem hab
ich Assembler und Compiler für eigene CPU Architekturen gebaut und unter
anderem Clang und GCC auf diese Architekturen portiert. Achja,
irgendwann hab ich auch mal ein Studium in Elektrotechnik Fachrichtung
Informationstechnologie (Mischung aus E-Technik und Informatik)
abgeschlossen, wobei das mittlerweile auch schon ein paar Jahre her ist.
Aber um dich nicht zu überfordern stelle ich die Frage mal neu:
"Warum meint der GCC das er
1
movsd xmm0, QWORD PTR [rsp-24]
2
mulsd xmm0, QWORD PTR [rsp-24]
NICHT zwischen zwei Sequenzpunkte bekommt,
1
movsd xmm0, QWORD PTR [rsp-24]
2
movsd xmm1, QWORD PTR [rsp-24]
3
mulsd xmm0, xmm1
aber schon?"
Und der Vollständigkeit halber:
1
intmain(void)
2
{
3
volatiledoublex=42.0;
4
volatiledoubley1=x*x;
5
}
wird beim GCC mit -O3 zu:
1
main:
2
movsd xmm0, QWORD PTR .LC0[rip]
3
xor eax, eax
4
movsd QWORD PTR [rsp-16], xmm0
5
movsd xmm0, QWORD PTR [rsp-16]
6
movsd xmm1, QWORD PTR [rsp-16]
7
mulsd xmm0, xmm1
8
movsd QWORD PTR [rsp-8], xmm0
9
ret
10
.LC0:
11
.long 0
12
.long 1078263808
und bei CLang mit -O3 (genauer sobald irgendeine Optimierung
angeschaltet ist) zu:
Markus F. schrieb:> vn nn schrieb:>> Toll, wenn es darum geht in einem echten Programm unnötige>> Rechenoperationen einzusparen, aber eher schlecht, wenn man>> demonstrieren will, zu was pow(x, 2) im ungünstigen Fall kompiliert.>> wenn Du nachvollziehen willst, zu was pow(x, 2) compiliert wird,> schreib' eine Funktion und compiliere die mit -c und schau' dir an, was> der Compiler daraus macht.> int isquare(int i)> {> return pow(i, 2);> }>> Da wird nix wegoptimiert. Die Übung überlasse ich dir.
Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht
einfach sagen kann "kompilier halt mit -c". Und ob er das bereits tut,
hatte ich einfach keine Lust auszuprobieren.
Aber da du scheinbar zum Thema ja nix sinnvolles beizutragen hast, musst
du dich halt jetzt auf ein "volatile" versteifen. Traurig.
Markus F. schrieb:> gcc (zumindest, clang weiß ich nicht) macht die 'pow()'-Optimierung nur,> wenn man nicht mit -ffreestanding übersetzt (was ja in einer> µC-Umgebung durchaus eher mal der Fall ist).
War ja keine Zielplattform gefragt.
Tim T. schrieb:>> Natürlich erkennt er es. Du verstehst nur nicht, was "volatile" macht.>> Ich bin mir absolut sicher das ich das deutlich besser verstehe als du,> nur es macht einfach keinen Sinn diese Optimierung nicht zu machen, da> sich ausserhalb der Sequenz für die Variable nichts dadurch ändert.
Leider macht dein Posting absoult keinen Sinn. Was genau meinst du zu
verstehen, und welche Optimierung ist unabdingbar? Dir ist schon klar,
dass die Oprimierung "trag einfach mal statisch 1764 ein" zwar auf einem
realen System sinnvoll sein mag, nicht aber wenn man etwas demonstrieren
will?
Tim T. schrieb:> Ob du es glaubst oder nicht, ich hab eins gelesen, genauer gesagt waren> es einige, dazu noch Compilerbau, Rechnerarchitektur usw. Außerdem hab> ich Assembler und Compiler für eigene CPU Architekturen gebaut und unter> anderem Clang und GCC auf diese Architekturen portiert. Achja,> irgendwann hab ich auch mal ein Studium in Elektrotechnik Fachrichtung> Informationstechnologie (Mischung aus E-Technik und Informatik)> abgeschlossen, wobei das mittlerweile auch schon ein paar Jahre her ist.
Und trotzdem ist dir nicht klar, warum ein volatile an der Stelle nicht
zu vereinbaren ist mit
Tim T. schrieb:> Das traurige ist das der gcc nicht erkennt das er einfach ein> movsd xmm0, QWORD PTR [rsp-24]> mulsd xmm0, xmm0>> [...]>> machen könnte und stattdessen zwei Register lädt...
?
Interessant.
Tim T. schrieb:> Aber um dich nicht zu überfordern stelle ich die Frage mal neu:>> "Warum meint der GCC das ermovsd xmm0, QWORD PTR [rsp-24]> mulsd xmm0, QWORD PTR [rsp-24]> NICHT zwischen zwei Sequenzpunkte bekommt,movsd xmm0, QWORD PTR> [rsp-24]> movsd xmm1, QWORD PTR [rsp-24]> mulsd xmm0, xmm1> aber schon?"
Interessant, wie du deine "Frage" nun geringfügig abänderst, die Stelle,
auf die ich mich bezog entfernst, um deinen Fehler zu vertuschen.
Natürlich nur "um mich nicht zu überfordern". Nicht, um durch
Unflätigkeiten von deinen Fehlern abzulenken.
vn nn schrieb:> Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht> einfach sagen kann "kompilier halt mit -c".
Was hindert dich denn daran?
vn nn schrieb:> Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht> einfach sagen kann "kompilier halt mit -c".
dann solltest Du das vielleicht mal probieren (so hättest Du dann
wenigstens irgendwas dazugelernt). Abgesehen davon hätte ich naiv
angenommen, daß jemand, der zu einer C-Frage den dicken Max macht,
vielleicht eventuell tatsächlich einen eigenen Compiler hat?
vn nn schrieb:> War ja keine Zielplattform gefragt.
Wie heisst das Forum hier gleich noch mal?
Also mir ist es jetzt einfach zu doof weiter darauf einzugehen. Der
Spezialist will es einfach nicht verstehen und ich hab sinnvolleres zu
tun als mich mit einem Troll auseinander zusetzen. Für mich ist hier
demnach EOD.
Dem Rest noch einen schönen Abend.
Tim T. schrieb:> Seufz:> movsd xmm0, QWORD PTR [rsp-24]> movsd xmm1, QWORD PTR [rsp-24]> mulsd xmm0, xmm1>> soll also besser sein als:> movsd xmm0, QWORD PTR [rsp-24]> mulsd xmm0, QWORD PTR [rsp-24]
Nein. Du hast keine Ahnung.
Du erwartest, dass im ersten Fall immer xmm0 == xmm1 gilt.
Das ist für volatile nicht garantiert, und der Compiler darf sich
nicht darauf verlassen. Wenn die Adresse nämlich eine MMIO-Adresse
ist, dann haben Lesevorgänge möglicherweise Nebeneffekte.
> Nope. Sobald du eine 2 Register Operation wie z.B. mul durchführst, geht> das gar nicht anders als sich darauf zu verlassen das der Wert> zwischenzeitlich nicht verändert wurde.
Du hast keine Ahnung. Der Wert der Variablen kann sich ändern. Wenn da
2x "lies X aus dem Speicher" steht, dann muss der Compiler auch 2x X aus
dem Speicher lesen, und er darf nicht annehmen, dass er 2x das gleiche
gelesen hat.
> Abgesehen davon bekommt Clang das hin...
Betrachte ich erstmal als Bug.
S. R. schrieb:> Tim T. schrieb:>> Seufz:>> movsd xmm0, QWORD PTR [rsp-24]>> movsd xmm1, QWORD PTR [rsp-24]>> mulsd xmm0, xmm1>>>> soll also besser sein als:>> movsd xmm0, QWORD PTR [rsp-24]>> mulsd xmm0, QWORD PTR [rsp-24]>> Nein. Du hast keine Ahnung.
Wenn du das sagst, wird das wohl deine Meinung sein.
> Du erwartest, dass im ersten Fall immer xmm0 == xmm1 gilt.> Das ist für volatile nicht garantiert, und der Compiler darf sich> nicht darauf verlassen. Wenn die Adresse nämlich eine MMIO-Adresse> ist, dann haben Lesevorgänge möglicherweise Nebeneffekte.
Brauch er auch nicht, wenn du einfach mal scharf hinschauen würdest,
wird im zweiten Fall ebenfalls eine zweiter Lesezugriff auf die Adresse
durchgeführt, nur werden die Daten nicht überflüssigerweise in einem
Register zwischengelagert sondern direkt verwurstet.
>> Nope. Sobald du eine 2 Register Operation wie z.B. mul durchführst, geht>> das gar nicht anders als sich darauf zu verlassen das der Wert>> zwischenzeitlich nicht verändert wurde.>> Du hast keine Ahnung. Der Wert der Variablen kann sich ändern. Wenn da> 2x "lies X aus dem Speicher" steht, dann muss der Compiler auch 2x X aus> dem Speicher lesen, und er darf nicht annehmen, dass er 2x das gleiche> gelesen hat.
Auch das hast du nicht verstanden, du MUSST einen Operanden vorab in ein
Register laden und dich dann darauf verlassen dass der zweite Operand in
der Zwischenzeit nicht verändert wurde. Im konkreten Beispiel eben dass
an der Adresse von x immer noch der Wert 42 drin steht, ansonsten
könntest du gar keine Multiplikation durchführen. Sowohl im ersten als
auch im zweiten Codestück ist das der Fall. Was nur hinzukommt ist das
der Codeabschnitt in eine Sequenz gepackt wird und so sicherstellt das
allgemein keine Änderungen an den volatilen Variablen vorgenommen wird.
>> Abgesehen davon bekommt Clang das hin...>> Betrachte ich erstmal als Bug.
Auch das wird deine Meinung sein.
So, nun ist aber wirklich Schluss für mich, hab nur noch geantwortet
weil du dir die Mühe gemacht hast eine Antwort zu basteln und dabei so
kräftig vor die Wand gelaufen bist das ich Mitleid hatte.
Ich bitte die Beteiligten, mal wieder runterzukommen.
Letztendlich ging es nicht um die Frage, ob und wie volatile wirkt,
sondern ob pow(x, 2) zu x² vom Compiler optimiert werden kann.
Also:
1
#include<math.h>
2
3
doublemysquare(doublex)
4
{
5
returnx*x;
6
}
7
8
doublemypow2(doublex)
9
{
10
returnpow(x,2);
11
}
wird zu:
1
mysquare: # @mysquare
2
mulsd xmm0, xmm0
3
ret
4
mypow2: # @mypow2
5
mulsd xmm0, xmm0
6
ret
gcc und clang liefern hier übrigens dasselbe Ergebnis.
Ich denke, damit ist die Frage hinreichend beantwortet und ein jeder
kann sich nun wieder wichtigeren Dingen zuwenden.
Nur mal so aus Neugierde, wer quadriert hier eigentlich auf kleinen
Mikrocontrollern doubles? Da möchte ich mal ne Anwendung sehen, die das
braucht außer vielleicht nem Sextanten. Und dann nehm ich halt einen
potenteren µC und überlasse das Optimieren der Toolchain. Um die paar
Cents in Serienfertigung kanns wohl kaum gehen?
Tim T. schrieb:> Brauch er auch nicht, wenn du einfach mal scharf hinschauen würdest,> wird im zweiten Fall ebenfalls eine zweiter Lesezugriff auf die Adresse> durchgeführt, nur werden die Daten nicht überflüssigerweise in einem> Register zwischengelagert sondern direkt verwurstet.
LLVM hat ein Tool womit man die Performancecharakteristik von Kompilaten
statisch bewerten kann: llvm-mca. Einen krassen Unterschied sehe ich
zwischen den Versionen damit nicht.
Carsten schrieb:> Nur mal so aus Neugierde, wer quadriert hier eigentlich auf> kleinen> Mikrocontrollern doubles? Da möchte ich mal ne Anwendung sehen, die das> braucht außer vielleicht nem Sextanten. Und dann nehm ich halt einen> potenteren µC und überlasse das Optimieren der Toolchain. Um die paar> Cents in Serienfertigung kanns wohl kaum gehen?
Sensordaten auswerten? Ich habe neulich was gebaut was den
Brechungsindex der Luft aus diversen Sensor-Inputs ausrechnet und meine
mich zu erinnern dass das mit floats relativ knapp wurde von der
Genauigkeit her. Die Rechnung hat leicht mal > 7 signifikante Stellen,
obwohl alle Inputs nicht hochpräzise sind.
Tim T. schrieb:> So, nun ist aber wirklich Schluss für mich, hab nur noch geantwortet> weil du dir die Mühe gemacht hast eine Antwort zu basteln und dabei so> kräftig vor die Wand gelaufen bist das ich Mitleid hatte.
Mir unklar, wie man sich daran dermaßen ereifern kann.
vn nn schrieb:>>>> das ist ja schon wieder irgendwie traurig...
Mir völlig unklar, wie man sich daran so dermaßen ereifern kann.
gcc sieht volatile und hält sich streng an "da steckt volatile drin,
also darf ich nicht optimieren", während clang das offensichtlich als
"gut, da ist ein volatile drin, aber ich kann trotzdem was optimieren"
betrachtet.
So what? Beides nicht verkehrt. Wer Performance braucht, sollte sich gut
überlegen, wo er ein volatile einstreut.
Dann werden gleich noch Unbeteiligte angepfiffen (ich war an diesem
Streit bis dahin noch nicht mal ansatzweise beteiligt) und Herr Holm T.
fühlt sich gleich noch mit herausgefordert, endlich mal wieder was
Destruktives zu schreiben.
Kindergarten. Echt.
Frank M. schrieb:> mysquare: # @mysquare> mulsd xmm0, xmm0> ret> mypow2: # @mypow2> mulsd xmm0, xmm0> ret>> gcc und clang liefern hier übrigens dasselbe Ergebnis.>> Ich denke, damit ist die Frage hinreichend beantwortet und ein jeder> kann sich nun wieder wichtigeren Dingen zuwenden.
Danke liebe Leute für eure Hilfe. Btw. es ist keine uC Anwendung,
sondern ein PC-Linux-C-Programm. Dort muss ich im innersten mehrerer
verschachtelter Schleifen die Längen von Vektoren berechnen, Umrechnung
Rechteck in Polarkoordinaten, einmal X,Y und dann noch im
Farbvektorraum. So dachte ich, das der Gedanke an den Versuch einer
Optimierung nicht ganz abwegig ist. Liebe Grüße
Icke schrieb:> X² = X * X
Stimmt auffällig. AAABer:
hier geht es um
(X - Xmittel)².
Wenn ich jetzt dern Herrn Binomi(TM) bemühe ist das aber meines Wissens
(X - Xmittel)² = X² + 2*X*Xmittel - Xmittel²
oder liege ich da falsch?
Blähboy schrieb:> Btw. es ist keine uC Anwendung, sondern ein PC-Linux-C-Programm.
Diese Info gehört ins Eröffnungsposting. Außerdem hast Du mit "µC &
Elektronik" auch noch das falsche Forum gewählt.
Ich verschiebe das dann direkt mal.
Jemand schrieb:> LLVM hat ein Tool womit man die Performancecharakteristik von Kompilaten> statisch bewerten kann: llvm-mca. Einen krassen Unterschied sehe ich> zwischen den Versionen damit nicht.
Interessant. Verstehe ich das Richtig, beide Versionen sind exakt gleich
schnell im default und Skylake und bei Zenver1 ist GCC sogar schneller?
Jemand schrieb:> vn nn schrieb:>> Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht>> einfach sagen kann "kompilier halt mit -c".>> Was hindert dich denn daran?
Dass ich ausprobieren wollte, zu was "pow(x, 2)" optimiert wird, und
nicht, welchen Funktionsumfang godbolt unterstützt. Denn genau das ist
Thema des Threads. Threadthema ist nämlich weder "was kann godbolt
alles", noch "ist volatile an der Stelle undefined oder nicht".
Aber faszinierend, wie sich die geballte Foreninkopmpetenz auf ein
"volatile" in einem Demobeispiel stürzt, weil sie zum eigentlichen Thema
nix beizutragen hat.
Markus F. schrieb:> vn nn schrieb:>> Du hättest auch selbst drauf kommen können, dass ich bei goldbolt nicht>> einfach sagen kann "kompilier halt mit -c".>> dann solltest Du das vielleicht mal probieren (so hättest Du dann> wenigstens irgendwas dazugelernt).
Natürlich kann ich es. Aber da ich wissen wollte, wie "pow(x, 2)"
optimiert wird, wollte ich mich halt nicht mit Nebenbaustellen
beschäftigen.
Klar, du hingegen machst gezielt die Nebenbaustelle auf.
Markus F. schrieb:> Abgesehen davon hätte ich naiv> angenommen, daß jemand, der zu einer C-Frage den dicken Max macht,> vielleicht eventuell tatsächlich einen eigenen Compiler hat?
Falls du es noch nicht gemerkt hast, der Sinn von godbolt an der Stelle
ist, dass man darauf verlinken kann (wegen der Nachvollziehbarkeit
wärs).
Aber eh klar, nachdem dich das eigentliche Threadthema nicht
interessiert, und du nur stänkern willst, interessiert dich natürlich
auch die Nachvollziehbarkeit von themenspezifischen Postings nicht.
Markus F. schrieb:> vn nn schrieb:>> War ja keine Zielplattform gefragt.>> Wie heisst das Forum hier gleich noch mal?
Genie. Embedded kann genau so gut x86 sein. Aber hellsichtig wie du
bist, kannst du bestimmt eine konkrete Zielplattform vorschlagen. AVR?
PIC? ARM? RISCV?
Tim T. schrieb:> Also mir ist es jetzt einfach zu doof weiter darauf einzugehen. Der> Spezialist will es einfach nicht verstehen und ich hab sinnvolleres zu> tun als mich mit einem Troll auseinander zusetzen. Für mich ist hier> demnach EOD.
Sehr gut. Dann können endlich wieder themenrelevante Dinge diskutiert
werden, anstatt deines Unverständnisses was "volatile" so macht.
Bis dahin wundere dich einfach weiter, warum die Variable deswegen
zweimal gelesen wird.
Tim T. schrieb:> Brauch er auch nicht, wenn du einfach mal scharf hinschauen würdest,> wird im zweiten Fall ebenfalls eine zweiter Lesezugriff auf die Adresse> durchgeführt, nur werden die Daten nicht überflüssigerweise in einem> Register zwischengelagert sondern direkt verwurstet.
Für den Fall, dass du es noch nicht gemerkt hast: es bezieht sich hier
jeder auf den ersten von dir gelisteten Fall, den du eleganterweise
jetzt einfach unter den Tisch fallen lässt.
Markus F. schrieb:> Mir völlig unklar, wie man sich daran so dermaßen ereifern kann.>> [...]>> Kindergarten. Echt.
Ich vermute, du meinst mit "Kinergarten" so Aussagen wie "dann solltest
Du das vielleicht mal probieren (so hättest Du dann
wenigstens irgendwas dazugelernt)"? Oder sowas wie "Wie heisst das Forum
hier gleich noch mal?", und plötzlich stellt sich raus dass x86-64 doch
nicht so falsch war?