3. Wieviel Performance und RAM braucht was?

Wieviel Performance und RAM braucht was?

  • X

    was ist plutimizieren ?

    warum macht dividieren einen unterschied? von was?

    radizieren = wurzel?
    also wenn die mit dem Tricks potienz 2 von abstand 10 cm besser ist, als wurzel aus ((x.b-x.a)...blabla). dann ist multiplikation schneller als wurzel, oder? soetwas muss ich unbedingt wissen.

    für PhysikEngine kein float, nur ganze positive Zahlen, da ich denke floats sind ne Performancebremse und sowieso ungenau...
    Datentyp mit dem es am schnellsten geht, ich nehm mal an die Integer-Wertebereich da sie plattformabhängig von 16-, 32-, 64-bit Rechner sind. Unbegrenzter Raum durch dynamische arrays+matrizen, wenn noch grösser dann auf festplatten.

    was sind festpunktarithmetik?

    multiplikaten sind lahm? was wäre dann schneller?

    ist

    __int64 rdtsc(){
   ___asm rdtsc;
}

    für intels? ich hab amd, wie ermittle ich die takts?

    0
  • X

    ach ja und warum konnte der compiler nicht selbst erkennen dass die potienz von 2 in vergleichoperator schneller ist als wurzel aus 2.
    wenn der compiler doch so toll optimieren können soll werd ich da doch skeptisch

    0
  • V

    xBlackKnightx schrieb:

    was ist plutimizieren ?

    malrechnen.

    warum macht dividieren einen unterschied? von was?

    dividiren ist im allgemeinen lahmer als plutimizieren.
    deswegen schreibt man gerne statt

    double dividend=bla;//irgendwo am anfang

x/=dividend;//oft
y/=dividend;

    ein

    double factor=1/bla;//irgendwo am anfang

x*=dividend;
y*=dividend;

    radizieren = wurzel?

    jo.

    also wenn die mit dem Tricks potienz 2 von abstand 10 cm besser ist, als wurzel aus ((x.b-x.a)...blabla). dann ist multiplikation schneller als wurzel, oder? soetwas muss ich unbedingt wissen.

    bei if((b.x-a.x)(b.x-a.x)+(b.y-a.y)(b.y-a.y)<0.1*0.1) hab ich genausooft plutimiziert. beachte, daß das 0.1*0.1 keine plutimikation ist, da steht nur 0.01 im code, hals umständlich geschrieben.

    für PhysikEngine kein float, nur ganze positive Zahlen, da ich denke floats sind ne Performancebremse und sowieso ungenau...

    ja, langsamer als ints.

    Datentyp mit dem es am schnellsten geht, ich nehm mal an die Integer-Wertebereich da sie plattformabhängig von 16-, 32-, 64-bit Rechner sind.

    typedef unsigned char u8;
