Sollte man Optimierung für bestimmte seltene Fälle einbauen?

volkard

hustbaer schrieb:

Bei einer Wahrscheinlichkeit von 1 zu 1 Mio. ist die Erreichbare Verbesserung immer irrelevant, da sie im Bereich von 1 zu 1 Mio liegt. Ganz egal wie lange eine Operation braucht. Bei einer Laufzeit von 1 Mio stunden interessiert es micht überhaupt nicht ob eine Stunde gespaart wurde oder nicht.

aber ein if kostet nur eine million stel sekunde. und bei einer lauf zeit von einer oder einer million sekunden, also einer sekunde oder 12 tagen bist du sicherlich interessiert.
ist die mathe matik dir denn völlig fremd?

witte

volkard schrieb:

aber ein if kostet nur eine million stel sekunde.

Was hast Du denn für eine CPU? 1MHz?

Hängt davon ab wie lang eine stel-sekunde ist.

hustbaer

volkard schrieb:

hustbaer schrieb:

Bei einer Wahrscheinlichkeit von 1 zu 1 Mio. ist die Erreichbare Verbesserung immer irrelevant, da sie im Bereich von 1 zu 1 Mio liegt. Ganz egal wie lange eine Operation braucht. Bei einer Laufzeit von 1 Mio stunden interessiert es micht überhaupt nicht ob eine Stunde gespaart wurde oder nicht.

aber ein if kostet nur eine million stel sekunde. und bei einer lauf zeit von einer oder einer million sekunden, also einer sekunde oder 12 tagen bist du sicherlich interessiert.
ist die mathe matik dir denn völlig fremd?

Was ist denn jetzt kaputt?
Du schreibst von einer Wahrscheinlichkeit von 1 zu 1 Mio. Und sogar wenn ich mir 1% aller Rechnungen spare komme ich nicht von 1 Mio Sekunden auf eine Sekunde runter. Ist DIR Mathematik denn komplett fremd?

mehrere if Schleifen mit equals-Methodenaufrufen aufrufen, die wiederum zeit brauchen.

http://www.if-schleife.de

if-schleife.de schrieb:

mehrere if Schleifen mit equals-Methodenaufrufen aufrufen, die wiederum zeit brauchen.

http://www.if-schleife.de

void if_schleife (int n)
{
  if (n)
    if_schleife (n-1);
  printf ("%d\n", n);
}

int main (void)
{
  if_schleife (10);
}

^^ich weiss, ist alt.

+fricky schrieb:

if-schleife.de schrieb:

mehrere if Schleifen mit equals-Methodenaufrufen aufrufen, die wiederum zeit brauchen.

http://www.if-schleife.de
void if_schleife (int n)
{
  if (n)
    if_schleife (n-1);
  printf ("%d\n", n);
}

int main (void)
{
  if_schleife (10);
}
^^ich weiss, ist alt.

nicht so alt wie dein Bart :p

volkard

hustbaer schrieb:

Was ist denn jetzt kaputt?
Du schreibst von einer Wahrscheinlichkeit von 1 zu 1 Mio. Und sogar wenn ich mir 1% aller Rechnungen spare komme ich nicht von 1 Mio Sekunden auf eine Sekunde runter. Ist DIR Mathematik denn komplett fremd?

^
du sparst dir EINMAL von einer million die teure rechnung, die millionenmal teurer als ein if ist und zahlst dafür jedesmal ein if mehr.

hustbaer

volkard schrieb:

hustbaer schrieb:

Was ist denn jetzt kaputt?
Du schreibst von einer Wahrscheinlichkeit von 1 zu 1 Mio. Und sogar wenn ich mir 1% aller Rechnungen spare komme ich nicht von 1 Mio Sekunden auf eine Sekunde runter. Ist DIR Mathematik denn komplett fremd?

^
du sparst dir EINMAL von einer million die teure rechnung, die millionenmal teurer als ein if ist und zahlst dafür jedesmal ein if mehr.

Ja verstehe ich schon.
Die Gesamtlaufzeit des Programms ändert sich dadurch aber nicht wesentlich.

Ich hab' ja bereits geschrieben dass ich es in dem Fall sicher auch machen würde. Weil es eben vermutlich Fälle gibt wo sehr oft 0, 1 oder -1 vorkommt. Und natürlich auch weil der Test so billig ist. Grundsätzlich bleibe ich aber dabei: eine Optimierung die mir eine Verbesserung um ein Millionstel bringt ist witzlos. Egal wie gross dieses Millionstel ist.

volkard

hustbaer schrieb:

Grundsätzlich bleibe ich aber dabei: eine Optimierung die mir eine Verbesserung um ein Millionstel bringt ist witzlos. Egal wie gross dieses Millionstel ist.

ja. jetzt verstehe ich dich.

unabhängig davon, daß du recht hast: "grundsätzlich" würde ich wie immer nicht sagen. es war ja nur eine wahrscheinlichkeit. für mich selber würde ich diese optimierung auch bei langzahlen weglassen. als bibliotheksentwickler würde ich auf die zielgruppe schauen müssen und sie im zweifelsfall unter umständen vielleicht gegen meine überzeugungen eher einbauen, weil sie mit optimierung unmerklich langsamer wird aber bei den nasen, die andauernd mit 0 oder 1 multiplizieren, statt sich vorher gedanken zu machen, satt was bringt.

