• 1
  • 2
2007-03-04, 18:41
  #1
Medlem
Drooms avatar
Sitter och har börjat bygga en fysikmotor i 2D och funderade över hur mycket jag ska dela upp varje del.
Om jag fortsätter som jag gör nu så blir det ett väldigt djupt funktionsträd eller hur man ska uttrycka det.

En funktion kallar på en funktion som kallar på en funktion som kallar på en funktion som kallar på en funktion som kallar på en funktion etc.

Varje funktion gör rätt få saker men detta behövs för att allt ska bli 100% begripligt. Tar det långt tid att börja "kalla på" en funktion om man t ex jämför med att t ex inkrementera en Int32?
Citera
2007-03-04, 19:40
  #2
Medlem
d03ahs avatar
Är verkligen ingen prestanda expert, men du kan ju enkelt göra några små tester och se om du vinner någon prestanda.

Men generellt tror jag inte att det i sig innebär någon direkt prestanda minskning att dela upp koden i många små metoder, så länge hoppen i binären är små. Små hopp beror helt på hur koden länkas ihop, finns antagligen något länkdirektiv som du kan använda för att optimera länkningen map hopp. Måste din kod vara uppdelad i många små metoder? Anropas alltid koden i sama ordning så finns det ju ingen direkt anledning att dela upp den, men det vet du säkert redan (har läst andra inlägg av dig o du verkar ju inte vara helt bakom flötet). Och som sagts tidigare, länkaren fixar det mesta åt dig.

Ett konkret tips om du använder c/c++ är att gör dina metoder inline. En annan idé är ju att se till att optimera dina funktioner. Har du mycket beräkningar som ska göras (vilket ju ofta är fallet med grafik) så se till att förenkla alla matematiska uttryck. Använd addition och subtraktion istället för multiplikation och division. En for sats är biligare att använda än tex en multiplikation. Se också till att använda call by refrence istället för call by value, det spar mycket prestanda (men detta vet du säkert).
Citera
2007-03-04, 19:52
  #3
Medlem
Drooms avatar
Grejen är den att jag har många små matematiska funktioner. Det blir helt enkelt lättare att se vad som händer.

Kör t ex Distance(PointF From, PointF To) (alltså avståndet) och det kan bli rätt mycket kod med några sådana utan dessa små funktioner.

Får se hur krävande det blir, borde inte bli för krävande om man bara använder det i 2D. Har dock gjort en fysikmotor innan när jag var lite yngre och den blev lite för kostsam prestandamässigt. För den som är intresserad så kan jag berätta att denna är inriktad på Mutliplayer-spel, alltså via nätverk.
Citera
2007-03-04, 19:56
  #4
Medlem
d03ahs avatar
Jag skäms...

Efter att ha svarat på ditt inlägg och utan att lägga märke till att din fråga rör C# för sent så fick jag plocka fram den stora manualen (använder Professional C# 3rd edition). Där i söke jag på inlining och den som söker finner:

Citat:
The JIT compiler is designed to generate highly optimized code, and will ruthlessly inline code as appropriate.

Och detta var svaret på den hypotetiska frågan, ur boken, om alla dessa små metoder som C# programmerare uppmanas till att skapa påverkar prestandan.

Citera
2007-03-04, 20:20
  #5
Medlem
Drooms avatar
Nu ska vi se här. Du menar alltså att C# själv hittar var den kan tillämpa inlining? Detta borde vara bra för mig.
Eftersom jag kör med statiska funktioner borde JIT:en fatta rätt snabbt att den kan inline:a dem.

Men man kan alltsåinte , som i C, ange att de ska inline:as?

Sen köper jag nog inte din teori om for-loops-multiplikation utan några tester.

(Förstår inte riktigt om det är bra eller dåligt. Får uppfattning om att det är positivt men sen klämmer du in en gråtande smiley. )
Citera
2007-03-04, 20:50
  #6
