Was ist rechnerisch schneller? simple formel

randa

Optimizer schrieb:

Ein Gegenargument ist die 80-20 Regel, die du sicherlich kennst. Ich verstehe nicht, was daran so schwer ist. Man kann doch akzeptieren, dass es ein paar wenige Stellen im Code geben kann, wo sich sowas lohnt

Ich habe das oben, bei etherals Bemerkung (die bisher die Überzeugendste war, wenn die Formeln tatsächlich komplett mit Bistshifts opimiert werden können), bereits akzeptiert. Es mag noch ein paar andere Bereiche geben, von denen ich aber glaube, dass sie sehr speziell sind und nichts mit gewöhnlicher Software, wie sie hier von Forumsmitgliedern und auch sonst enwtickelt wird, zu tun haben. Bestimmt gibts auch bestimmte Hardwarenahe Programme, in denen es nötig sein kann.
Beim Rest (beim Großteil) der Fälle sollte man seine Zeit besser in wirkliche Optimierung umsetzen, denn eigentlich reden wir (oder ich? ) hier von ganz normalen Programmen und nicht von Spezialfällen.

volkard

randa schrieb:

Das sind etwa 14% mehr Leistung.

poste mal ein messprogramm in standard-c++ (damit ich nachmessen kann), denn mich verwirrt die these, daß shiften hier 14% mehr speed bringt.

Walli

randa schrieb:

btw, wieso so agressiv?

Ich bin nicht aggressiv. Mich nervt es nur ein wenig, dass du keine Argumente bringst und alles als blöde Bitshifterei abtust. Du stellst hier abenteuerliche Rechnungen auf, die zu 99% deiner Phantasie entspringen. Fakt ist: Leute wie John Carmack und Co. haben bereits eindrucksvoll bewiesen, was Bitshiftereien, inline-asm, loop-unrolling, lookup-tables und sonstige Optimierungen ausmachen "können", wenn man sie denn an den richtigen Stellen einsetzt.

randa schrieb:

Meine Position kennt man, ich bin eher gespannt auf Gegenargumente.

Das ist das Problem... Die ignorierst du.

randa

Zuegegeben, ich bin auch im Zweifel, wie räpresentativ das ist... Jedenfalls hab ich den Code bereits gelöscht *g*.
Es war schlicht eine äußere Schleife, Indexvaraible unsigned int, welche bis 4 Milliarden gelaufen ist. Innen eine Schleife, die von 100000 bis 100010 (mit höheren Zahlen, nahm ich an, wäre mehr Rechenaufwand) gelaufen ist. Innen dann 18 Divisionen und 6 Multiplikationen mit dem inneren Counter, Rechnungen in etwa

