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

[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.

[wasisdas?]

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.

[MisterX]

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!

[MisterX]

Algorithmis := Algorithmus

[zzzzzzz]

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.

[Gast]

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!!!

[zzzzzzz]

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.

[zzzzzzz]

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.

[volkard]

Tim schrieb:

Immer, ausnahmslos. Merk dir das endlich!!!

zu späte optimierung hat aber auch schon so manches projekt zerstört.

[raps]

volkard schrieb:

Tim schrieb:

Immer, ausnahmslos. Merk dir das endlich!!!

zu späte optimierung hat aber auch schon so manches projekt zerstört.

sicher nicht so oft wie zu fruehe

[uhsuhz]

nun ja meine Funktionen sind ja eigentlich bereits alle fertig, algorithmen implementiert und fehler rausgenommen
damit müsste ich ja jetzt ans optimieren kommen oder?

[volkard]

raps schrieb:

zu späte optimierung hat aber auch schon so manches projekt zerstört.

sicher nicht so oft wie zu fruehe [/quote]
stimmt. deswegen soll man ja auch einerseits (vor allem sehr frühe) optimierung meiden, andererseits aber die effizienz insgesamt nie aus dem auge verlieren.

[volkard]

uhsuhz schrieb:

nun ja meine Funktionen sind ja eigentlich bereits alle fertig, algorithmen implementiert und fehler rausgenommen
damit müsste ich ja jetzt ans optimieren kommen oder?

keine ahnung. ist denn an der klasse irgendwas, was danach riecht, optimiert werden zu wollen. ich rieche nichts.

[raps]

volkard schrieb:

raps schrieb:

zu späte optimierung hat aber auch schon so manches projekt zerstört.

sicher nicht so oft wie zu fruehe

stimmt. deswegen soll man ja auch einerseits (vor allem sehr frühe) optimierung meiden, andererseits aber die effizienz insgesamt nie aus dem auge verlieren.

ich muss bei der planung fuer die optimierungen genau wie fuer cleanup eine zeiteinschaetzung abgeben.
von daher sehe ich das problem von 'zu spaet' nicht wirklich. von 'zu frueh' seh ich aber fast immer, denn optimierungen sind am effektivsten, wenn man den fall kennt fuer den man optimiert und der ist am ende erst bekannt (also verifizierbar).

uhsuhz schrieb:

nun ja meine Funktionen sind ja eigentlich bereits alle fertig, algorithmen implementiert und fehler rausgenommen
damit müsste ich ja jetzt ans optimieren kommen oder?

fast, hast du einen guten test case? profile ihn, je besser deine profiling daten sind, desto besser wird dein optimierungsergebnis.
und wie du vielleicht an meinem beispiel von seite 1 siehst, kostet ein if das nie anschlaegt in einer mathematisch aufwendigen situation auf phenom/intel core2 cpus garnichts. es sind ganz andere einheiten die das abarbeiten.... aber auch hier solltest du das mit einem profiler pruefen.

ich weiss nicht, ob das hier nicht zuviel des guten ist, aber ich hatte das vor ein paar tagen gelesen und fand es ziemlich unterhaltend

http://www.ddj.com/hpc-high-performance-computing/217200602?pgno=3 schrieb:

Many years ago, I got a call from a guy I had once worked for. He wanted me to do some consulting work to help speed up his new company's software. I asked him what kind of software it was, and he told me it was image processing software, and that the problem lay in the convolution filter, running on a Sparc processor. I told him I didn't know anything about either convolution filters or Sparcs, so I didn't think I could be of much help. But he was persistent, so I finally agreed to take a shot at it.

He put me in touch with the engineer who was working on the software, who immediately informed me that the problem was that the convolution filter involved a great many integer multiplies, which the Sparc did very slowly because, at the time, it didn't have a hardware integer multiply instruction. Instead, it had a partial product instruction, which had to be executed for each significant bit in the multiplier. In compiled code, this was implemented by calling a library routine that looped through the multiplier bits, and that routine was where all the time was going.

I suggested unrolling that loop into a series of partial product instructions, and jumping into the unrolled loop at the right point to do as many partial products as there were significant bits, thereby eliminating all the loop overhead. However, there was still the question of whether to make the pixel value or the convolution kernel value the multiplier. The smaller the multiplier, the fewer partial products would be needed, so we wanted to pick whichever of the two was smaller on average.

When I asked which was smaller, though, the engineer said there was no difference. When I persisted, he said they were random. When I said that I doubted they were random (since randomness is actually hard to come by), he grumbled. I don't know why he was reluctant to get me that information -- I guess he thought it was a waste of time -- but he finally agreed to gather the data and call me back.

He didn't call me back that day, though. And he didn't call me back the next day. When he hadn't called me back the third day, I figured I might as well get it over with and called him. He answered the phone and, when I identified myself, he said, "Oh, Hi. I'm just standing here with my managers, watching. We're all really happy."

When I asked what exactly he was happy about, he replied, "Well, when I looked at the data, it turned out 90% of the values in the convolution kernel were zero, so I just put an if-not-zero around the multiply, and now the whole program runs three times faster!"

[volkard]

raps schrieb:

von daher sehe ich das problem von 'zu spaet' nicht wirklich.

aber du kannst dir schon vorstellen, daß man software so baut, daß man von anfang an überhaupt keinen wert auf performance legt und man am ende sehr unzufrieden ist und daß man dann doch optimiert und beim optimieren das tolle design total zerstört und das gibt dann häßliche unwartbare frickelsoftware.

[Der Dumme]

Was lässt sich mit 1 und -1 denn verkürzen?

[Gast]

volkard schrieb:

raps schrieb:

von daher sehe ich das problem von 'zu spaet' nicht wirklich.

aber du kannst dir schon vorstellen, daß man software so baut, daß man von anfang an überhaupt keinen wert auf performance legt und man am ende sehr unzufrieden ist und daß man dann doch optimiert und beim optimieren das tolle design total zerstört und das gibt dann häßliche unwartbare frickelsoftware.

Ebenso sollte er sich vorstellen können, dass man software bauen muss wo (zumindest teilweise) schon zu Beginn offensichtlich ist wo viel Rechenzeit liegenbleiben wird. Und wenn man sich den anderen verallgemeindernden Spruch "make it work, make it right, make it fast" anschaut: Oft steht man vor dem Problem, dass man "make it fast" braucht um "make it work" zu bekommen.

Der Dumme schrieb:

Was lässt sich mit 1 und -1 denn verkürzen?

x mul (a, b)
    if a=1
        x = b
    elif a=-1
        x = b.togglesign()
    elif a=0
        x = 0
    else (allgemeiner Fall)
        x = a*b

[SideWinder]

Warum nicht einfach ein Template und das für diese drei Fälle spezialisieren. Da kann man nichts im Projekt zerstören und hat maximale Performance?!

MfG SideWinder