Medlem
How to write friendlier code for the Garbage Collector and to gain performance boost
Citera
2007-03-04, 20:57
  #7
Medlem
Drooms avatar
Citat:
Ursprungligen postat av K85
How to write friendlier code for the Garbage Collector and to gain performance boost
Ahhh gamle räven K85 . Det här blir till att sträckläsa. Tack!
Citera
2007-03-04, 21:25
  #8
Medlem
Många länkar till fler artiklar i slutet av artikeln.
Så lär dig allt(en del) så kommer du "förhoppningsvis"
ha applikationer som får flash gordon att framstå som en snigel som kryper i motvind
Citera
2007-03-04, 22:41
  #9
Medlem
d03ahs avatar
Citat:
Ursprungligen postat av Droom
(Förstår inte riktigt om det är bra eller dåligt. Får uppfattning om att det är positivt men sen klämmer du in en gråtande smiley. )

Smileyn på slutet var bara ett försök att markera mitt misstag. Hade jag inte varit så salongsberusad då jag läste din post hade jag ju i rubriken sett att frågan rörde C#...

Citat:
Ursprungligen postat av Droom
Men man kan alltsåinte , som i C, ange att de ska inline:as?

I boken går det att läsa:

Citat:
There is now way for you to control which methods are inlined , by using, for example, some keyword similar to the keyword inline of C++.

K85:s lästips verkar ju riktigt intressant. Har inte jobbat speciellt mycket med C# men det som artikeln tar upp är ju nyttig läsning för många utvecklare. Det slarvas och skrivs mycket OO kod är dålig.
Citera
2007-03-05, 10:22
  #10
Medlem
Om man oroar sig över prestanda för funktions-anrop i C# då använder man inte rätt språk. Koda på som du gör och sluta oroa dej över prestanda tills det blir ett problem. När prestandan blir ett problem måste du kanske öka på dina kunskaper om vad som kan optimeras. Länken K85 skickade om garbage collection är ett bra exempel.

Jag ska tipsa dej om en annan mycket bra artikel på CodeProject :

Optimization
Citera
2007-03-05, 12:55
  #11
Medlem
Citat:
Ursprungligen postat av Droom
Grejen är den att jag har många små matematiska funktioner. Det blir helt enkelt lättare att se vad som händer.

Kör t ex Distance(PointF From, PointF To) (alltså avståndet) och det kan bli rätt mycket kod med några sådana utan dessa små funktioner.

Jag är inte utbildad programmerare... även om jag jobbar som sådan och har vissa kunskaper...

...dock är jag utbildad i matte/fysik (~210 universitetspoäng) och kan förvarna dig om att dessa "små" funktioner kommer bli mycket kostsamma. Jag har t.ex skrivit en fysikmotor på kvantmekanisk nivå.

Några saker man t.ex kan fundera över:
- När det gäller avstånd: räkna inte ut rötter i onödan! Att kvadrera går snabbt, men rotdragning är inte alls lika effektiv. Men tänk på: Det går lika bra att jämföra kvadrater på avstånd som att jämföra avstånden själva.
- Tabulera funktioner! Att interpolera i tabeller kan ofta vara mycket snabbare än att beräkna jobbiga funktioner.
- Ofta stöter man på rent matematiska optimeringsproblem: då lönar det sig ofta att plocka upp en bok i ämnet istället för att hitta på nån egen metod.
- Det finns massor grejer... orkar inte skriva mer...
Citera
2007-03-05, 12:59
  #12
Medlem
Sane?s avatar
Att köra programmet genom en profiler när det är klart ger alltid några nya vinklar för optimering.
Kan rekommendera ants-profiler http://www.red-gate.com/products/ant...iler/index.htm
Citera
  • 1
  • 2

Skapa ett konto eller logga in för att kommentera

Du måste vara medlem för att kunna kommentera

Skapa ett konto

Det är enkelt att registrera ett nytt konto

Bli medlem

Logga in

Har du redan ett konto? Logga in här

Logga in