knivil

Bei einer Wahrscheinlichkeit von 1 zu 1 Mio.

Das ist 'ne Art running gag bei Terry Pratchett. Wenn diese Chance exakt ist, dann wuerde ich auf alle Faelle optimieren.

rapso schrieb:

bei mir:
ohne: 12030ms
mit: 12010ms

Das kann garnicht sein, das sind zwei Anweisungen mehr. Glaubst du, dass hier alle doof sind und nur dein Paradoxon stimmt?

uhsuhz

Ok danke für die zahlreichen Antworten.

Ach ja das mit den schleifen: da hab ich nur das falsche Wort geschrieben
Ich habe keine! if-schleife eingebaut...

ich werde einfach glaub ich ein boolean special einbauen, und nur dieses abfragen anstelle von mehreren vergleichen. Diese operation dürfte dann nicht ins gewicht einfallen bei den normalen berechnungen. Wenn dann ein speizialfall eintrifft kann ich dann noch immer abfragen um welches es sich handelt und danach handeln.

Beispiel:

Du kannst etwas 10 fach beschleunigen was zu 20% im Programm vorkommt.
(Das ist schon was, was man nur durch nen besseren Algorithmis schafft und sehr viel!)

Rechnung:

Gesamtbeschleunigung= 1/((1-0.2)+(0.2/10)) = 1.22
Hierbei wird das Gesamtprogramm lediglich 1.22 mal so schnell.

Da kann man sich überlegen ob es was brint etwas zu beschleunigen was noch viel seltener ist!

Algorithmis := Algorithmus

volkard schrieb:

tfa schrieb:

Optimiert wird nur, wenn du wirklich ein Performance-Problem hast, und das scheint nicht der Fall zu sein, oder?

Ihr Schnapsnasen! Natürlich macht man sich von Anfang an Gedanken darüber. Will man solcherlei Art der Optimierung erlauben, kommt ein ganz anderes Klassengerüset heraus (und keine if-Schleifen).
Und hier ist die Überlegung auch so einfach, daß man das tatsächlich ohne Profiler schafft, wie tfa und Mr Evil beweisen. Der Profiler mag Euch zwar das Nachdenken abnehmen können, aber doch erst im Nachheinein, wenns schon zu spät ist, wenn für eine tiefgreifende Optimierung alles umgeschubst werden muß.

Bleibt nur noch zu fragen, wann und wo und warum man die Optimierungen für Zero, One und MinusOne sieht. Ach ja, bei Langzahlarithmetik. Klar, wenn man bei 100000000 Ziffern eine ganze Rechnung spart, ist die Einsparung so groß, daß man das bereits bei einer wahrscheinlichkeit von eins zu einer Million versucht.

Bei solchen Spassaufgaben kann man sich über sowas gedanken machen. Wenn du dir bei realen Projekten, die in einem bestimmten Zeitraum fertiggestellt sein müssen, bei jeder Funktion an solche "Optimierungen", wie z.B. mach ich da noch ein if für diesen Speziallfall, denkst, wirst du nie fertig. In realen Projekten solltest du dir zuerst Gedanken über die Wart- und Erweiterbarkeit deines Softwaredesigns Gedanken machen. Dann kannst du dir überlegen welche Datenstrukturen und Algorithmen du verwendest, das sind die Sachen die wirklich Performance bringen. O(n²) vs. O(n) usw. Diese Mikrooptimierungen von ein paar Befehlen kannst du machen, wenn du raus gefunden hast, dass dein Programm wirklich ein paar Milliarden mal an dieser stelle vorbeikommt und es keine Möglichkeit gibt das zu vermeiden. Gut, wenn du beruflich Frameworks programmierst die dann von tausenden anderen verwendet werden, dann kannst du dir überlegen, ob das list.insert diesen oder jenen Befehl braucht, aber sowas macht sowieso fast keiner. Aber ich glaub beruflich hast du noch nie an nem größeren Projekt (mehrere Mannjahre), das dann an Kunden ausgeliefert wurde, gearbeitet, stimmts?

volkard

zzzzzzz schrieb:

bla

die überlegung dauert hier keine zehn sekunden. da muß man sich nicht mit solcher gewalt dagegen wehren.

volkard schrieb:

zzzzzzz schrieb:

bla

die überlegung dauert hier keine zehn sekunden. da muß man sich nicht mit solcher gewalt dagegen wehren.

Nein volkard. premature optimization is the root of all evil. Immer, ausnahmslos. Merk dir das endlich!!!

Also bei uhsuhz hats deutlich länger gebraucht. Und in größeren Projekten hast du tausende Funktionen und viele mit komplexeren Problemen als diesen. Da kommen dann schnell ein ein paar Tage "über Befehle optimieren" nachdenken raus. Die steckst du besser in "über Design und Algorithmen" nachdenken rein.

Tim schrieb:

volkard schrieb:

zzzzzzz schrieb:

bla

die überlegung dauert hier keine zehn sekunden. da muß man sich nicht mit solcher gewalt dagegen wehren.

Nein volkard. premature optimization is the root of all evil. Immer, ausnahmslos. Merk dir das endlich!!!

premature mikrooptimization würd ich sagen.