PureBoard

Verfasst: **13.02.2006 18:06**

Nur um da etwas kleines zu "berichtigen": Der Unterschied zwischen dem
a+0 und dem a in der Schleife beruht nicht auf dem von Deeem2031
genannten Effekt (obwohl es diesen auch gibt), sondern auf PB, welches
das Zeug ganz lustig optimiert

Code: Alles auswählen

a=a+0
wird zu
MOV ebx,dword [v_a]
 MOV dword [v_a],ebx

Code: Alles auswählen

a = a
wird zu
 PUSH dword [v_a]
 POP dword [v_a]

rofl

Aber ansonsten stimme ich vollkommen mit Deeem überein

Verfasst: **13.02.2006 18:07**

In einer OS-Umgebung wie Windows haben solche "Messungen" wirklich
nicht viel Aussagekraft. Selbst nicht mit "#RealTime_Priority". Irgendwas
läuft immer mit. Es kann höchstens Tendenzen zeigen.

Die einzigste Möglichkeit, um "schnelleren" oder "langsameren" Code zu
ermitteln, ist, sich das Compilat anzusehen. Aber nicht einmal das ist
dann sicher (L1/L2-Cache). Schon gar nicht einfach (bei grösserem Code).

Verfasst: **13.02.2006 18:08**

@remi_meier:
Lol, nagut, das ist wirklich Müll den PB da produziert. (mal davon abgesehen das "a=a" auch müll ist

) PB hat also immernoch seine Optimierungsschwächen.

Verfasst: **18.02.2006 03:21**

Deeem2031 hat geschrieben:@remi_meier:
Lol, nagut, das ist wirklich Müll den PB da produziert. (mal davon abgesehen das "a=a" auch müll ist ) PB hat also immernoch seine Optimierungsschwächen.

PB wird nicht a=a optimieren, weil dies - wie Du schon selbst sagst - vom betreffenden Programmierer "Schwachsinn" ist.

Fred hat mir dazu geschrieben:

It's non-sens to implement such optimisations, there is a lot of
'idiot' case which can be optimised but which will never arise in a
real program. It will just slowdown and bloat the compiler.

Gute Programmierer "verzapfen" also nicht so solchen Code....

Verfasst: **18.02.2006 13:07**

@Fridhelm

Danke,
jetzt kann ich mir einen neuen Computer kaufen
76xxx Millisekunden.
Celerron 1800MGz

Verfasst: **18.02.2006 13:11**

Sorry Friedhelm,
hab dein Namen falsch geschrieben

PureBoard

Geschwindigkeit