Ein bisschen InlineAssembler hilfe :)

[himitsu]

Delphi macht etwa das daraus

Delphi-Quellcode:

00461AF3 EB1F             jmp @@Loop
@@Start:
// Unit1.pas.32: Zahl:= Zahl +1/n;
00461AF5 D905381B4600     fld 1
00461AFB DC3424           fdiv &n
00461AFE DC442408         fadd &Zahl
00461B02 DD5C2408         fstp &Zahl
00461B06 9B               wait 
// Unit1.pas.33: n:= n+1;
00461B07 DD0424           fld &n
00461B0A D805381B4600     fadd 1
00461B10 DD1C24           fstp &n
00461B13 9B               wait 
@@Loop:
// Unit1.pas.30: while  Zahl < i do
00461B18 DB442410         fild &i
00461B1C DC5C2408         fcomp &Zahl
00461B20 9B               wait 
00461B21 DFE0             fstsw ax
00461B23 9E               sahf 
00461B24 77CF             jnbe @@Start

Eine Optimierung, welche mir einfällt ... kann man das n denn nicht auch als Integer auslegen?

Delphi-Quellcode:

// Unit1.pas.33: n:= n+1;
00461B07 DD0424           fld &n
00461B0A D805381B4600     fadd 1
00461B10 DD1C24           fstp &n
00461B13 9B               wait

Hier würde ja alles in einen winzigen Befehl (INC &i) reinpassen und das dan auch noch sofort und ohne warten auf die FPU.

Mit der ASM-Programmierung der Fließkommaeinheit kenn ich mich nicht grade aus, aber vielleicht kann man da ja die Zahl gleich da drinne lassen und nicht immer rein- und wieder rauskopieren.
Wenn man das n als Integer hätte, dann würde in der FPU ja nur vorranging mit Zahl gerechnet, wärend n, zusammen mit i womöglich sogar nur in den Registern rumgammeln könnte.


PS: wir hatten hier schon ein paar Mal, daß die hochoptimierten (Versuche von Menschen) ASM-Codes wesentlich langsamer oder wenigstens/zumindestens genauso schnell waren, wie die optimierten Delphi-Codes aus 'nem Pascal-Compiler.

[Neutral General]

Zitat von mleyen:

Lass es über die Grafikkarte laufen. (soll schneller gehn )

Ich weißt zwar nicht wie es geht, aber es würde mich auch mal interessieren.

Hatte mich gerade drangesetzt. Aber die FPU hat mich geärgert. Ich weiß zwar jetzt wies geht aber jetzt hab ich keine Lust mehr

[sx2008]

Du berechnest anscheinend eine harmonische Reihe.
Mit der richtigen Näherungsformel kannst du die Laufzeit extrem verringern.

[Medium]

Ungetestet, und keine Ahnung ob das wirklich schneller ist. Spart ein paar OPs, ob es damit auch cycles spart ist nie so sicher Zumindest spart es eine Menge pushes auf den FPU Stack! Auch möglich, dass man den Vergleich mit i noch etwas optimieren kann, ohne die Statusbits erst noch nach AX zu schaufeln. Das wait kann man sich erfahrungsgemäß so gut wie immer sparen. In meinen Handoptimierungen hat es bislang zumindest nie weh getan das einfach ersatzlos zu streichen

Delphi-Quellcode:

fild &i
fld &n
fld &Zahl
jmp @@Loop
@@Start:
// Unit1.pas.32: Zahl:= Zahl +1/n;
fld 1
fdiv st(0), st(2)
faddp
// Unit1.pas.33: n:= n+1;
fadd st(1), 1
@@Loop:
// Unit1.pas.30: while  Zahl < i do
fcomp st(2)
fstsw ax
sahf 
jnbe @@Start

[Spiderpig_GER_15]

Hi, danke für eure bemühungen

Kann es sein, dass die 50% Auslastung daher kommen, dass er meinen Dualcore nicht ausnutzt? (hab 2 * 3,0GHZ) wenn ja, wie kann ich das erreichen? Wäre das ein Ansatz für bessere Ergebnisse?

