Was ist rechnerisch schneller? simple formel

Walli

randa schrieb:

Also Maschi, folgende Sache:
Wie ich dich verstanden hab, hälst du es für sinnvoll, jeden Takt herauszukitzeln bzw überall Bitshifts zu verwenden, wo es geht.

Du kannst echt nicht lesen, oder?

Maschi schrieb:

Ich sprach nie von Anwendungsentwicklung, sondern ausschließlich vom Grafikbereich und da auch nur von Flaschenhälsen.

Btw: Stelle dir doch mal eine Methode in einem Programm vor, die 80% der ganzen Rechenzeit ausmacht. Wenn man da Takte spart dann macht sich das ganz ordentlich bemerkbar...

randa

MaSTaH schrieb:

Du kannst echt nicht lesen, oder?

Das kann ich, doch einmal präsentiert er sich so, einmal so. Ich glaube eher, er weiß selbst nicht was er sagt. Mal sagt er, man kaönne keine Allgemeinaussagen treffen, aber er gibt seine Version so, als ob er die Wahrheit kennt.

btw, wieso so agressiv?

Zu deiner anderen Aussage: Das hat nichts mit meinen Argumenten zur Bitshift-Sache zu tun. Es ist wurscht, ob ich das in einer Funktion oder in 10 berechne. Zu den "gesparten Takten" hab ich mich ja mittlerweile genug ausgelassen, also lies nochmal. Meine Position kennt man, ich bin eher gespannt auf Gegenargumente.

net 0

eigentlich sollte man beim rausholen von speed immer darauf achten, dass die hardware schön ackert. jede softwarelösung ist ist da weit unterlegen. es soll ja noch leute geben, die verwenden auf 'nem pentium eine sinus lookup-table und bemühen nicht den integrierten rechenknecht. auf den ollen 8-bittern, die noch nicht mal mul/div-instructions hatten, hätte z.b. eine simulation dieser rechenarten durch shifts und additionen sicher was gebracht, aber heute nicht mehr. ..und wenn man code optimiert und solche sachen wie instruction cache, pipelining, etc. ausser acht lässt, kann's schnell nach hinten losgehen. so gibt es z.b. prozessoren, die sind bei byte-operationen langsamer als mit 16-bit words. alles fies eben.

btw: manchmal wirds schneller, wenn man zeitintensive prozesse parallelisiert z.b. indem man mehrere threads einsetzt. (ich glaub informatiker sagen 'teile und herrsche' dazu). gerade bei heutigen gui-anwendungen, wo die cpu 99% der zeit herum-idled ist das sinnvoll. aber das ist ein anderes thema...

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.
Natürlich war die Idee, zur Laufzeit des zu prüfen, ob man shiften könnte, Müll. Man hat auch nicht immer eine 2er Potzenz. Aber manchmal kann man ja einfach dafür sorgen, dass man eine hat.

Im großen und Ganzen kommt man mit guten Algorithmen und Datenstrukturen sicherlich am weitesten. Vor allem bleibt man damit auch noch am meisten Plattformunabhängig. Shiften ist allerdings auch recht plattformunabhängig, also mit keinerlei Nachteilen verbunden.

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?