typedef unsigned short u16;
typedef unsigned int u32;
typedef unsigned long long u64;

    und dann nimm den, der am besten zu deinem problem passt.

    Unbegrenzter Raum durch dynamische arrays+matrizen, wenn noch grösser dann auf festplatten.

    also kleine nehmen.

    was sind festpunktarithmetik?

    wenn du meter immer in anzahl der centimeter darstellst.
    also nicht double 3.13, sondern int 314 umd 3 meter und 14 centimeter zu meinen.

    ist schneller als double oder float. hat aber immer ne feste anzahl von nachkommastellen. und man muß ein wenig aufpassen beim rechnen.

    int r=200;//radius von 2 metern
    int flaeche=r*r*314;//falsch!
    int flaeche=r*r*314/10000;//vielleicht richtig. man muss beim plutimizieren und dividieren noch nen stellen-ausgleich machen. naja, man schreibt sich nen datentyp dafür, der das macht, dann issses so praktisch wie double. aber schnell wie ein int. und natürlich nicht 100 also faktor sondern ne zweierpotent.

    multiplikaten sind lahm? was wäre dann schneller?

    addieren und subtrahieren.
    wenn du die fläche ausrechnen willst, kannste aber plutimikationen nicht vermeiden.

    ist

    __int64 rdtsc(){
   ___asm rdtsc;
}

    für intels? ich hab amd, wie ermittle ich die takts?

    müßte auch für amds laufen. windows wurd ja auch nicht (außer mal bei win95 und dem loop-bug) für den amd geschrieben, sondern für intel und läuft auch.

    0
  • V

    xBlackKnightx schrieb:

    ach ja und warum konnte der compiler nicht selbst erkennen dass die potienz von 2 in vergleichoperator schneller ist als wurzel aus 2.

    weil die automatische umsetzung falsch wäre.

    mal ein krasses beispiel:
    if(a/3>b)
    macht er dummerweise zu
    (ifa>b*3)
    und sobald b gräßer als MAX_INT/3 ist, gibts einen überlauf und er rechnet total falsch.
    nee, du als coder mußt leider wissen, was los ist.

    wenn der compiler doch so toll optimieren können soll werd ich da doch skeptisch

    skepsis ist gut. weiter so.

    0
  • ?

    <OT>
    @volkard: Der Wert vom url-Attribut kommt (unlogischerweise) nicht in Anführungszeichen. 😉
    </OT>

    0
  • C

    wurzeln die lahm. multiplikation ist auch nicht der tollste renner. wenn wurzeln unumgänglich sind, kannste im netz nach fast_sqrt oder so suchen rechtet nicht bis auf letzte bit genau, ist aber sehr flott

    soweit ich weiß bauen die CPU-hersteller schon seit geraumer Zeit feste Tabellen zur Wurzelbestimmung ein, so dass wurzenlziehen bis zu einem gewissen Grad ziemlich schnell ist (muss ich noch mal Nachschlagen, aber imho ist es die genauigkeit bis hundertstel und das gibts schon bei AMD seit amd k5).

    __int64 rdtsc(){
    ___asm rdtsc;
    }

    es funktioniert auf einem AMD k6-2 und auch auf Intel ;

    0
  • X

    hmm vielen dank, eine frage noch:

    wenn ich statt multiplikation

    c=a*b

    die addition in forschleife nehme

    for( unsigned int i=0 ; i < a ; ++i) {
c += b;
}

    ist es genau so schnell?
    dass problem ist dass ich die zahl 0 in integerzyklus symbolisch als ganze positive zahl definieren will - also 0 = (die letzte zahl von integer), und die Null rausschmeisse die ich sowieso nicht gebrauchen kann

    0
  • S

    xBlackKnightx schrieb:

    ist es genau so schnell?

    Nur wenn der Compiler sehr klug ist.

    0
  • V

    [quote="xBlackKnightx"]wenn ich statt multiplikation

    c=a*b

    die addition in forschleife nehme
    ist es genau so schnell?
    [quote]
    nein. bei *sehr* wenigen schleifendurchläufen könntest du vielleicht leicht schneller sein. bei vielen durchläufen bestimmt nicht mehr.

    dass problem ist dass ich die zahl 0 in integerzyklus symbolisch als ganze positive zahl definieren will - also 0 = (die letzte zahl von integer), und die Null rausschmeisse die ich sowieso nicht gebrauchen kann

    das hab ich jetzt nicht verstanden.

    0
  • X

    [quote="volkard"][quote="xBlackKnightx"]wenn ich statt multiplikation

    c=a*b

    die addition in forschleife nehme
    ist es genau so schnell?

    nein. bei *sehr* wenigen schleifendurchläufen könntest du vielleicht leicht schneller sein. bei vielen durchläufen bestimmt nicht mehr.

    dass problem ist dass ich die zahl 0 in integerzyklus symbolisch als ganze positive zahl definieren will - also 0 = (die letzte zahl von integer), und die Null rausschmeisse die ich sowieso nicht gebrauchen kann

    das hab ich jetzt nicht verstanden.

    die Zahl 0 hat keine Funktion mit der division
    von daher wäre 4 / 0 = error - was falsch wäre wenn die 0 als ganze positive zahl betrachtet wird?

    mal anders gesagt:
    die Wertebereiche sind alles Zahlen, wie eine Uhr-Arimethik
    Wenn ich short 65535 noch eine eins hinzuaddiere geht es wieder von vorn: die Null
    so wäre short 65536er-Uhr-Arimethik.

    wenn ich jetzt 2 65536er-Uhrer-Arimethiken nehme: die erste zeigt auf 3 und die andere auf 456, und möchte die beiden uhren multiplizieren -> so muss 456 in der multiplikation 3 mal um 456 gedreht werden. und anders rum 456 mal um 3. die dritte uhr zeigt dann auf 1368

    jetzt ein anderes beispiel:
    wenn ich sie 0 mal 3 multipliziere, so kommt 0 raus. wenn 65536 * 3 wird es nur 3x ganz herumgedreht zeigt es wieder auf 65536 also die null

    so weit so gut

    so jetzt mal aufgepasst:
    wenn die erste uhr auf 32768 zeigt und die andere auf NULL und die beiden dann dividiere, so kommt eine fehlermeldung raus was unlogisch wäre
    denk daran dass die Null die 65536te Zahl ist, also:
    32768 / 65536 = 0,5 wäre

    da spuckt also was

    vielleicht sollte ich die division ganz vermeiden.

    und etwas mehr praktizierendes machen

    0
Anmelden zum Antworten