N kann leider kein integer sein (es ist zwar ganzzahlig, aber wird größer als der Bereich eines Int). Hat Delphi was genaueres auf Lager als double? Vielleicht sollte ich einen Abbruch machen, wenn 1/n = 0 ist, da es dann ja keinen Sinn mehr macht. Wieviel macht eine zusätzliche If Abfrage in einer solchen Schleife aus? Fatal?

Gruß vom Spiderpig,

(achso, der Grund ist eigentlich nur persönliches Interesse, und Anfrage meines Bruders )

[Namenloser]

Zitat von Spiderpig_GER_15:

Hi, danke für eure bemühungen

Kann es sein, dass die 50% Auslastung daher kommen, dass er meinen Dualcore nicht ausnutzt? (hab 2 * 3,0GHZ) wenn ja, wie kann ich das erreichen? Wäre das ein Ansatz für bessere Ergebnisse?

Natürlich, wie soll er denn den 2. Kern auch nutzen? Du hast ja nichts parallelisiert.

Zitat von Spiderpig_GER_15:

N kann leider kein integer sein (es ist zwar ganzzahlig, aber wird größer als der Bereich eines Int). Hat Delphi was genaueres auf Lager als double? Vielleicht sollte ich einen Abbruch machen, wenn 1/n = 0 ist, da es dann ja keinen Sinn mehr macht. Wieviel macht eine zusätzliche If Abfrage in einer solchen Schleife aus? Fatal?

Es gibt noch den Typ Extended, aber vergiss nicht, dass die Genauigkeit nicht gerade unerheblichen Einfluss auf die Geschwindigkeit hat. Einen Vergleich auf 1/n=0 zu machen, bringt nichts, weil n nie genau 0 wird, sondern einfach immer ungenauer, und das bei jeder Iteration.

[Spiderpig_GER_15]

extended ist also größer als double? Dann probier ich es mal damit (brauche übrigens nur positive Zahlen).

aber irgendwann ist doch auch aus der letzen 1 eine null geworden?!

[Apollonius]

Nur wenn n unendlich wird. Warum verwendest du eigentlich kein Int64?

[himitsu]

Zitat von Spiderpig_GER_15:

extended ist also größer als double?

Laut der OH ja.

Single = 4 Byte
Double = 8 Byte (doppelt so groß wie Single)
Extendet = 10 Byte

Allerdings ist das mit den "Größen" bei den Fließkommatypen soeine Sache.

Es muß nicht unbedingt die Größe größer werden, nur weil der Typ größer wird.
Tut es zwar, aber hier kommt es eigentlich mehr auf die nun größere Genauigkeit an.
Genaueres siehe OH.

Und das mit den 50% (bei einem QuadCore wären es nur ~25% )
Bei dir ist halt alles in einem Thread und ein Thread läuft immer nur auf einem Prozessor (gleichzeitig) ... für mehr müßtest du die Beechnung mehrere Threads aufteilen und diese Threads auch noch unterschiedlichen CPUs zuteilen (falls dieses Windows nicht automatisch macht)

[Namenloser]

Zitat von Spiderpig_GER_15:

aber irgendwann ist doch auch aus der letzen 1 eine null geworden?!

Bei Festkommazahlen wäre das so, aber Gleitkommazahlen speichern die Werte als Kombination aus Koeffizient (Mantisse) und Exponent. Den Exponent kannst du einfach immer weiter verringern, ohne dass die Zahl 0 wird. Natürlich wird auch der Exponent theoretisch irgendwann 0, aber das kann dauern. Und während dieser Zeit werden die Werte immer ungenauer, ich schätze, dass der Koeffizient irgendwann pseudo-zufällige Werte annimmt.
Es hat schon seinen Grund, dass man Gleitkommazahlen nie auf 0 prüfen sollte, schon allein deshalb, weil sich 0 auf verschiedene Weisen darstellen lässt. Nicht umsonst gibt es auch die Funktion IsZero() aus der Unit Math.

Bitte schlagt mich nicht, wenn ich jetzt mit meinem Halbwissen irgendwas falsches erzählt habe, aber ich glaube, das ist eifnach eine schlechte Idee. Und dein ursprüngliches Problem kriegst du auf diese Weise garantiert nicht gelöst.