XPSE

- Seite 2 -

Natürlich...

Meine Zeiten werden auch trotz beenden aller unnötigen Tasks und Services nicht viel besser. Hab auch die Priorität auf hoch, sämtliche Antivirenprogis raus etc.:

45°C 54°C 64°C 71°C 72°C 77°C
2844 2860 2859 2860 2875 2844
2828 2828 2860 2844 2844 2859
2812 2812 2890 2812 2844 2813
############################
2735 2735 2735 2750 2750 2735
2781 2734 2765 2750 2750 2750
2719 2735 2766 2844 2766 2812

Ergebnis: Ich brauch einen Quadcore!
LOL
Gruss

22.08.2008 ▲

Frank
Abbing

Hehe, ich hab nichtmal einen Duocore...

22.08.2008 ▲

Hm, die 64 Bit scheinen es zu bringen. AMD holt angeblich auch aus weniger Clockcycles mehr Rechenpower. Hab ich schon auf dem AutoCad-Rechner bemerkt, daß da ordentlich was weitergeht...

Wenn meinem Prescott heiss wird, schaltet er angeblich trotz gleichbleibender Clockrate Energiespar-NOPs in den Rechenfluss, damit die CPU nicht abfackelt.
Und im Moment hats hier 31 Grad im Raum - das nur zu seiner "Entschuldigung"

Aber ich gebe zu: Was hülfe ein Quad-Tiger im Tank, wenn ein Esel

am Steuer sitzt...
Gruss

22.08.2008 ▲

Die For-Schleife ist fast schon ein Relikt aus den ersten Zeiten des XPSE, tatsächlich kann diese Schleife aufgrund des nötigen Aufbaus auch garnicht schneller sein, als eine whileLoop-Schleife. Das liegt einfach daran das hier eine Variable genutzt wird, was wiederum auch einen Vorteil darstellt. (Denn früher war &loop in untergeordneten Schleifen schier nicht erreichbar, daher machte diese Form sinn.) In Anlehnung an die Syntax von Pascal hatte ich mich für Begin-End entschieden (konsequent) und nicht für for next.

23.08.2008 ▲

Ha, ha..., diese &GetTickCount ändert die Ablaufzeiten , je nachdem wieviel Programme ich im Windowstaskmanager abwürge.
Wenn ich den Computer neu starte und den Test sofort durchführe, sieht er angenehm aus.
Wenn ich zwischenzeitlich etwa anderes damit mache und den gleichen Test starte, kommen andere bzw längere Laufzeiten raus.

Ich halte von der ganzen Laufzeitdiskkussion nichts . Ist nur augenwischerei.

Manchmal habe ich das gefühl, das bei bestimmten Befehlen die komplette Registersicherung im ASM-Bereich unnützt ist. Die Bremse kommt nur durch die Registersicherung, die verschieden gehandhabt wird.

Ich halte die Profan-Schleifen für sehr angenehm und leicht nachvollziehbar.
Der Geschwindigkeitsverlust ist im Programmablauf nicht spürbar.

Bis jetzt habe ich im Profan-Forum noch kein Programm gefunden, das dieser Geschindigkeitsunterschied in irgendeiner Weise nachhaltige Ablaufprobleme mitbebracht hat.

mfg

23.08.2008 ▲

Jörg
Sellmeyer

Hm - wie kommst Du hier denn jetzt auf ASM? Der ganze Thread handelt nur von profanschen While-Schleifen. XPSE wandelt nur verschiedene Syntaxen nach Profan um, ohne die aber in eine andere Sprache zu verwandeln. Ich bin absolut sicher, daß diese Schleifen in ASM midestens um den Faktor 1000 schneller abgearbeitet werden. Dann muß aber auch alles innerhalb der Schleife in ASM sein.

@Frank:
Würde eine ASM-Prozedur Sinn machen, die innerhalb einer Assembler Schleife die Funktionsadresse einer Profanprozedur aufruft? Oder rennt die Schleife dann weiter? Mit einem entsprechenden Returnwert müßte man das doch steuern können...

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Die Schleife über ASM realisieren und nur eine ProcAddr übergeben welche aus asm angecallt wird macht schon Sinn, wird im Vergleich aber nicht viel schneller sein als eine whileLoop-Schleife. Ich kann mir aber auch vorstellen das bei eine bestimmten Anzahl von Parametern das nach hinten los geht...

Frank
Abbing

Ich glaube ich nicht, dass das ideal wäre und viel Sinn macht.

Tut es, ein sehr gutes Beispiel dafür ist z.B. die lineDDA-Api die im Prinzip schon eine derartige Zählschleife darstellt. (und auch deshalb oft und gerne von mir genutzt wird - z.B. in Spielen)

Jörg
Sellmeyer

Ich hab ja immer noch die Vorstelleung von einer ASM-Schleife, die eine Liste mit dem Inhalt eines Laufwerks füllt. Aber wahrscheinlich ist das durch die dabei zu benutzenden Apis, wie FindFile (oder so) auch nicht wesentlich schneller als ein Profan-AddFiles *=*.*"

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

Schaue Dir doch meine addfiles.dll an.

xpse macht hier (zum Glück) doch alles korrekt:
Kompilieren Markieren Separieren

 {$cleq}
int i
for i=10 to 20 step 3 do begin
print i
end
waitkey
end

Entweder hast Du eine ältere Version oder die Meldung stammt nicht vom xpse?

27.08.2008 ▲