x/(x/4), x/(x/8), x*(x/(x/4), x*(x/(x/8)), x/(x*(x/...

Davon halt zwei Schleifen, beide äquivalent. Eine mit Bitshifts, eine normal.

Eine simpel getrickte Sache eigentlich. Nur wenn die Berechnung lange läuft, ist das Ergebnis akzeptabel. Allerding hab ich noch nie solche Tests geschrieben, von daher kann es sein, das das Ergebnis verfälscht wurde. Wer es besser kann, möge was korrekteres schreiben.

Walli

Ja, jetzt ist nur die Frage, ob der Compiler deinen Test nicht wegoptimiert hat. Die Rahmenbedingungen würde ich gerne genauer kennen.

randa

@Mastah:
Ich glaub eher, du willst dich wichtigmachen. Wenn dir meine Argumente, die ich zur genüge dargebracht habe, nicht reichen, dann kommentiere sie einzeln und bringe deine Meinung dar.
Aber ich bin es leid, mir sowas wie von dir anzuhören. Innerhalb dieses Threads gehts nicht um Carmack, es geht nicht um Grafikkarten und GPUs, es geht um Softwareappliaktionen, betrieben auf einem Prozessor.
Du dagegen, so wie Mschi, stützt dich auf andere, Profis, die es so und so machen. Blödsinn. Könnt ihr auch selbst was dazu sagen?
Ich hab an keiner Stelle hier Argumente ignoriert, und habe die Diskussion dehalb neu gestartet, damit jeder schlauer werden kann. Ich eingeschlossen, wenn einer kommt und vernünftig kontert. Andernfalls, Mastah, solltest du still sein.

Ja, jetzt ist nur die Frage, ob der Compiler deinen Test nicht wegoptimiert hat.

Ich gebs auf. Immernoch auf dem Nanosekundentrip?

x/(x/4), x/(x/8), x*(x/(x/4), x*(x/(x/8)), x/(x*(x/...

Durch 8 teilen entspricht shiften. Was willst du damit zeigen?

Walli

@randa: Weißt du was? Glaub doch was du willst. Mir ist das langsam echt zu blöd hier. Nichts als Wischiwaschi bekommt man von dir zu hören. Du jonglierst hier nur mit Zahlen ohne Sinn und Verstand, stellst Menschen, die hier eine andere Meinung vertreten als Wichtigtuer hin und bist selber nicht in der Lage Fakten auf den Tisch zu bringen. Nein, wenn man dich auf deine angeblichen Tests anspricht kommst du mit der Ausrede "Den hab ich schon gelöscht". Wer soll dir das bitte abkaufen? Wenn dein Test so überzeugend gewesen wäre dann hättest du ihn ganz sicher gepostet. Willst du meine Fakten sehen? Schau dir mal ID-Games an... Warum setzen sie wohl immer neue Standards, während andere noch auf die nächste Prozessorgeneration warten müssen?

Und nein, ich werde bestimmt jetzt nicht anfangen einen Egoshooter mit und einen ohne Zweierpotenzen und Bitshifting zu basteln... In einem kleinen Konsolenprogramm wirst du den Effekt nämlich nicht so leicht bemerken können.

randa schrieb:

Ja, jetzt ist nur die Frage, ob der Compiler deinen Test nicht wegoptimiert hat.

Ich gebs auf. Immernoch auf dem Nanosekundentrip?

Nein mann! Ist dir mal in den Sinn gekommen, dass ein Compiler Berechnungen einfach so wegoptimieren kann wenn sie nutzlos sind? Damit wäre dein ganzer Test für den Ar....

randa

hmm, das ist mir grad auch aufgefallen. Naja, ich sagte ja, das das Ergebnis nicht räpresentativ ist. => Machts besser

b7f7

MStimer mt;// Hier fav timer
    mt.start();
    int i=2;
  //  _asm{int 3}
    for(unsigned int j=0;j<100000000;++j)
      i=(i*i)/i;
    mt.end();
    mt.start();
    for(unsigned int k=0;k<100000000;++k)
      i=(i<<1)/i;
    mt.end();
    cout<<endl<<i<<endl;// gegen optimierung

output
3.8352
3.108

randa

MaSTaH schrieb:

@randa: Weißt du was? Glaub doch was du willst. Mir ist das langsam echt zu blöd hier. Nichts als Wischiwaschi bekommt man von dir zu hören.

Das glaubte ich von dir zu hören.

Du jonglierst hier nur mit Zahlen ohne Sinn und Verstand

Diejenigen, die das gemacht haben, waren bisher du und Maschi, mit den Takten und den Shifts und bla.

Fakten auf den Tisch zu bringen.

Das habe ich getan.

Wer soll dir das bitte abkaufen?

Den Test hab ich heute Morgen gemacht, lang wieder gelöscht. Wenn du es mir nicht glaubst, mir egal. Meine Rechnungen hab ich ja offengelegt, mehr Source gibts gar nicht...Du willst dich wirklich nur wichtigmachen.

In einem kleinen Konsolenprogramm wirst du den Effekt nämlich nicht so leicht bemerken können.

Was du bisher nicht verstanden hast, ist, das es nicht drauf ankommt, ob du 10, 14, 20, oder 30% Performance gewinnst. Warum? Lies meinen ersten post nach dem close. Es nützt deiner Glaubwürdigkeit nichts, darauf rumzureiten, da ich noch eineiges mehr geschrieben hab. Aber du hast eher was gefunden, wo ich was nicht ganz korrekt gemacht hab, und so kannst wohl auch glücklich sein.
Dein Post, Mastah, hatte gar keine Aussagekraft, außer zu flamen.

Wenn sonst nichts mehr vernünftiges kommt, steig ich hier aus. Ich finde es schade, das die Kritiker nicht versuchen, die normale Diskussion fortzuführen, die ich anzufangen versuchte. => Mir wurscht, jeder optimiert selber.

Ciao.

Walli

randa schrieb:

Meine Rechnungen hab ich ja offengelegt, mehr Source gibts gar nicht...Du willst dich wirklich nur wichtigmachen.

*Prust*, su meinst doch wohl nicht das hier?

x/(x/4), x/(x/8), x*(x/(x/4), x*(x/(x/8)), x/(x*(x/...

ROFL

Warts mal ab... irgendwann verstehst du warum ich lache...

randa schrieb:

Was du bisher nicht verstanden hast, ist, das es nicht drauf ankommt, ob du 10, 14, 20, oder 30% Performance gewinnst.

Also wenn ich durch ein paar Änderungen "nur" 10% Performance gewinne dann mache ich sie! Intel ist auch doof, oder? Entwickeln die nen Dothan um ein paar Prozent rauszuholen...

b7f7

MaSTaH schrieb:

Also wenn ich durch ein paar Änderungen "nur" 10% Performance gewinne dann mache ich sie! Intel ist auch doof, oder? Entwickeln die nen Dothan um ein paar Prozent rauszuholen...

Die frage ist eigentlich wo ich die 10% schaffe
wenn ich zum Bsp FLDPI 10%schneller mach bringt das nicht wirklich was.
bei IMUL doch schon ehr.
bei der FFT kan man noch so viel schiften wenn man sein Vector nicht in gtössen zur basis 2 hat verliert man alles wieder.
und was nutzt im Bubblesort nen superschneller Swap algo?
Optimierung ist immer eine frage der Stelle an der sie geschiet.

japro

b7f7 schrieb:

MStimer mt;// Hier fav timer
    mt.start();
    int i=2;
  //  _asm{int 3}
    for(unsigned int j=0;j<100000000;++j)
      i=(i*i)/i;
    mt.end();
    mt.start();
    for(unsigned int k=0;k<100000000;++k)
      i=(i<<1)/i;
    mt.end();
    cout<<endl<<i<<endl;// gegen optimierung

output
3.8352
3.108

lol der ist echt geil *weglach*

jeder weiss schliesslich, dass i<<1 i quadriert

oder wolltest du zeigen, dass das quadrieren langsamer ist als das mit 2 multiplizieren. :p

b7f7

japro schrieb:

oder wolltest du zeigen, dass das quadrieren langsamer ist als das mit 2 multiplizieren. :p

für 2 machen beide das gleiche oder nicht?
asso und warum da i*i steht liegt daran damit der Compiler kein shift draus baut

japro

ja nur ist i eine variable und der sinn einer variable ist nun mal der variabel zu sein (bei mir jedenfalls).

ausserdem ist es sinnlos rechungen mit einer variable anzustellen deren wert man sowieso kennt oder sogar voraussetzt. wo soll man sowas brauchen?

b7f7

japro schrieb:

ja nur ist i eine variable und der sinn einer variable ist nun mal der variabel zu sein (bei mir jedenfalls).

ausserdem ist es sinnlos rechungen mit einer variable anzustellen deren wert man sowieso kennt oder sogar voraussetzt.

es geht darum was fixer ist ne multiplication oder nen shift

b7f7

btw wenn man nicht noch cout<<i; macht ersetzt der compiler alles dur ret

volatile ist dabei manchmal eine Hilfe. Amsonsten sind solche Progrämmchen meisten von wenig wert. Man müsste sich dann auf jeden Fall mal den Assembler-Code ansehen.

japro

b7f7 schrieb:

es geht darum was fixer ist ne multiplication oder nen shift

es ist aber ein unterschied, ob du eine variable mit einer anderen variable (z.b. mit sich selbst) multiplizierst, oder mit einer konstante...
d.h. i<<1 musst du wenn schon mit der operation i*2 vergleichen. dass irgendeine multiplikation schneller oder langsamer als irgendein bitshift ist wird dir jeder auch ohne beweis glauben.

wenn du beweisen willst, dass äpfel schneller fallen als birnen hast du auch nicht viel davon, wenn du die birne auf dem mond fallen lässt und den apfel auf der venus.