XPSE

- page 2 -

Frank
Abbing

Hehe, je hab nichtmal une Duocore...

22.08.2008 ▲

Hm, qui 64 Bit sembler es trop apporter. AMD holt angeblich aussi aus moins Clockcycles plus Rechenpower. Hab je déjà sur dem AutoCad-calculateur bemerkt, qui là réglé quoi weitergeht...

si meinem Prescott heiss wird, schaltet il angeblich trotz gleichbleibender Clockrate Energiespar-NOPs dans den Rechenfluss, avec cela qui CPU pas abfackelt.
et im Moment hats ici 31 Grad im espace - cela seulement trop seiner "Entschuldigung"

mais je gebe trop: quoi hülfe un Quad-Tiger im tank, si un Esel

am Steuer sitzt...
Gruss

22.08.2008 ▲

qui For-Boucle ist presque déjà un Relikt aus den ersten Zeiten des XPSE, réellement peux cet Boucle aufgrund des nötigen Aufbaus aussi garnicht plus rapide son, comme une whileLoop-Boucle. cela liegt simple daran que voici une variable genutzt wird, quoi wiederum aussi une Vorteil darstellt. (car früher était &loop dans untergeordneten Schleifen schier pas erreichbar, daher machte cet forme sinn.) dans Anlehnung à qui Syntax de Pascal J'ai eu mich pour Begin-Fin entschieden (konsequent) et pas pour for next.

23.08.2008 ▲

Ha, ha..., cet & GetTickCount ändert qui Ablaufzeiten , je après que combien Programme je im Windowstaskmanager abwürge.
si Je l' ordinateur récente starte et den Test tout de suite durchführe, sieht il enchanté aus.
si je zwischenzeitlich etwa d'autre avec cela fais et den gleichen Test starte, venons autre bzw längere Laufzeiten raus.

je halte de qui ganzen Laufzeitdiskkussion rien . Ist seulement augenwischerei.

quelquefois habe je cela sentiment, cela chez certain Befehlen qui komplette Registersicherung im ASM-Bereich unnützt ist. qui Bremse venez seulement par qui Registersicherung, qui verschieden gehandhabt wird.

je halte qui Profan-Schleifen pour très enchanté et léger nachvollziehbar.
qui Geschwindigkeitsverlust ist im Programmablauf pas spürbar.

jusqu'à maintenant habe je im Profan-Forum encore ne...aucune Programme trouvé, cela cette Geschindigkeitsunterschied dans irgendeiner Weise nachhaltige Ablaufprobleme mitbebracht hat.

mfg

23.08.2008 ▲

Jörg
Sellmeyer

Hm - comment viens Du ici car maintenant sur ASM? qui ganze Fil handelt seulement de profanschen Tandis que-Schleifen. XPSE wandelt seulement verschiedene Syntaxen pour Profan um, sans qui mais dans un autre Discours trop verwandeln. je suis absolu sûrement, qui cet Schleifen dans ASM midestens um den facteur 1000 plus rapide abgearbeitet volonté. ensuite doit mais aussi alles dedans qui Boucle dans ASM son.

@Frank:
Würde une ASM-Procédure Sinn faire, qui dedans einer Assembler Boucle qui Funktionsadresse einer Profanprozedur aufruft? ou bien rennt qui Boucle ensuite plus? avec einem entsprechenden Returnwert devrait on cela doch steuern peut...

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

qui Boucle sur ASM realisieren et seulement une ProcAddr transfert quelle aus asm angecallt wird pouvoir déjà Sinn, wird im comparaison mais pas viel plus rapide son comme une whileLoop-Boucle. je peux mir mais aussi présenter cela chez une certain Anzahl de Parametern cela pour hinten à l'attaque allez...

Frank
Abbing

je crois je pas, dass cela ideal wäre et viel Sinn pouvoir.

Tut es, un très gutes Beispiel pour ist z.B. qui lineDDA-Api qui im Prinzip déjà une derartige Zählschleife darstellt. (et c'est pourquoi souvent et volontiers de mir genutzt wird - z.B. dans Spielen)

Jörg
Sellmeyer

je hab oui toujours qui Vorstelleung de einer ASM-Boucle, qui une liste avec dem le contenu eines Laufwerks füllt. mais wahrscheinlich ist cela par qui dabei trop benutzenden Apis, comment FindFile (ou bien so) aussi pas wesentlich plus rapide comme un Profan-AddFiles *=*.*"

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

Schaue Dir doch mon addfiles.dll à.

Entweder la hâte Vous ältere Version ou bien qui annonce stammt pas vom xpse?

xpse pouvoir ici (zum Glück) doch alles korrekt:
Kompilieren Marque Séparation

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

27.08.2008 ▲